| Internet-Draft | Agent Action Determinability | September 2026 |
| Wadkins | Expires 14 March 2027 | [Page] |
Evidence that an agent was authorized to act does not establish that the authorization was enforced, that the action was executed, or that the intended effect occurred. These are distinct transitions.¶
This document defines requirements for making a claimed agent transition independently determinable after the original interaction has ended. The requirements address binding the material action and governing conditions to the transition at decision time, identifying which revision of a mutable governing artifact was in force, preventing later substitution, and preserving enough information for an independent evaluator to establish the claimed transition after participants, sessions, credentials, keys, or agent instances are no longer available.¶
This document defines no evidence format, token, action identifier, delegation protocol, audit system, registry, or transparency service.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 14 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Agent systems cross several distinct boundaries, and evidence that one was crossed is not evidence that a later one was.¶
A signed authorization can prove that an issuer made an authorization statement. It does not, by itself, prove that the authorization constrained execution. A dispatch record can prove that work was handed to an executor. It does not prove that the work was performed. An execution record does not necessarily prove that the intended external effect occurred.¶
These distinctions matter when the question is asked after the fact. In out-of-band infrastructure management, an agent may hold standing authority to act on a device that is unreachable through the production network, under a policy the device owner maintains and the responding party does not. When the change is later disputed, the responding party is asked which policy permitted it, whether that policy was the one in force when the agent acted, and whether the agent was still authorized at that moment rather than only at the time its credential was issued. Records built to answer the first question routinely cannot answer the second or the third.¶
This document uses T for the event or ordering point at which the transition being examined occurs or becomes effective, and T+n for a later point at which a party that need not have participated at T attempts to determine what happened.¶
The problem is narrow: if a specification claims that a transition can be determined at T+n, what must have been bound at T so that the claim does not depend on reconstruction, later selection among candidate conditions, or continued cooperation from the original participants?¶
This document does not require evidence for every transition. It requires a specification that claims a transition is retrospectively determinable to identify what establishes that transition and not infer it solely from evidence of another transition.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Evidence used to establish a transition at T+n MUST identify the material action and the transition being claimed with enough specificity to distinguish them from materially different actions or transitions.¶
Where governing conditions are material to the claim, the evidence MUST also identify the governing conditions claimed for that transition. If a governing condition is a mutable policy, ruleset, or other artifact, the evidence MUST distinguish the specific revision that governed the transition. Where the source of that revision is material to the claim, the evidence MUST identify the party that issued or ratified it.¶
Evidence of one transition MUST NOT, by itself, be treated as evidence that a different transition occurred.¶
For example, evidence of authorization is not by itself evidence of enforcement, and evidence of dispatch is not by itself evidence of execution or effect.¶
Where a specification claims that governing conditions controlled a transition, the verification procedure MUST establish that those conditions actually governed the transition at T and that the required binding was fixed no later than T. For a mutable governing artifact, this includes establishing which revision was in force at T.¶
Where a prior declaration or commitment is claimed to constrain the transition, that declaration or commitment MUST have been an input to the decision or enforcement path at T. Merely associating it with the transition in a record created at or after T is insufficient.¶
The following facts, by themselves, are insufficient:¶
If more than one candidate condition set remains compatible with the evidence, the evaluator MUST NOT select one and report the governing conditions as determined.¶
Where the evaluator is in a different administrative domain from the party that applied the governing conditions, the applicable specification or profile MUST provide a way for that evaluator to determine which party issued or ratified the governing revision and under what authority. An evaluator that establishes the content of the governing revision but not its source, or its source but not which revision was in force at T, MUST NOT report the governing conditions as determined; it MAY report the subset it established, identified as such.¶
A proof generated after T MAY satisfy this requirement if it establishes a binding that was fixed no later than T and could not have been created or substituted after T without detection.¶
This requirement does not mandate synchronized clocks, an external timestamp, transparency service, trusted execution environment, or other specific mechanism.¶
At T+n, an independent evaluator MUST be able to establish the facts claimed under DET-1 and DET-2 without requiring cooperation from an original participant whose conduct or assertion is material to those facts.¶
The determination MUST NOT depend on the continued existence of the original session or agent instance. It MUST NOT require a credential or key used at T to remain currently valid merely because the transition is being verified later.¶
Where credential, key, revocation, compromise, or other status at T is material, the applicable specification or profile MUST provide a way to establish the relevant historical fact or return an explicit result that the fact cannot be established.¶
Information required for the determination MUST remain available for the period over which retrospective determinability is claimed. Integrity and availability are separate properties: a commitment does not satisfy this requirement if the material needed to verify it can be obtained only from a participant whose cooperation is excluded at T+n.¶
Where a specification claims determinability for a negative transition, such as deny, refuse, or challenge, the transition MUST be determinable without relying on a later successful action. Silence MUST NOT be treated as refusal unless the specification defines a verifiable rule giving silence that meaning.¶
Where a material action follows a transfer, delegation, resumption, or handoff, the evaluator MUST be able to determine which governing conditions carried forward, which were narrowed or terminated, and which were newly established, to the extent those facts are material to the claimed transition.¶
Transfer of work or session state MUST NOT, by itself, be treated as evidence that authority was transferred.¶
Presentation of individually valid evidence MUST NOT, by itself, be treated as proof that all material evidence has been presented. If completeness is required for a claimed determination, the specification MUST define how omission is detected or return an explicit result that completeness cannot be established.¶
These requirements distinguish claims. They do not make every claim true.¶
A valid signature can establish that an issuer made a statement. It does not by itself establish that the issuer possessed authority, that the statement was true, that stated conditions actually constrained internal processing, or that an external effect occurred.¶
Likewise, transparency can establish existence, inclusion, and ordering properties without establishing actual decision-time use. The SCITT architecture [RFC9943] distinguishes registration from truth and does not make registration order equivalent to issuance order unless the registration policy supplies that property.¶
Determinability of a negative transition is similarly narrow. A determinable refusal establishes that the fact of refusal was stated by a party rather than inferred from an absence. It does not establish that the refusal was correct, that any reasons given were honest, or that the refusing party was entitled to refuse.¶
A relying party therefore needs to know what fact an artifact establishes and under what assurance basis. Evidence of an earlier transition does not by itself establish a later one.¶
Several current drafts instantiate portions of these requirements. [I-D.lee-orprg-permit-receipts] defines a permit-before-commit mechanism for external effects. [I-D.abak-agent-control-delivery-evidence] separates control emission, required-target resolution, receiver-side observation, enforcement outcome, and observation of the resulting effect. [I-D.sokolov-rats-aep-composition] binds an application-layer action record to RATS platform Evidence in the sense of [RFC9334] while explicitly distinguishing that binding from independent observation of the reported action. [I-D.mih-sato-agent-accountability-composition] composes authorization, action, and runtime-enforcement evidence, and [I-D.bu-agentproto-security-principal-binding] separates security claims by verifier, binding, freshness, and failure semantics.¶
This document does not replace those mechanisms. It states mechanism-independent requirements that such mechanisms or profiles can satisfy when claiming participant-independent retrospective determinability.¶
Agent session requirements [I-D.feng-agentproto-session-requirements] address session establishment, authorization boundaries, and lifecycle.¶
A session relationship and an authorization relationship are different objects. Delegating work from B to C does not by itself make C a peer of an existing A-B session, and establishing a new A-C session does not by itself establish what authority C received from an earlier grant.¶
That document places outside the base session abstraction both the coordination of delegation or handoff of application tasks to entities that are not peers of the session, and the operational management, audit, and durable evidence mechanisms used to reconstruct or assess application-layer actions. It observes that another requirements document could define application-level delegation, task handoff, accountability, and audit properties without making them part of that abstraction, and contemplates that a separate specification or profile may require conforming implementations to produce, bind, retain, or expose evidence when a session decision is made so that the decision can be independently evaluated later.¶
This document states what such a specification or profile must satisfy for that later evaluation to be independent. A session specification can incorporate the subset it needs without defining a general evidence or audit system.¶
This document does not propose a change to the agentproto charter.¶
Failure to distinguish transitions can cause a relying party to infer a stronger fact from weaker evidence, as described in DET-1.¶
Later reconstruction creates a separate risk. A party can preserve or reconstruct several internally valid candidate condition sets and present the favorable one after learning the outcome. DET-2 requires the claimed governing conditions to have been bound no later than T.¶
Silent amendment is a specific case of that risk. If evidence names a mutable policy but not the revision that governed at T, later amendment can leave the evaluator with a valid reference to different content. DET-1 and DET-2 require the governing revision, and where material its source, to be bound to the claim.¶
Participant loss and credential lifetime create another failure mode. Evidence that is valid only while the original participant, session, credential, key, or agent instance remains live does not provide the retrospective property claimed by DET-3.¶
Retrospective determinability can require retention of identities, authority relationships, policy information, resource identifiers, or other sensitive material. Stable identifiers and commitments can also permit correlation, and durable representation of refusals can reveal traffic patterns.¶
Specifications applying these requirements SHOULD retain and disclose no more information than is needed for the claimed determination and SHOULD define appropriate retention and access-control rules.¶
This document has no IANA actions.¶
The requirements in this draft were sharpened through discussion on the agentproto mailing list.¶
Henri Sirkkavaara stated the first form of the participant-independence property and put it into normative wording. He also provided a content-addressed, recomputable example that showed record identity and later recomputation to be separable from actual decision-time use.¶
Sumit P. Ahuja strengthened that property beyond the transferring party to either party to the transfer and identified the distinction between integrity and availability and the problem of falsifying a later record when the decision-time fact was not independently constrained.¶
Bradley B contributed the closing clause in DET-3, that the determination must not depend on the continued validity of any credential, key, or agent instance involved, wrote the refusal property in DET-4, and identified the prior-commitment requirement reflected in DET-2.¶
Mikhail Sergeev identified the multiple-candidate or unique-selection failure underlying DET-2.¶
Chong Feng clarified the boundary between session peerhood and application-layer task coordination. Discussion with Mirja Kuehlewind and Suresh Krishnan also helped separate session concerns from properties that must survive the live interaction.¶
The author is responsible for the reduction expressed here and for the remaining errors.¶