One trust boundary for every machine that holds a key.
Your CEX and DEX API keys stay inside an AWS Nitro Enclave. Agents on Binance, Hyperliquid, and OKX get a signature only after the request clears your policy (venue, action, and size), checked inside the same enclave, before the signature exists. On the CEX venues it can't touch a withdrawal or transfer at all.
Every AI-agent framework that touches a CEX today loads the API key into the agent process — into env vars, npm packages, prompt-engineered tool calls, and shell history. One prompt injection, one supply-chain attack, one curious co-worker — and the key leaks. Logs reach the LLM context. Infostealer malware grabs .env. Compromised dependencies swap the credential loader. The same key, more places to leak from.
A signer that lives outside the agent process collapses the attack surface. The agent proposes an order. A trust boundary decides whether that order fits the policy. The credential itself stays unreachable.
On Hyperliquid the signing key is generated inside an AWS Nitro Enclave; on the CEX venues your exchange secret is unwrapped and used only inside that same enclave, and never leaves it. The enclave is attested by AWS itself. The enclave's measurement (PCR0) is published and independently verifiable. The MCP server gives Claude Desktop, Cursor, ElizaOS, and any MCP-aware client a five-tool surface — bounded by an explicit policy: per-asset cap, per-period cap, allowed venues, deny-by-default. The agent can ask the enclave to sign a specific order. It cannot read the key. Neither can your laptop, your IaC, or our engineers.
AWS KMS holds the wrapped data-encryption key; the enclave decrypts it locally per session. Each signature is bound to the policy version it was issued under — change the policy, the previous DEK is no longer valid for new signs.
Signer: hosted service paused since 21 Sep 2026. Code and verification tools are public: github.com/namixai/signer.
How the check works: an attestation response carries attestation_doc_b64 — a raw NSM attestation document produced inside the enclave: a COSE_Sign1 structure (CBOR), signed with an enclave-held key whose certificate chains to the AWS Nitro Enclaves Root CA. Three checks make the claim yours instead of ours:
It's the same check we'd want before trusting anyone else's enclave.
CEX venues use HMAC over the REST request line. DEX venues use EIP-712 typed-data signing. Same enclave-isolated key, two signing primitives, one policy boundary. The statuses are today's state rather than the roadmap: Binance USD-M perp, Hyperliquid, and OKX are signing live on mainnet — on our own funds, not a client's, and pre-audit; design partners still start on testnet.
This is the integration surface — the same five-tool boundary our own trading runs through. The MCP server is open source (@usenami/signer-mcp); the enclave-side service is invite-based during early testnet, so the token below is provisioned for you at onboarding — there is no self-serve signup yet.
Once provisioned, an agent connects from a Claude Desktop / Cursor / ElizaOS MCP config:
{
"mcpServers": {
"signer": {
"command": "npx",
"args": ["-y", "@usenami/signer-mcp"],
"env": { "SIGNER_API_TOKEN": "<provisioned at onboarding>" }
}
}
}Each token is bound to an explicit policy fixed at provisioning — per-asset cap, per-period cap, allowed venues, deny-by-default. Five tools become available:
What survives: a fully compromised agent can still attempt orders. The policy boundary — asset cap, period cap, allowed-venue list — determines the worst-case loss, not the attacker's creativity.
Most funds and prop desks that want to run an agent against a live account hit the same wall in compliance review: nobody signs off on handing a model an exchange API key when that key sits somewhere the agent process can read it. The conversation usually ends there, before it gets to what the agent would actually be allowed to do.
Signer changes what compliance is being asked to approve. The signing secret is used inside the enclave and never leaves it — and every order is checked against a policy (venue, action, size) before a signature exists. That check is something compliance can verify directly, not something they have to take our word for.
One consequence, not the headline: a withdrawal or transfer request is refused at the signer, before a signature is ever produced — no policy setting turns that off.
The policy itself is fixed at provisioning, written with you before the key exists. It isn't something an agent can renegotiate later, and it isn't self-serve yet — we set it up with each design partner directly.
Signer: hosted service paused since 21 Sep 2026. Code and verification tools are public: github.com/namixai/signer. Access is provisioned per partner — tell us what you trade and which venues you need, and we set up a policy-bound token.