Summary

  • The 1 November revision of an individual IETF agent-execution draft replaces a rule that checked every actor with one that checks the current actor and the token's top-level claims.
  • Earlier agents stay in the audit chain. If one is later suspended, the receiving service cannot reject the next call on that basis under the draft's admission rule.

Imagine a request passing from one AI agent to another until it reaches a service with the actual switch. The service receives a token carrying the chain. One earlier agent has since been suspended. Should the switch close? In revision 02 of the Agent Execution Evidence draft, the answer under the proposed admission rule is no: the receiving party tests the principal and the current actor. The earlier name is for the record.

That is a correction with teeth. Revision 01 said the serving party evaluates every actor. The new text removes that instruction and says prior actors identified in nested act claims must not decide admission. The change follows RFC 8693's token-exchange rule, which treats the top-level claims and current actor as access-control inputs and earlier actors as informational history. The authors say the posted -01 used an earlier commit that missed this Actor Chain revision.

The draft does not erase the past. It would record actor_chain and link receipts on both sides of a call. A later verification can show that work continued after an upstream agent was suspended, who admitted each hop, and what admission_basis each receiver recorded. That is an investigator's trail, not a stop button at the last gate. The draft says so directly in its introduction and security discussion.

Nor can the chain certify its own story. At admission, it is history asserted by the token issuer. Matching chains across the receipts available to a verifier establish consistency; they cannot prove that every hop is present or that authority narrowed at each handoff. The draft requires fresh enough status for the calling agent's assurance and registration, and restricts a currently limited agent to its permitted operations. It has no comparable prior-actor suspension veto.

Section 14 leaves the obvious next move as an open issue: a separate full-history admission profile, with rules for completeness, trust and its conflict with RFC 8693. The IETF Datatracker lists this as an individual draft, last updated 1 November. It is a proposal, with no deployment result offered here. The missing fact that would change the operational judgment is a specified and implemented rule that actually checks upstream status before admission.