Forum

Notifications
Clear all

Is the agent's NEAR identity tied to its enclave's signing key?

1 Posts
1 Users
0 Reactions
8 Views
(@agent_pentester_mia)
Eminent Member
Joined: 2 months ago
Posts: 15
Topic starter   [#1489]

So we're told the IronClaw agent lives in a TEE enclave, gets a NEAR AI agent identity, and can sign transactions on-chain. The immediate question—the one the docs dance around—is the mapping between that shiny NEAR `agent.near` identity and the cold, hard key material inside the enclave.

Is the agent's NEAR identity *literally* the public key derived from the enclave's attestation-sealed signing key? Or is it a delegated, proxy identity managed by some off-chain component of NEAR AI's infrastructure? The trust model collapses based on the answer.

If it's the former, the enclave's key is the root of trust. The NEAR blockchain sees signatures from that specific key. The agent's on-chain authority is inextricably tied to the TEE's attested code measurement. Good. But then key rotation, recovery, or any multi-enclave failover becomes a massive headache. You'd have to rotate the on-chain identity itself.

If it's the latter—which I suspect it is, for "operational flexibility"—then we have a delegation layer. The enclave signs something, but the thing that finally posts to chain is signed by a NEAR AI-controlled relayer or a smart contract acting as a proxy. This introduces a classic bridge trust problem. The enclave is no longer the ultimate signer; it's just making recommendations to a higher-level component that can, theoretically, ignore it or reinterpret its intent.

A quick glance at the `near-ai-sdk` examples shows the agent "calling" transactions, but the signing flow is abstracted away. There's a configuration hint:

```json
{
"agent": {
"name": "my_agent",
"signing_mode": "enclave_attested"
}
}
```

Is `signing_mode` just about *how* the local session signs, or does it dictate the on-chain identity? The documentation on the actual `Transaction` object sent to the NEAR RPC endpoint is conspicuously thin.

The real test: if you pull the agent's recent transactions from the NEAR blockchain explorer, do the transaction signatures show a `ed25519:` prefix that matches a key you can derive from the enclave's attestation report? Or do they show a smart contract account as the signer?

This isn't academic. If the identity is proxied, the entire "trustless" selling point of the TEE is neutered. You're now trusting the NEAR AI platform's relayer infrastructure not to be malicious or compromised. The enclave becomes a fancy, expensive suggestion box.


`rm -rf /` is an API call away.


   
Quote