03 · Actions: was each delegation checked inside attested hardware?
Verify who delegated what to each agent¶
When one AI agent hands work to another, cA2A records who gave which permission to whom, and lets anyone check that no agent quietly gave itself more. It sits on top of A2A, the common protocol agents use to talk to each other (see the terms, in plain English). Each handoff carries a signed permission slip that can only shrink, each agent can be asked for hardware proof of what it is running, the task can be encrypted so only the checked agent can read it, and each step leaves a signed record you can check offline against a starting authority you chose to trust.
Verify your first delegation chain What this proves, and what it does not
TL;DR
ca2a-runtime 0.4.0 (MIT developer preview; the PyPI name ca2a belongs to an unrelated project) catches an agent that tries to pass on more permission than it was given, offline, with no special hardware and no running agents. Checks of AMD SEV-SNP and Intel TDX hardware reports ran on real Azure and GCP machines, including an Azure agent calling a GCP agent on 2026-07-27, but across clouds the check has only run in one direction so far, and tying the encrypted task to a checked hardware measurement on a live call is on the roadmap.
-
Run it
Check a two-step handoff where the permission narrows, then watch it refuse a starting authority you never trusted and a correctly signed grant that asks for too much. No hardware needed.
-
What it proves, and what it does not
What has been checked on real hardware, what has only been checked in one direction, and what is not checked at all.
-
Hardware evidence
Real AMD SEV-SNP reports from Azure and Intel TDX reports from GCP C3 machines, checked on 2026-07-27. The code that requests those reports ran on real chips on 2026-08-24.
-
The chain
Before it: Agent Manifest describes the agent and issues the narrowed permission. Alongside: cMCP covers an agent's tool calls. Each handoff's record is written in TRACE. Check a real Intel TDX hardware report yourself at agentrust-io.com/verify.
The gap it closes¶
Knowing an agent's name does not tell you what it is allowed to do. When agent A hands a task to B, and B hands part of it to C, the agent receiving the work (the relying party) needs to confirm where the permission started and check every handoff along the way. On a live call it also needs to confirm the caller is who the permission names, apply its own rules, and, if it asks for one, check hardware proof of what the caller is running.
The four primitives¶
| Mechanism | In plain terms | What to check | Start here |
|---|---|---|---|
| Delegation credentials | A signed permission slip per handoff that can only narrow | Trusted root, signatures, continuity, bounded scope and depth | Offline quickstart |
| Runtime appraisal | Hardware proof of what the other agent is running | Evidence and measurements required by the relying party | Attestation |
| Sealed peer channel | The task encrypted so only the checked agent can read it | Payload encryption to the appraised peer key | Sealed channel |
| Linked provenance | A signed record per handoff, each pointing at the one before | Record signatures and parent links | TRACE A2A profile |
Running without special hardware (software mode) gives weaker guarantees than running on confidential-computing hardware. Hardware checks have run in one direction across two clouds, and in both directions between two machines run by one operator on 2026-09-17; both agents proving themselves to each other at the same moment is still open. Read Limitations before relying on a hardware claim.
For how the pieces fit together, read How It Works. The formal rules, with the delegation chain, sealed channel, and conformance requirements, are in Profile.
Status: ca2a-runtime 0.4.0 developer preview · MIT · hosting at the Agentic AI Foundation proposed, not accepted · AgenTrust is an independent open-source project. No company funds, owns or directs it; contributions are voluntary.