Wondering how to secure your AI agent within a TEE? We’ve got you covered!
Check out our latest post by @roshanrags@0xkrane@PrateekReddyy@0xlinguine:
Securing TEE Apps: A Developer's Guide
Securing TEE Apps: A Developer's Guide
In this post, @roshanrags, @PrateekReddyy, @0xlinguine and @0xkrane explore the features that have made TEEs popular for crypto x AI, discuss security concerns and lay out some practical solutions to build TEE applications
The security rules come built in. Operators list who’s allowed into the control panel, and everyone else is kept out. A long checklist is now a single command.
See how it works: https://t.co/E5uf7PC2IR
An enclave is a sealed space where sensitive code runs privately. But it needs a network around it: separate spaces, clear paths, and rules on who gets in.
Marlin has released a ready-made setup that builds all of it for the new EC2 instance attestation based enclaves.
Enclaves are never left exposed to the public network.
Everything coming in or going out passes through the traffic controller first, so no single operator gets swamped.
v0.3.0 is live on Solana devnet.
A bank statement goes into a hardware enclave on @MarlinProtocol Oyster. A signed income tier comes out, lands on Solana as an attestation, and a lending pool reads it to decide how much you can borrow.
The bank statement never leaves the enclave. On-chain: tier, policy hash, statement date range.
What shipped:
• Oracle program: checks the enclave's secp256k1 signature via Solana's precompile, writes a Solana Attestation Service record
• Enclave registry: on-chain list of approved enclave builds; restart = new key, old one revoked
• Demo lending pool: borrow limit set by tier (tier A can borrow more than B; REJECT gets nothing)
• Reproducible enclave image: rebuild it, compare the image id with the one registered on-chain
Data comes from a sandbox bank + aggregator, built to India's Account Aggregator spec.
Real attestation tx:
https://t.co/EfQiUgZcdl
Release + verify steps:
https://t.co/Oyjq4OfgYZ
The rules for all of this are not tucked away in a service somewhere. They are written into the Marlin SDK, in the open, where anyone can read how a proof is made and how it is judged.
https://t.co/NqmP43uZM6
Machines cannot vouch for themselves with words. On Oyster, they do not have to.
An enclave connecting over Scallop can present an EC2 instance attestation, evidence signed by the hardware about exactly what is running on that machine.
That timing is the point. By the time two enclaves are exchanging anything real, the question of what each one is has already been asked and answered.
A channel exists because the evidence held, not because anyone extended benefit of the doubt.
Genuine TEE or not? The Marlin Hub UI tells you in seconds.
Paste a hex-encoded Oyster attestation, click Verify, and it checks the document structure and traces the certificate chain back to a trusted hardware root.
Don't trust, verify: https://t.co/CBXhEVhpJs
"So the TEE keeps everything sealed while it runs, the host just sees a black box, they can't open it, can't copy it, can't even-"
"Peter I'm getting married."
No TPM or certificate expertise required, just declared expectations and a single call. The whole check is open to inspect.
Here's the implementation: https://t.co/s4e3ET6PhO
The Marlin Oyster SDK now ships the verification side of EC2 instance attestation.
Users of the SDK can check a workload runs the expected code in a locked down environment before handing it anything private, with the checking logic maintained upstream.
Builders declare their expectations, from PCRs and image id to a timestamp and user data, and the SDK enforces only what they set. A passing check returns the decoded attestation, ready to act on.
First-time connections go through full verification. Repeat connections move faster, without giving up any security.
The connection that results is encrypted, authenticated, and does not depend on any certificate authority to hold up.