The Log Is Not the Grant. An IETF Draft Finally Says So.
draft-kuehlewind-audit-architecture-01, revised 7 September 2026, proposes four separate record classes for auditing agent delegation: what a user asked for, what a tool call actually did, who delegated to whom, and how authorization changed over time. The draft is explicit that this is post-hoc auditing, not session management and not runtime enforcement, and that authorization is time-evolving state to be reconstructed as of the moment an action occurred, not read off whatever is currently known. It remains an individual Internet-Draft with no working group behind it.
Not on its own, and a new IETF Internet-Draft is explicit that it should not be read that way. draft-kuehlewind-audit-architecture, from Mirja Kuehlewind (Ericsson) and Henk Birkholz (Fraunhofer SIT), proposes an architecture for auditing agent-driven interactions across trust boundaries by generating four separate classes of record rather than one undifferentiated log: Interaction Records for user-facing events (prompts, responses, approvals, refusals), Action Records for the system-facing boundary where a tool or service call actually took effect, Delegation Records for authority handed from one actor to another, and Authorization Transition Records for how permission itself changed over time, initial grants, step-up approvals, scope narrowing, revocation and expiry. Revision 01, dated 7 September 2026, generalizes the title from "AI Agent" to "Agent," adds a diagram and section for multi-level sub-agent delegation chains, adds an in-band record-storage architecture option, reorganizes the draft's proposed standardization work items, and, for the first time in the draft's own text, states explicitly that the architecture is inherently post-hoc: it lets an auditor prove after the fact what happened, and it is not itself a session or context-management mechanism, and not runtime enforcement. It remains an Independent Submission Internet-Draft with intended status Informational, authored outside any IETF working group; an accompanying proposal for a BoF and working-group charter on agent auditing was circulated to the OAUTH and WIMSE working-group mailing lists in parallel with the draft and has, per independent reporting, been deferred rather than scheduled.
Every agent-authority record this desk has read for months makes some version of the same argument from a different angle: an event log shows what ran, not what was allowed to run. draft-kuehlewind-audit-architecture is the first IETF-track document this record has found that tries to standardize the fix at the level of what gets recorded in the first place, by refusing to let one record type answer both questions.
Why an ordinary log is not enough, in the draft's own framing
The draft's motivating observation, read via its canonical source and consistent with independent reporting of its abstract, is that existing auditing mechanisms for agent-driven interactions often capture isolated system events but do not consistently represent delegation relationships, user intent, or evolving authorization. Its proposed answer is architectural rather than cryptographic first: distributed audit-record generation at each participating actor, an Audit Context propagated across protocol and administrative boundaries so records from different actors can be correlated, and optional attestation and transparency logging layered on top rather than assumed as a precondition.
Four record classes, not one log
The draft's Section 5 defines four record classes, and keeping them apart is the architectural point rather than an incidental taxonomy choice.
Moona's own Risk Registry already carries the corrective principle behind three of these four classes as separately evidenced weaknesses, not as something this draft introduces for the first time. AEW-011, evidence after the fact mistaken for authorization before it, states the Action Record boundary directly: an audit record proves what happened, not that it was permitted. AEW-006, delegated authority inherited without attenuation, states the Delegation Record boundary: a delegated grant must not exceed its parent's scope, must not outlive its parent's expiry, and must be revocable together with it, which is a fact about the grant, not about whatever record merely notes that delegation occurred. AEW-005, approval not bound to the executed action, is the closest existing match to what an Action Record's own authorization scope/expiry and parent-interaction fields are meant to prevent: an approval whose binding to the exact action it covers cannot be independently checked against what actually ran.
Authorization as an ordered sequence, not a snapshot
The Authorization Transition Record class is the draft's most consequential technical claim for this desk's own purposes, because it names a property Moona's own canonical Authority Resolution engine did not yet represent before this record: that authority for a past action must be reasoned about using the authorization state that was in force when the action occurred, not simply the latest known state. A revocation issued after an action already executed does not retroactively make that earlier action unauthorized; a widening issued after an action executed does not retroactively authorize it either. The draft's own ordered transition sequence exists specifically so an auditor can reconstruct which of those states applied at a given point in the run.
Moona's canonical Decision Context and Authority Resolution v1 model (src/content/moona-knowledge/authority-model.ts, authority-resolution.ts) previously represented temporal authority only as a single flat snapshot, an approval's own stated expiry compared against a proposed execution time, with no way to reconstruct a state that changed more than once relative to when an action actually ran. This record's own evidence closes that specific gap: an evidenced explicitProhibition may now carry its own revokedAt timestamp, distinct from the execution time being reasoned about, so a revocation timestamped after the action it would otherwise deny no longer retroactively denies it, while a revocation timestamped before the action continues to deny it exactly as before. The change is additive and backward compatible: a Decision Context that never sets a transition timestamp resolves exactly as it did before this record existed.
What this architecture explicitly is not
Revision 01 adds language this record reads as its most important scope-limiting statement: the auditing use case this document addresses is inherently post-hoc, it enables an auditor to prove after the fact what happened, and this architecture is not a session or context-management mechanism. That is a direct, first-party disclaimer against exactly the overclaim this desk keeps warning against elsewhere in its own corpus, that a record of an event is not the same fact as control over that event, and that auditability alone does not prevent unauthorized execution. Nothing in this draft proposes to intercept a proposed action before it runs; every record class described above is generated once an interaction, an action, a delegation or a transition has already happened.
What changed from -00 to -01
Independent verification of the two revisions, through the draft's own canonical source repository and its commit history rather than a direct load of the IETF archive pages (see the sourcing note below), confirms five deltas: the title generalizes from "An Architecture for Auditing AI Agent Delegation and Interactions" to "An Architecture for Auditing Agent Delegation and Interactions," broadening the scope beyond AI-specifically-branded agents to complex delegated workloads generally; a new Agent Interaction Workflow section and diagram illustrates chains of agents and sub-agents delegating tasks across multiple levels; the explicit post-hoc, not-session-management statement quoted above was added; a new Section 3.2 describes an in-band record-storage architecture option, where each participating agent runs its own audit store and forwards records to the next agent's store over the same transport connection already in use, trading a separate audit channel for increased trust in the participating parties; and the draft's proposed standardization work items were renumbered and reorganized, spanning canonical data models for the four record classes, a delegation-chain format, a RATS evidence profile, an SCITT transparency-registration profile, an auditor query interface, deployment best practices, and Audit Context propagation through HTTP headers or composite claims.
Where it sits relative to OAuth, WIMSE, RATS and SCITT
The draft positions itself as complementary to, not a replacement for, each of these: it cites RFC 9334 for RATS as the evidence-profile target for its own records, the in-progress SCITT architecture draft for transparency registration and receipt verification, the in-progress WIMSE architecture draft for workload identity, and RFC 6749, RFC 8693 token exchange, and the in-progress OAuth transaction-tokens and identity-chaining drafts as the authorization-protocol layer this audit architecture observes and records rather than replaces. Moona's own dataset already carries several of these as separate Protocol records (the WIMSE delegation-chain draft, the SCITT agent-action-capsule and AI-agent-receipt profiles, and multiple individual OAuth-adjacent agent-authorization drafts); this record connects to them rather than duplicating their evidence.
Current standing, stated plainly
This is an Internet-Draft, not an RFC, not an adopted IETF standard, and not evidence of deployed interoperability or runtime enforcement anywhere. It is an individual submission with intended status Informational; no working group owns it. Independent reporting corroborates that a proposed BoF and working-group charter for agent auditing, circulated to the OAUTH and WIMSE mailing lists alongside the draft's original publication, has been deferred rather than scheduled, and that agent-identity and agent-auditing work more broadly remains scattered across several existing working groups rather than consolidated under one. Revision -00 was published 18 May 2026 and carries a stated expiry of 19 November 2026; revision -01 was published 7 September 2026, and this record could not independently confirm its own expiry date since datatracker.ietf.org and ietf.org were both blocked to direct fetch this session. Whether a -02 revision, working-group adoption, or an eventual RFC ever follows is unknown, and this record does not infer an answer from the draft's own substance.
Sourcing limits, stated directly
datatracker.ietf.org, www.ietf.org, mailarchive.ietf.org and author-tools.ietf.org were each blocked by this session's network egress policy on every attempt, the same policy-level block this desk's other IETF-draft records already document, so this record was not built from a direct load of the draft's own IETF-hosted archive pages or its official iddiff. What follows instead is real, independently checked evidence rather than search-only corroboration: the draft's own canonical source repository, github.com/mirjak/draft-audit-architecture, linked from the draft's own front matter as its editor's copy, was reachable directly this session, and this record's account of the four record classes, the post-hoc/not-session-management statement, the in-band record-storage subsection, the Agent Interaction Workflow section, and the work-item reorganization is drawn from that repository's own markdown source and its commit history, read through this session's fetch tooling rather than a locally supplied full-text file. That is a real primary-adjacent source, the draft's own editor's copy, but this record still grades every substantive property below documented rather than verified: this session did not itself perform a byte-level read of the complete revision text the way this desk's own AAE-02 record could when a full local copy was supplied, and it did not independently confirm that the repository's current state matches revision 01 specifically rather than a later, uncommitted or in-progress state. -00's own metadata, its publication date, expiry, Independent Submission stream, and the deferred-BoF status, is corroborated through convergent, independently phrased web search against IETF Datatracker content and an OAUTH-WG mailing-list thread, at the same evidentiary level this desk applies to every other blocked-source IETF record it carries. A future editor with unblocked access to ietf.org should fetch both revisions directly and confirm every property below at the verified grade before this record is upgraded.
Sources
This analysis interprets third-party reporting, research and announcements. Moona is not the original reporter of the underlying events.
Protocol evidence
This record does not assess these architectures. The connection runs through the Risk Registry requirement each one bears on, and these published authority architectures are what the evidence says about that requirement.
Protocol evidence related through AEW-011 Evidence after the fact mistaken for authorization before it
- Supports requirement
A Black Box for Agentic Processes
Arslan Bromme (independent research, arXiv preprint)
Requirement The paper's own evidence model separates temporal anchoring and artifact integrity from event ordering, capture authenticity, authorized anchoring and causal traceability
This weakness's own authority gap states that evidence made after an action is not the authorization decision made before it. This paper's own evidence model draws a closely related separation from a different starting point, stating directly that digest verification establishes only that a retained artifact matches a prior commitment, not that the underlying event was captured completely or faithfully, occurred in the order a chain of anchors implies, was anchored by an authorized party, or is true. It supports the requirement that a Moona reasoning surface never let evidence integrity alone stand in for authorization or captured truth, rather than implementing an enforced version of that separation, since the paper itself proposes no mechanism that checks these properties against each other.
- Supports requirement
A Black Box for Agentic Processes
Arslan Bromme (independent research, arXiv preprint)
Requirement Anchoring or timestamp order between two committed events is explicitly not treated as proof of causal or workflow order
This weakness already treats a record made after an action as distinct from authorization of that action; this property extends the same discipline to a narrower claim this weakness's own known examples had not yet named directly, that the order in which two events are anchored or timestamped reflects anchoring and confirmation mechanics rather than the causal order of the underlying workflow. It supports requiring an explicit dependency link before an anchored or timestamped order is read as proof that one recorded action caused or authorized another.
- Supports requirement
A Black Box for Agentic Processes
Arslan Bromme (independent research, arXiv preprint)
Requirement The paper frames its use for governance, risk and compliance evidence, incident reconstruction and regulatory reporting readiness, not as a preventive control
This property frames blockchain anchored agent evidence as governance, risk and compliance and regulatory reporting readiness infrastructure, not a preventive control, the same record versus gate separation this weakness already states as its own authority gap. Gartner's Audit AI: A Practical Guide for CAEs, published 9 September 2026, is independent, non technical, practitioner side evidence that the internal audit profession names the identical need from its own side: it reports a gap between audit leaders who name AI governance a 2026 priority (83 percent) and those confident they can address it (34 percent), names limited visibility into deployed AI as the assurance risk underneath that gap, and recommends audit ready evidence generated during work rather than reconstructed afterward. That recommendation supports this property's own post hoc, not preventive framing without establishing that any specific construction satisfies it.
- Supports requirement
Agent Infrastructure Control Protocol (AICP)
Tihan-Nico Paxton, Apollo Deploy (individual submission to the IETF)
This weakness's own corrective principle keeps a decision record produced before execution separate from a log produced after it, and forbids treating prose as the control. AICP's own Section 5.5 states directly that a client must not treat prose as authorization, executable instructions, a replacement for a stable code, or a reason to violate a structured constraint, and Section 12.1 restates the same discipline for a Problem's own human readable detail member specifically, stating that a client bases retry and recovery decisions on the stable code and structured fields, not the prose. Section 11.3 extends the same separation to evidence itself: access to an Evidence Reference must be independently authorized and must not be granted merely because a client can read an Outcome. Recorded as design evidence for the requirement this weakness already states across its whole object model, not as a claim that any provider has implemented this draft's text.
- Supports requirement
An Architecture for Auditing Agent Delegation and Interactions (audit-architecture)
Mirja Kuehlewind (Ericsson) and Henk Birkholz (Fraunhofer SIT), individual submission to the IETF
Requirement Auditability is built from four separate record classes rather than one undifferentiated log
This weakness's own corrective principle requires a decision record produced before execution to be kept separate from a log produced after it, and treats audit evidence and authorization as separate obligations. The draft's own four record classes are exactly that separation made structural rather than left to convention: an Action Record documents that a tool or service call took effect, and an Authorization Transition Record, a distinct class with its own ordered previous-state/new-state sequence, is what actually tracks whether that effect was authorized. Recorded as design evidence for the weakness's own principle, not as a claim that any implementation of this record model exists outside the draft's own text.
This record is the cited evidence for this relationship.
- Supports requirement
An Architecture for Auditing Agent Delegation and Interactions (audit-architecture)
Mirja Kuehlewind (Ericsson) and Henk Birkholz (Fraunhofer SIT), individual submission to the IETF
Requirement The draft states directly that this architecture is post-hoc auditing, not session management and not enforcement
This weakness names the confusion between an audit record and a pre-execution control directly: presenting an after-the-fact record as if it governed the decision leaves the actual decision ungoverned. Revision 01 of the draft states, in its own words, that the architecture it describes is post-hoc and is not a session or context-management mechanism, a first-party statement of exactly this weakness's own boundary rather than an implicit assumption a reader has to supply.
This record is the cited evidence for this relationship.
- Supports requirement
EP Authorization Receipts (EMILIA Protocol)
Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF
Requirement The draft states directly that a receipt is evidence, not authorization, and that it does not treat a local human interaction as an authorization decision
EMILIA states directly that a receipt is evidence, not authorization, and that the decision remains with the authorization server. That is the exact line this weakness says products blur when they present an audit archive as a control.
Protocol evidence related through AEW-005 Approval not bound to the executed action
- Supports requirement
Agent Flight Recorder
Laurent Bindschaedler, Quentin Botha, Christoph Siebenbrunner (independent research, arXiv preprint)
Requirement Cryptographic binding of the approval field to the approver's identity and the specific action is described as a production deployment property, not an unconditional schema guarantee
This weakness's own known examples are, across every one of them, a case where an approval attached to nothing verifiable or a later state change went unchecked against a prior decision. Agent Flight Recorder's own schema keeps a human approval field and an execution field as two independently checkable facts rather than one narrative line, which is a direct answer to the underlying need this weakness names: an approval must bind to a specific action, not merely occur near one. It supports that requirement rather than implementing an enforced version of it, because the reported cryptographic binding of the approver's identity to the specific action applies only in production deployments of the construction, not as an unconditional schema guarantee, and the mechanism records the approval/execution relationship for later forensic inspection rather than checking it before the action dispatches the way EMILIA's action hash rejection or Codex CLI's authorization freshness recheck do.
- Supports requirement
Agent Infrastructure Control Protocol (AICP)
Tihan-Nico Paxton, Apollo Deploy (individual submission to the IETF)
Requirement An accepted approval binds cryptographically or transactionally to one exact plan revision
This weakness's own corrective response pattern calls for binding an approval to the exact action object by hash or an equivalent identity, and rejecting execution when the action presented for review differs from the action about to run. AICP's own Section 9.4 requires an accepted approval to be cryptographically or transactionally bound to the Plan identifier, exact revision, approving principal, material changes and expiry, stating directly that approval of prose alone is insufficient and that a changed revision is not authorized by the old approval. The HTTP binding in Section 14.5 enforces the same binding mechanically, through a conditional request against the Plan's strong entity tag. Recorded as design evidence for the requirement this weakness already states, not as a claim that any provider has implemented this draft's text.
- Supports requirement
An Architecture for Auditing Agent Delegation and Interactions (audit-architecture)
Mirja Kuehlewind (Ericsson) and Henk Birkholz (Fraunhofer SIT), individual submission to the IETF
Requirement Authorization is modeled as an ordered sequence of transitions, not a single current value
This weakness's own response pattern calls for recomputing an approval's binding to the exact action at the enforcement point rather than trusting an earlier decision, including the temporal window that decision was made under. The draft's Action Record carries an authorization scope and expiry alongside the action it bears on, and its Authorization Transition Record class exists specifically so the state in force at a given point in a run can be reconstructed rather than assumed from whatever is currently known. Recorded as design evidence for the general response pattern; this record's own evidence separately connects to a targeted extension of Moona's canonical Authority Resolution engine closing the equivalent gap in Moona's own runtime reasoning, not a claim that this draft's own text was implemented anywhere.
This record is the cited evidence for this relationship.
- Supports requirement
ChainIT Authority Protocol and Agent Subject Profile for pre execution authority validation
ChainIT
Requirement A canonical transaction digest is described binding payer, payee, destination, amount, currency or asset and payment rail to approval and execution
A canonical transaction digest binding payer, payee, destination, amount, currency or asset and payment rail to both approval and execution is a direct, more specific response to an approval that attaches to nothing in particular. This is the corrective this weakness describes, named at the level of concrete payment fields rather than a generic hashed parameter set.
- Supports requirement
Codex CLI 0.151.0, restored permission profiles and authorization bound Guardian classifications
OpenAI
Requirement A cached low risk score is checked against the current authorization state before it is allowed to approve, and a mismatch defers to strict review rather than proceeding
Codex CLI's own fix rechecks a cached decision against current authorization state before it is allowed to approve anything, refusing to let a decision computed under one state keep approving after that state has moved. Claude Code's own current plugin marketplace documentation, read directly, describes an installed plugin auto-updating on a version, commit or content digest signal with no described mechanism to diff, flag or gate a change to the plugin's own hooks.json specifically, so whatever authority a user's earlier trust decision represented is not shown to be rechecked once a later update changes what that plugin's bundled hooks execute. Codex CLI's own mechanism is the corrective the reviewed documentation does not describe for this specific binding.
- Supports requirement
EP Authorization Receipts (EMILIA Protocol)
Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF
Requirement Implementations MUST reject an approval request whose action hash does not match a locally recomputed hash of the presented Action Object
EMILIA's requirement that an approval be rejected unless the action hash matches a locally recomputed hash of the exact action object is the binding these cases lack, where an approved command's behaviour is decided by state the approval never inspected.
- Supports requirement
EP Authorization Receipts (EMILIA Protocol)
Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF
Requirement Offline verification does not establish current revocation status, and the draft requires a relying party to apply current policy and current status inputs before any new reliance decision
UiPath Maestro's own default on Refresh schema before call setting keeps an MCP tool's technical interface current immediately before each call, but nothing in UiPath's own documented behavior establishes that the parameter authority a workflow's configuration granted against the original schema is re evaluated once a later schema changes underneath it. That gap, a technically current interface with no stated authority re evaluation behind it, is exactly the condition EMILIA's own requirement, that a relying party apply current status rather than historical acceptance before a new reliance decision, exists to close. UiPath's mechanism supports the need for that requirement rather than implementing it, the distinction this dataset already keeps between this property's two linked entries. A preprint posted to arXiv on 3 September 2026, 2609.03340, Fresh Memory, Stale Plans, restates the same distinction for a derived plan specifically: an executor that has read a superseding revision of a shared requirement into its own memory can still execute a plan derived from the earlier revision, since refreshing the executor's memory does nothing to a plan already computed from the state that memory has since moved past, so current state and current authorization for a pending action are two different facts. Read at the manual review evidence level, corroborated through convergent search rather than a direct read of the primary text, since arxiv.org and every mirror this record attempted were blocked at this session's network egress proxy; treated as further support for the requirement, not as an implementation of it.
- Supports requirement
N-AALP, Native Agentic Application Layer Protocol (draft-bubblefish-naalp)
BubbleFish, individual submission to the IETF
Requirement A signed-action-object model with a content-bound Approval and a single-use consume ledger is reported, not independently verified
This weakness's own response pattern calls for binding an approval to the exact action object, by hash or an equivalent identity, rather than to a name or a connection. The reported mechanism, an Approval bound under signature to the content id of the exact canonical argument object and, for an MCP call, a tool_id and args_id together, so a changed tool description or changed arguments yields a different approved call identity, would be a clean instance of exactly that pattern if it accurately reflects the draft's own filed text. This session could not independently verify that text through any reachable primary or secondary source, so this link is recorded conditionally: design evidence for the weakness's own already-established requirement, not confirmation that this specific draft implements it.
- Supports requirement
N-AALP, Native Agentic Application Layer Protocol (draft-bubblefish-naalp)
BubbleFish, individual submission to the IETF
Requirement A durable single-use consume ledger, and a stated limit that offline verification proves validity at issue, not current unspentness, are reported, not independently verified
This weakness's authorityGap states that authority attaches to what was presented for review, not automatically to whatever executes afterward; an approval a durable ledger has already recorded spent is not, in any meaningful sense, still attached to a further execution. The reported single-use consume ledger, and the reported statement that offline cryptographic verification proves validity at issue rather than current unspentness, would instantiate that gap precisely for a signed approval's own consumption state rather than its identity binding. Unverified by this session for the reason stated above; this record's own independent contribution is the additive extension it separately motivated to Moona's canonical Authority Resolution engine (an evidenced approval's singleUse/consumed state, consulted only when singleUse is evidenced true), which does not depend on this specific draft's own claims being confirmed.
- Supports requirement
The Missing Execution-Finality Protocol Layer of the Internet (draft-das-execution-finality-protocol-layer)
Sangram Das, individual submission to the IETF
Requirement A validated Candidate Act may produce a narrowly scoped, non-bearer Execution Handle bound to that one act and to the Finality Sink that will consume it
This weakness's own response pattern calls for binding an approval to the exact action object and recomputing that binding at the enforcement point rather than trusting possession of a credential. The non-bearer Execution Handle, corroborated through convergent search rather than a direct read of the filed text, generalizes exactly that principle to a credential class broader than one interface family: a validated Candidate Act may produce a handle scoped narrowly to that one act, and possessing the handle is not itself proof the currently presented act still matches the one it was issued for. Recorded as documented design evidence restating this weakness's own already-established requirement at a general level, not as independent confirmation that this specific umbrella draft's own mechanism is demonstrated running anywhere.
- Supports requirement
The Missing Execution-Finality Protocol Layer of the Internet (draft-das-execution-finality-protocol-layer)
Sangram Das, individual submission to the IETF
Requirement Formalizes Candidate Act, Non-Effective State, Protected Enforcement Domain, Execution Handle and Finality Sink as shared vocabulary for a family of domain-specific drafts
This weakness's own known examples had, before this addition, connected to draft-das-agentic-tool-binding-03 as though it were a freestanding architecture. Convergent search corroborates this draft as the umbrella that sibling instantiates: a Protected Enforcement Domain validates authority scoped to an act's purpose, destination, jurisdiction, freshness, revocation state, policy epoch, runtime integrity and effectuation-boundary identity together, a broader validation surface than the tool-binding draft's own two directly verified consequence classes. Recorded as design evidence for this weakness's own binding requirement at the general architecture level; this session located no reference implementation for this specific umbrella draft and does not treat any part of it as independently verified running code.
- Supports requirement
The Missing Execution-Finality Protocol Layer of the Internet (draft-das-execution-finality-protocol-layer)
Sangram Das, individual submission to the IETF
Requirement Fails closed on missing, stale, mismatched, replayed or unverifiable context
This weakness's own response pattern calls for rejecting execution when the action presented for review differs from the action about to run, rather than proceeding on a default allow. The signal that prompted this record carries a five-item fail-closed enumeration, missing, stale, mismatched, replayed or unverifiable context, consistent with the fail-closed behavior this weakness's own draft-das-agentic-tool-binding-03 known example already verified directly in running code for one narrower mechanism. This session's own independent search did not itself return that exact enumeration from a secondary source, so this link is recorded as documented design evidence consistent with corroborated evidence, not as independently re-confirmed word for word against the filed text.
- Supports requirement
tool_use Is Not invoke(): Binding Execution Finality to Agentic Tool Call Interfaces and MCP (agentic-tool-binding)
Sangram Das, individual submission to the IETF
Requirement Authority is scoped to one Candidate Act through a deterministic digest of its own exact arguments
This weakness's own response pattern calls for binding an approval to the exact action object by hash or an equivalent identity and recomputing that binding at the enforcement point rather than trusting the request. Act Bound Authority, confirmed directly this session from the draft's own reference implementation, is exactly that binding applied to tool dispatch: a deterministic digest computed over a Candidate Act's own exact arguments, so authority issued for one call cannot be presented for a different call bearing different arguments even under the same session or workload. Recorded as design evidence independently demonstrated in running reference code, not as a claim that this specific implementation is deployed anywhere.
- Supports requirement
tool_use Is Not invoke(): Binding Execution Finality to Agentic Tool Call Interfaces and MCP (agentic-tool-binding)
Sangram Das, individual submission to the IETF
Requirement A Finality Sink verifies authority atomically immediately before invoke() runs, fail closed on any failure
This weakness's own response pattern calls for recomputing an approval's binding at the enforcement point rather than trusting an earlier decision. The Finality Sink, confirmed directly this session from the reference implementation's own sink module, is that enforcement point positioned immediately before the underlying invoke() call, verifying authority atomically and blocking execution whenever verification does not succeed rather than proceeding on a default allow. Recorded as design evidence for the same requirement EMILIA's own action-hash rejection requirement already formalizes for payment operations, applied here to tool dispatch generally.
- Supports requirement
tool_use Is Not invoke(): Binding Execution Finality to Agentic Tool Call Interfaces and MCP (agentic-tool-binding)
Sangram Das, individual submission to the IETF
Requirement Each parallel tool call requires its own independently computed authorization
None of this weakness's own known examples had, before this addition, named independent authorization for concurrent tool calls specifically. The reference implementation's own test scenarios, read directly this session, decide a parallel search plus unauthorized payout case as two independent authorization decisions rather than one session-level trust judgment covering an entire batch, closing a gap this weakness's own binding requirement implies but had not yet evidenced concretely for parallel dispatch.
- Supports requirement
tool_use Is Not invoke(): Binding Execution Finality to Agentic Tool Call Interfaces and MCP (agentic-tool-binding)
Sangram Das, individual submission to the IETF
Requirement A retried or replayed call presenting already-consumed authority is denied
This weakness's own known examples document an approval or a cached decision surviving a state change it never accounted for; none had yet named a retried or replayed call presenting already-spent authority as its own distinct axis. The reference implementation's own replay store, read directly this session, marks authority consumed atomically on first use and denies a subsequent presentation of the same authority, with the implementation's own stated limitation that this protection is local rather than distributed. Recorded as design evidence for a property this weakness's own response patterns imply but had not yet evidenced at this level of precision.
- Implementation evidence
EP Authorization Receipts (EMILIA Protocol)
Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF
Requirement Implementations MUST reject an approval request whose action hash does not match a locally recomputed hash of the presented Action Object
MoonPay's PayBox documents that any change to an operation's amount, merchant, destination, contract, function or secret name after submission forces a fresh approval request rather than letting the original one carry over. That is the same operation-bound approval EMILIA's action-hash rejection requirement formalizes cryptographically, arrived at independently in a live consumer product rather than a draft specification, which corroborates that the requirement is buildable outside a standards process.
- Implementation evidence
EP Authorization Receipts (EMILIA Protocol)
Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF
Requirement Offline verification does not establish current revocation status, and the draft requires a relying party to apply current policy and current status inputs before any new reliance decision
Codex CLI's own merged fix binds a cached Guardian v2 classification to the exact authorization state it was scored against and refuses to let it approve an action once that state has moved, arrived at independently in a shipped product rather than a draft specification. That corroborates EMILIA's own requirement that a relying party apply current status inputs before a new reliance decision rather than treat historical acceptance as still current, the same binding failure this weakness already describes. OpenMAIC's own 1.0.1 fix, read directly by this dataset, applies the identical principle to a network destination rather than a cached score: fetchWithRedirectValidation re-runs validateUrlForSSRF against every redirect hop before following it, rather than treating the single validation performed against the caller's originally supplied bring your own key base URL as still current once an ordinary HTTP redirect substitutes a different destination. A third independent, shipped instance of the same requirement, this one at a network authority boundary rather than at an approval or a classification.
- Missing requirement
ChainIT Authority Protocol and Agent Subject Profile for pre execution authority validation
ChainIT
Requirement No canonicalization algorithm, serialization format or independent test of the transaction digest against a live or reference transaction was found
Naming the fields a digest binds is not the same fact as a demonstrated binding. No canonicalization algorithm, serialization format or independent test of the digest against a live or reference transaction was found, so whether an executed transaction can be proven identical to the one approved remains a missing requirement rather than a closed one.
- Missing requirement
Codex CLI 0.151.0, restored permission profiles and authorization bound Guardian classifications
OpenAI
Codex CLI's own shipped Guardian v2 fix binds a cached tool call classification to the exact authorization state it was scored against, refusing to let a stale classification approve a call once that state has moved. GitHub issue 43549, read through this session's own automated web fetch and summarization tool, reports a materially different gap this record's own reviewed material states nothing about: whether a tool call's own reported terminal status, here the literal status aborted following the caller's own interruption, is checked against the account level effect that call already produced before reporting that status. The reviewed protocol record binds a decision to the state it was made under; it does not, on the material available to this session, bind a call's own reported outcome to the state the call actually left behind.
- Missing requirement
tool_use Is Not invoke(): Binding Execution Finality to Agentic Tool Call Interfaces and MCP (agentic-tool-binding)
Sangram Das, individual submission to the IETF
Requirement The reference implementation ships under a restricted evaluation license, not open source
Demonstrating a binding mechanism in reference code is not the same fact as that mechanism being available for production adoption. This session's own direct read of the reference implementation's LICENSE.md confirms a source-available evaluation license, not open source, explicitly denying production deployment and commercial use and reserving patent rights outside evaluation. Recorded as a missing requirement for anyone evaluating this reference implementation as a buildable corrective rather than as design evidence, not as a claim against the underlying architecture the draft itself describes.
Protocol evidence related through AEW-006 Delegated authority inherited without attenuation
- Supports requirement
Agent Flight Recorder
Laurent Bindschaedler, Quentin Botha, Christoph Siebenbrunner (independent research, arXiv preprint)
Requirement Delegation provenance (the requesting agent's identity, the parent event's hash, and the delegated scope) is recorded per event, but attenuation of that scope is not itself enforced
This weakness names authority spreading past its granted boundary because a delegated grant is not checked for narrowing, expiry, or revocability against its parent. Agent Flight Recorder's own delegation provenance field records a requesting agent's identity, a parent event's hash, and a delegated scope per event, which would let an investigator reconstruct after the fact whether a given delegation ever attenuated relative to its parent. That is evidence supporting the need for an attenuation check, not an attenuation check itself: nothing in the material available to this record describes the construction rejecting, narrowing, or expiring a delegated scope at the point delegation happens, only recording what was claimed about it.
- Supports requirement
An Architecture for Auditing Agent Delegation and Interactions (audit-architecture)
Mirja Kuehlewind (Ericsson) and Henk Birkholz (Fraunhofer SIT), individual submission to the IETF
Requirement The draft keeps a Delegation Record's existence separate from the delegatee's current effective authority
This weakness's own corrective principle states that a delegated grant must not exceed its parent's scope, must not outlive its parent's expiry, and must be revocable together with it. The draft's own separation of a Delegation Record, which states that a delegation occurred, from an Authorization Transition Record, which states the delegated scope's current standing, is structural support for exactly that principle: evidence that authority was delegated is kept apart from evidence of the delegatee's currently effective authority, rather than one record class being asked to carry both facts. Recorded as design evidence for the attenuation principle this weakness names, not as a claim that any implementation of it exists outside the draft's own text.
This record is the cited evidence for this relationship.
- Supports requirement
ARC, Agentic Runtime Control
Britive
Requirement Elevated privilege is documented as minted directly in a target system through its own native API and revoked automatically when a task ends, with credential brokering as a separate path for systems that require one
Britive's own documented model brokers or mints credentials ephemerally and scoped to a task, rather than leaving a standing credential ambiently reachable by whatever caller happens to connect. argocd-mcp's pre fix ARGOCD_API_TOKEN is the failure that principle answers, made concrete at an MCP server rather than at the CI or SSH targets Britive's own material names: a standing, environment configured credential, reachable in full by any network caller whose request the server's own credential check would accept regardless of what, if anything, the request itself supplied. The shipped fix, a separate MCP_AUTH_TOKEN, narrows who can reach the server at all rather than narrowing or brokering the ARGOCD_API_TOKEN itself, which remains one long lived, ungraded credential shared across every holder of the new inbound token.
- Supports requirement
Cross App Access (XAA), Okta Agent SSO and MCP Enterprise-Managed Authorization
Okta
Requirement Enterprise Managed Authorization governs the cross app connection, not the individual action an agent later attempts
Cross App Access places the decision of which requesting identity may open a connection to a resource application with the enterprise identity provider and an administrator's own configured policy, independent of whether that resource application, or a server fronting it, is separately reachable inside the same environment. That connection level, principal specific decision is the same corrective github/gh-aw's own merged fix applies to a dynamically registered GitHub MCP backend: a backend's registration for one principal's delegated use is deliberately not read as a connection grant for a different principal, which must clear its own independent check.
- Supports requirement
Grantex and the Delegated Agent Authorization Protocol (DAAP)
Sanjeev Kumar, Grantex
Requirement Child scopes MUST be a subset of the parent's scopes, and a child may hold exactly the parent's scopes
Grantex enforces that a child grant's scope is a subset of its parent's and its expiry the earlier of the two, which is the attenuation these inheritance and shared credential failures lack. Unit 42's account of a real enterprise intrusion, corrected 3 September 2026 to clarify the event was an intrusion rather than ransomware, is a longer instance of the same missing attenuation: credentials a reconnaissance and repository search step discovered reached a secrets manager, then CI/CD and cloud identity, with no subset or expiry check narrower than what each step happened to find described at any hop.
- Supports requirement
Verifiable Attenuated Delegation for AI Agent Chains (draft-asor-wimse-agent-delegation-chain)
Rafael Asor, Attenu
Requirement A child's authority must be a verifiable subset of its immediate parent's: scopes under the wildcard containment rule, every parent constraint present and equal or narrower in the child, and expiry and delegation depth no greater than the parent's
The draft requires a child's scopes, ceilings, constraints and expiry to be a verifiable subset of its immediate parent's, cryptographically checkable offline through a parent hash, which is the attenuation these inheritance and shared credential failures lack. OpenCode issue 47819 documents the same missing subsumption check at the level of a single agent's own permission configuration: the merge composing a custom agent's frontmatter block against the platform's own defaults is a union of the two rather than a verified subset of the wider one.
- Supports requirement
Verifiable Attenuated Delegation for AI Agent Chains (draft-asor-wimse-agent-delegation-chain)
Rafael Asor, Attenu
Requirement Revision 01 adds a min constraint type whose safe attenuation direction is upward, a floor that can only rise as authority narrows
Revision 01's own min constraint, and its explicit statement that a maximum narrows downward while a minimum narrows upward, makes precise a point this weakness otherwise leaves implicit: narrowing is not one direction for every dimension of authority, and a delegation mechanism that only checks subset and shorter expiry can miss a floor that widened rather than a ceiling that loosened.
- Reveals bypass
Agent Identity and Agent Identity Auth Manager
Google
Requirement Agent identities are not shared by multiple workloads by default, cannot be impersonated, and do not allow long lived keys
Google's own comparison states that an agent identity, unlike a service account, is not shared by multiple workloads by default, cannot be impersonated and does not allow long lived keys. argocd-mcp's own ARGOCD_API_TOKEN is exactly the shape this property contrasts against: one long lived, environment configured credential, shared by construction across every caller able to reach the server, with nothing this entry's own reading of the affected source found narrowing which caller could exercise it. This does not fault Google's own architecture, which the property itself only describes rather than mandates elsewhere; it evidences why the comparison the property draws is the attenuation this weakness's own known examples keep missing.
- Reveals bypass
AI Agent Identity Certificate (AIC) extension for X.509 v3
Jijie Wei, individual submission to the IETF
Requirement Authority can go stale after issuance
AIC's authorized mode locks the permission set into the certificate at issuance, so authority can go stale: a change to the principal's grants after issuance does not reach an already issued certificate, a delegation gap the inheritance failures illustrate.
- Reveals bypass
Verifiable Attenuated Delegation for AI Agent Chains (draft-asor-wimse-agent-delegation-chain)
Rafael Asor, Attenu
Requirement Nothing in the token profile establishes that the root token holder was actually entitled to grant the authority the root token represents
A verified chain proves lineage forward from a trusted root key, not that the root holder was ever entitled to the authority it represents, so a mistaken or illegitimate grant at the root produces a chain every hop of which still narrows correctly, an inheritance failure the subsumption check alone does not reach.
Protocol evidence related through AEW-027 A persistent effect survives the revocation of the authority that created it
- Supports requirement
An Architecture for Auditing Agent Delegation and Interactions (audit-architecture)
Mirja Kuehlewind (Ericsson) and Henk Birkholz (Fraunhofer SIT), individual submission to the IETF
Requirement Authorization is modeled as an ordered sequence of transitions, not a single current value
This weakness names the gap between authority admitted at one moment and authority actually in force at a later moment of consequence, evidenced elsewhere in this registry by CONTINUITY's REVOKED_GRANT and EXPIRED_RELEASE fault classes. The draft's Authorization Transition Record class is the audit-record-format mirror of exactly that property: an ordered previous-state/new-state sequence built so an auditor can reconstruct which state was in force at a specific point in a run, rather than reading the latest known state back over an earlier moment. Recorded as design evidence for the weakness's own principle in the reverse temporal direction, a later revocation must not retroactively deny an earlier, then-still-authorized action; this record's own evidence separately connects to a targeted extension of Moona's canonical Authority Resolution engine implementing exactly that reconstruction for one specific field.
This record is the cited evidence for this relationship.
- Missing requirement
Grantex and the Delegated Agent Authorization Protocol (DAAP)
Sanjeev Kumar, Grantex
Requirement Cascade revocation stops future use of descendant grants; nothing found addresses reversing an action a now revoked grant already authorized
This property, verified directly against Grantex's own specification, already records that cascade revocation stops future use of a revoked grant's descendants but that nothing found addresses reversing an action a grant already authorized before it was revoked. Ruflo's own remediation guidance for CVE-2026-59726 is concrete evidence for exactly the same shaped gap one layer further in: an attacker's live access to the MCP bridge was closed by version 3.16.3, and closing it did nothing to whatever the attacker had already written into AgentDB while that access was open, which is why Ruflo's own operators are separately instructed to audit and purge the learning store rather than trust the version upgrade alone. Recorded as a missing requirement because both the specification and this concrete instance name the same unresolved question, whether ending an authority retroactively settles what that authority already produced, without either one describing a mechanism that answers it.
- Missing requirement
x401, the HTTP Proof Requirement Protocol
Proof, with editors from Proof and Circle and reviewers from Lightspark, MATTR, Okta, OpenAI and Visa
Requirement Whether revoking the underlying mandate or credential immediately invalidates an already issued Verification Token is undocumented
This property, verified directly against the base x401 specification, already records that the specification does not state what happens to an already issued Verification Token if the credential or delegation evidence behind it is later revoked, and that no revocation endpoint or propagation rule was found. Ruflo's own incident is the same unresolved question realised as a concrete consequence rather than an acknowledged gap in a draft: an attacker's access was revoked by the fixed bridge, and the persistent state that access had already produced, an AgentDB pattern store entry, is not described anywhere in Ruflo's own material as automatically invalidated by that revocation. Recorded as a missing requirement rather than a supported one, since neither the specification nor Ruflo's own remediation describes a mechanism that propagates a revocation into previously produced, persistent effects; both leave that step to a separate, manual action.