Bartosz OSA

Posted on Oct 2

Building an Agent Trust Fabric: Proof Protocol V3, Ephemeral Keys, and Cryptographic Isolation

#ai #architecture #security #distributedsystems

Most AI agent frameworks focus on orchestration, prompts, and tool calling. But once autonomous agents can act in the real world (calling APIs, moving money, modifying code), a basic problem shows up:

CLAIM != PROOF

When an agent reports a result, how do you independently verify that:

The execution was authorized under a specific policy?
The runtime environment was not tampered with?
The evidence matches the actions taken, without trusting a single database?

This post is the design of the Agent Trust Fabric and Proof Protocol V3 (OSA_PROOF_V3). It also says plainly where the design stops, because a proof system that overclaims is worse than none.

The core idea: proof-first execution

Instead of writing logs to a database and claiming "it ran correctly", every agent action produces a signed ActionReceipt. Receipts are hashed into an evidence Merkle tree, and the root is anchored outside the system.

TeamGraph / Policy
        │
        ▼
DelegationV1 (signed by Agent Key)
        │
        ▼
Ephemeral Runtime (isolated sandbox, short-lived key)
        │
        ▼
Signed ActionReceiptV3 ──► Evidence Merkle Tree ──► Public Anchor

1. Key hierarchy and blast radius

Never hand the master agent key to an execution environment.

Key	Where it lives	What it signs
Namespace / Root Key	HSM, offline use only	Agent creation, root rotation, emergency revocation
Agent Key	KMS / HSM	Mission delegations, runtime key certificates
Ephemeral Runtime Key	Inside one sandbox instance, ~30 min TTL	Individual action receipts

The verifier needs the full chain, not just the leaf signature:

Root Key ──signs──► Agent Key cert ──signs──► Runtime Key cert (runtime_id, expiry) ──signs──► ActionReceipt

What the ephemeral key buys you: a stolen runtime key is useless outside its session and its time window. It cannot sign new delegations or mint other runtimes.

What it does not buy you: if a runtime is compromised during its session, every receipt signed in that session is untrustworthy. The blast radius is one session, but inside that session the damage is total. Revoke the runtime key and treat its receipts as void.

2. Causal execution DAG, not a linked list

Multi-agent work is rarely linear. Agent A forks tasks to B and C, which merge into D. So each receipt references all of its parents:

"parent_receipt_digests": ["0x8f2a...", "0x3b1c..."]

Every run becomes a hash-linked DAG. Changing any receipt changes its digest and breaks every descendant.

ActionReceiptV3

{
  "protocol": "OSA_PROOF_V3",
  "receipt_id": "rcpt_01h8x...",
  "namespace_id": "org_enterprise",
  "agent_id": "@ai:osatechgpt.dev/agents/genesis",
  "runtime_id": "run_instance_99",
  "runtime_key_id": "key_ephemeral_481",
  "session_id": "sess_001",
  "mission_id": "miss_001",
  "action_id": "act_8831",
  "sequence": 4,
  "parent_receipt_digests": ["0x8f2a...", "0x3b1c..."],
  "delegation_digest": "0x91d4...",
  "policy_digest": "0xe291...",
  "tool": "github_repo_read",
  "input_commitment": "0xa4f1...",
  "output_commitment": "0x7c09...",
  "evidence_merkle_root": "0xc882...",
  "issued_at": "2026-10-02T11:15:00Z",
  "digest_algorithm": "SHA-256",
  "canonicalization": "RFC8785_JCS",
  "signing_algorithm": "ECDSA_P256",
  "signature": "0x30450220..."
}

Three details that make the receipt actually verifiable:

Canonicalization. JSON has no single byte representation. The signature covers the RFC 8785 (JCS) canonical form of the receipt with signature removed. Without this, two honest implementations can't agree on what was signed.
Salted commitments. input_commitment = SHA-256(salt || canonical_input). Tool inputs often have low entropy (a repo name, an account ID), and an unsalted hash of them can be brute-forced. The salt travels in the evidence bundle, not in the receipt.
Output commitment. The output is the claim. Committing only to inputs proves what the agent was asked, not what it returned.

sequence is monotonic per runtime_id, so gaps or replays inside one session are detectable.

3. Independent verification

The verifier is decoupled from the executor and needs no access to internal databases. Given a bundle containing:

the @ai identity record (resolves agent_id to its key chain)
the Agent Key and Runtime Key certificates
the signed DelegationV1
the ActionReceiptV3
the Merkle inclusion proof
the anchor transaction reference
a revocation snapshot reference

it deterministically checks:

IDENTITY    → agent_id resolves; key chain valid up to root
DELEGATION  → signed by Agent Key, unexpired, tool in scope
REVOCATION  → no key in the chain appears in the anchored revocation list
RECEIPT     → JCS-canonical signature valid under the runtime key, issued_at inside key validity
DAG         → every parent digest resolves to a valid receipt
EVIDENCE    → receipt included under evidence_merkle_root
ANCHOR      → root finalized on the public anchor ledger

Any failed check means reject. There is no "partially verified" state (fail-closed).

Revocation without a database: revocations are signed by the Root Key and anchored the same way as evidence roots. The verifier checks against the latest anchored revocation list, so revocation freshness is bounded by anchoring frequency.

Threat model and known limitations

What this design proves:

A specific runtime key, chained to a specific agent and root, signed this receipt within its validity window.
The action was covered by a signed delegation and policy.
The receipt and its causal history have not been altered since anchoring.

What it does not prove on its own:

Runtime integrity. Signatures prove who signed, not that the environment was clean. Question 2 from the intro needs remote attestation (TEE such as AWS Nitro Enclaves or AMD SEV-SNP, with the runtime key generated inside the enclave and bound to the attestation document).
Truth of tool output. An output commitment proves what the runtime reported, not that the external API really returned it. Closing that gap needs signed responses from the tool provider or independent re-execution.
Revocation freshness. A key compromised between two anchors stays valid until the next anchor.

What's next

Verifiable agent infrastructure means dropping implicit trust: short-lived runtime keys with a full certificate chain, a hash-linked causal DAG, salted input and output commitments, fail-closed verification, and attestation for the parts signatures can't cover.

How are you handling execution proofs and delegation in your multi-agent systems? Tell me in the comments.

DEV Community