The Action Evidence Boundary for Consequential Agent Effects

Status of This Memo

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 22 January 2027.¶

Copyright Notice

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.¶

Table of Contents

1. Introduction

A remote executor can receive several independently useful inputs: a workload credential and protected request, a delegation or capability, a pre-execution permit, a human-authorization artifact, and a policy decision. None of those inputs alone answers every question the consequence-owning system has to answer before changing its system of record.¶

The missing contract is at the effect boundary. The executor must determine what exact material action it is about to perform; verify each artifact under its native rules; correlate independently verified representations without guessing; evaluate whether the evidence bundle fills its requirement; make its own authorization decision; consume or reserve any one-time or bounded authority; invoke the effect once; and preserve uncertainty when the effect cannot be observed conclusively.¶

This document defines that contract. Its required order is:¶

 native verification
        |
        v
 CAID material-action MATCH
        |
        v
 AEC evidence SATISFIED
        |
        v
 local policy AUTHORIZED
        |
        v
 atomic CONSUMED / RESERVED
        |
        v
 durable DISPATCH_PENDING
        |
        v
 INVOKED
        |
        +--> EXECUTED
        +--> FAILED
        +--> INDETERMINATE --> authenticated reconciliation

Every arrow is conditional. A signature is not authority. Native verification is not action correlation. Action correlation is not evidence satisfaction. Evidence satisfaction is not local authorization. Authorization is not execution. An invocation error is not proof that no effect occurred.¶

2. Conventions and Terminology

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.¶

Effect boundary:

The last control point that can withhold the protected mutation before it is submitted to the effecting system.¶

Relying party:

The party that selects trust inputs, action definitions, mapping profiles, evidence requirements, freshness rules, and local authorization policy, and that relies on the resulting decision.¶

Native artifact:

An evidence, credential, permit, token, receipt, status, or message-protection object defined outside AEB and verified under its own specification.¶

Observed action:

The immutable material action constructed by the effect boundary from executor-controlled parsing and system-of-record facts.¶

Material field:

A field whose change can alter the protected consequence, as declared by the selected CAID action-type definition.¶

Invocation:

The first dispatch of the frozen authorized action to a component that can cause the protected effect.¶

Authoritative reconciliation:

An authenticated, audience-bound observation from the effecting provider or system of record that is matched to the original action and operation identifier.¶

3. Non-Collapsing Decision and Lifecycle Vocabulary

AEB uses the following decisions with the meanings established by the EMILIA architecture and its component drafts:¶

VERIFIED:

One native artifact passed its native verifier under relying-party-selected trust inputs.¶

MATCH:

Independently verified artifacts denote the same material action directly or under exact relying-party-pinned CAID mapping profiles.¶

SATISFIED:

Verified and matched evidence fills every slot in the relying party's AEC requirement.¶

AUTHORIZED:

The consequence-owning relying party's local policy permits this exact action at this time.¶

EXECUTED:

The executor records, or an accepted native artifact attests, that the exact effect occurred. This meaning remains bounded by the native source and its trust assumptions.¶

AEB also names operational lifecycle states:¶

CONSUMED:

A one-time authorization, challenge, operation key, or equivalent native replay unit has been durably made unavailable for another invocation.¶

RESERVED:

Bounded state, such as a capability budget, has been durably fenced for the exact operation before invocation.¶

DISPATCH_PENDING:

A durable intent record binds the frozen action, operation identifier, provider environment, and reservation before any effecting dispatch can occur. Recovery treats a stranded intent as uncertain, not as unused authority.¶

INVOKED:

The protected effect was dispatched using the frozen authorized action and operation identifier.¶

FAILED:

Authoritative executor or reconciliation evidence establishes that the invoked operation did not cause the protected effect. A local exception or timeout alone is not sufficient.¶

INDETERMINATE:

Invocation began, but available authoritative evidence does not establish whether the protected effect occurred.¶

CONSUMED, RESERVED, DISPATCH_PENDING, INVOKED, FAILED, and INDETERMINATE are lifecycle terms, not new evidence types or IANA registry values. A deployment MAY use different local labels if their semantics are at least as strict.¶

4. Relying-Party Inputs and Pins

The requester, presenter, agent, and mutable intermediary context are untrusted inputs. They MAY propose an action and present native artifacts. They MUST NOT select or weaken the controls used to accept that request.¶

Before evaluating an action, the relying party MUST configure or pin, as applicable:¶

• the supported native artifact revisions, verifier adapters, algorithms, trust anchors, issuers, audiences, and status sources;¶
• the CAID suite, action-type definition source, exact source descriptors, and mapping-profile digests;¶
• the AEC requirement and the admissible native evidence roles for each slot;¶
• local policy identifiers, policy epochs, tenant and organization boundaries, and any separation-of-duty rule;¶
• the trusted clock, maximum ages, validity windows, allowed skew, and revocation or status freshness requirements;¶
• the durable replay, consumption, reservation, and operation-key namespaces; and¶
• the protected executor, provider environment, reconciliation endpoint, and authenticated provider or system-of-record identities.¶

A label, key, profile identifier, requirement, status assertion, or policy identifier carried only in presenter-controlled data MUST NOT become its own trust anchor. Missing, conflicting, unsupported, or ambiguous required configuration MUST fail closed.¶

5. Required Processing Model

6. Declaration and Challenge Semantics

A deployment MAY publish a static declaration describing protected actions, material fields, evidence requirements, challenge methods, and effect-boundary placement. Such a declaration is discovery metadata. It MUST NOT override the relying party's live, local enforcement configuration. An unsupported declaration version MUST be ignored as discovery input; it cannot weaken or replace live enforcement. An action that the live boundary configuration cannot classify or process under a supported version MUST fail closed.¶

When required evidence is absent or unacceptable, a boundary MAY use its application protocol to return a dynamic challenge. A challenge MUST identify the boundary-computed action, the missing evidence roles, the policy context, an intended audience, a short expiry, and a single-use unpredictable nonce or equivalent replay unit. The nonce MUST NOT be consumed merely because untrusted bytes parse. It MUST be consumed atomically only after the selected native verifier establishes the integrity and challenge binding of an in-window presentation, and before that presentation can reach SATISFIED or authorize an effect. A presentation that is malformed, unauthenticated, expired, or not bound to the challenge MUST be refused without burning the nonce. A natively verified, challenge-bound presentation consumes the nonce whether or not the remaining evidence satisfies the requirement. Follow-up challenges MUST remain bound to the original boundary-computed action and MUST NOT derive that action from presenter input.¶

A declaration or challenge authorizes nothing, reserves nothing, and promises no execution. A satisfied challenge still proceeds through native verification, MATCH, SATISFIED, local AUTHORIZED, and atomic consumption or reservation. This document intentionally defines no new manifest object, challenge object, well-known URI, HTTP status code, or media type.¶

7. Native Evidence and Transport Boundaries

8. Conformance and Deployment Claims

An implementation conforms to AEB only if every protected invocation follows the ordered processing model in Section 5 and fails closed on every missing or ambiguous required transition. A deployment MUST document:¶

• the protected action types and the effect paths actually mediated;¶
• the trusted configuration and durable-state boundaries;¶
• the native verifier revisions and relying-party pins;¶
• the method used to derive material action fields at the boundary;¶
• the consumption, reservation, and cross-replica fencing mechanism;¶
• the authoritative sources and matching rules used for reconciliation; and¶
• all direct, break-glass, administrator, alternate-protocol, and system-of-record paths that bypass the AEB implementation.¶

An implementation placed beside a write path is not complete mediation. A deployment MUST NOT claim complete mediation unless the protected system rejects all material alternate paths or subjects them to an equivalent boundary. Observe-only operation MAY be useful during deployment, but it MUST NOT be described as enforcement.¶

9. Security Considerations

Cross-binding. An attacker can splice a valid permit, approval, credential, or receipt for action A into a request for action B. Native verification before mapping, executor-owned action construction, exact CAID matching, and a relying-party-pinned AEC requirement are all required defenses. Omitting any one of them reopens the attack.¶

Mutable context. Intermediary-added headers and agent annotations are convenient but are not trustworthy merely because they arrived on an authenticated hop. Every load-bearing field needs accepted end-to-end integrity coverage or independent derivation at the effect boundary.¶

Time of check and time of use. The action passed to the executor must be the frozen action that was verified, matched, satisfied, authorized, and consumed or reserved. Mutable aliases, provider defaults, exchange rates, destinations, branch heads, and policy epochs can change a consequence after approval; profiles must bind or revalidate them as material fields.¶

Replay and distributed state. Process-local caches are insufficient where replicas can invoke the same effect. Replay, consumption, reservation, and operation ownership state must be durable, atomic, and shared across every boundary instance that can reach the protected executor.¶

Freshness and revocation. Expiration, nonce checks, credential status, authority status, and policy epoch are separate checks. A fresh message does not make a revoked credential valid, and a current credential does not make old per-action evidence fresh.¶

Indeterminate effects. Retrying after a timeout can duplicate a payment, mutation, disclosure, or physical action. An invocation that might have reached the provider consumes the operation's retry right until authenticated reconciliation resolves the exact outcome. Caller assurances and unauthenticated webhooks do not resolve it.¶

Signature overclaiming. A cryptographic signature can establish control of a key and integrity of covered content under a selected verification profile. It does not inherently identify a human, prove human operation, prove comprehension, establish legal authority, or prove execution.¶

Boundary bypass. A correct AEB implementation does not protect direct database credentials, alternate APIs, shell access, administrator consoles, side channels, or actuator paths that bypass it. Deployment topology and credential placement are security properties, not implementation details.¶

10. Privacy Considerations

Action objects and evidence can expose identities, destinations, resources, policy choices, commercial relationships, and sensitive operational timing. Deployments SHOULD minimize the evidence passed to the executor and retained in portable records, use opaque high-entropy references where appropriate, and avoid treating a plain digest of low-entropy personal data as anonymization.¶

Reconciliation queries can disclose that an operation is disputed or uncertain. They SHOULD be authenticated, authorized, rate-limited, and limited to the exact operation. AEB does not require public disclosure of native evidence or local policy.¶

11. Relationship to EMILIA and Adjacent Work

CAID [CAID] owns typed material-action identity and exact, relying-party-pinned cross-format mapping. AEB invokes CAID after native verification and does not extend CAID with trust semantics.¶

AEC [AEC] owns heterogeneous evidence composition and the SATISFIED or UNSATISFIED result under a relying-party requirement. AEB invokes AEC and then makes the separate local authorization and effect-lifecycle decisions.¶

Authorization Receipts [RECEIPTS] define one native action-bound organizational approval artifact and its receipt-specific consumption semantics. AEB does not make that format mandatory and does not generalize every native artifact into an EMILIA receipt.¶

This document is intended to absorb the lifecycle responsibilities of draft-schrock-agent-action-manifest-00, draft-schrock-authorization-evidence-challenge-00, and draft-schrock-ep-enforcement-point-00. Static declaration, dynamic challenge, fail-closed enforcement, one-time consumption, invocation, and outcome handling are specified here as one boundary lifecycle. Their earlier wire shapes remain historical inputs; AEB conformance does not require a new common envelope for them.¶

12. IANA Considerations

This document has no IANA actions. In particular, it creates no registry for native evidence types, lifecycle labels, verifier adapters, action mappings, or policy identifiers.¶

Appendix A. Acknowledgments

External review sharpened the boundaries between workload and message integrity, per-action authorization evidence, credential status, human operation, and executor-owned effect control. Those distinctions are load-bearing in this document. Acknowledgment does not imply endorsement.¶

Author's Address