Internet Engineering Task Force D. Watts Internet-Draft Independent Researcher Intended status: Experimental 12 September 2026 Expires: 16 March 2027 Evidence-Bounded Authorization for Agentic Systems: Evidence Qualification Receipts draft-watts-agent-evidence-boundary-00 Abstract Autonomous agents increasingly make or propose consequential actions using premises assembled from model outputs, memory, tools, telemetry, and external data. Existing authentication and authorization mechanisms can establish who is acting, under whose delegation, and which operation is permitted, but they do not by themselves establish whether the proposition that triggered the operation has adequate support. This document defines the Evidence Qualification Receipt (EQR), a transport-neutral JSON data model and fail-closed verification procedure for binding a proposition to a declared evidence profile, its supporting evidence digests, contradiction state, freshness, and evaluation result. An EQR can be PASS, FAIL, or INDETERMINATE. A PASS EQR is only an authorization input: it is never itself permission to execute. The design is append-only: changed evidence produces a successor receipt rather than rewriting prior epistemic state. The goal is to prevent evidence, provenance, or model confidence from silently acquiring authorization semantics. 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 16 March 2027. Watts Expires 16 March 2027 [Page 1] Internet-Draft Evidence-Bounded Agent Authorization September 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Problem Statement and Non-Collapse Requirements . . . . . . . 4 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Evidence Qualification Receipt Data Model . . . . . . . . . . 7 5.1. Evaluation Status . . . . . . . . . . . . . . . . . . . . 8 5.2. Example EQR Payload . . . . . . . . . . . . . . . . . . . 8 6. Integrity Protection and Issuer Authentication . . . . . . . 9 7. Receipt Production . . . . . . . . . . . . . . . . . . . . . 10 8. Receipt Verification and Use . . . . . . . . . . . . . . . . 10 8.1. Fail-Closed Qualification . . . . . . . . . . . . . . . . 11 9. Integration with Authorization Systems . . . . . . . . . . . 11 10. Append-Only Lifecycle and Supersession . . . . . . . . . . . 12 11. Failure and Error Semantics . . . . . . . . . . . . . . . . . 12 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Invoice Payment Agent . . . . . . . . . . . . . . . . . 13 12.2. Operations Agent . . . . . . . . . . . . . . . . . . . . 14 12.3. Research Promotion Agent . . . . . . . . . . . . . . . . 14 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 14. Relationship to Existing Work . . . . . . . . . . . . . . . . 15 15. Security Considerations . . . . . . . . . . . . . . . . . . . 15 16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 18. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 16 19. Normative References . . . . . . . . . . . . . . . . . . . . 16 20. Informative References . . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Watts Expires 16 March 2027 [Page 2] Internet-Draft Evidence-Bounded Agent Authorization September 2026 1. Introduction Autonomous agents increasingly act on premises derived from model inference, retrieved memory, external tools, telemetry, documents, and other agents. Authentication can establish an actor's identity. Delegation can establish on whose behalf that actor operates. Authorization can establish whether a requested operation is permitted. None of those steps, by themselves, establish whether the proposition used to justify the action is adequately supported. This creates a failure mode that is easy to miss in otherwise well- designed authorization systems: a correctly authenticated and correctly authorized agent can still execute an action because an unsupported, stale, contradictory, or merely speculative premise was treated as though it were established evidence. This document defines an Evidence Qualification Receipt (EQR). An EQR binds an exact proposition digest to a versioned evidence- requirements profile, evidence digests, contradiction state, temporal context, and one of three evaluation results: PASS, FAIL, or INDETERMINATE. It is intended to be consumed by an authorization system as one input among identity, delegation, policy, action, and resource context. The design follows four non-collapse rules: * Integrity is not admissibility. * Evidence is not authority. * Qualification is not authorization. * Authorization is not execution. In particular, a cryptographically valid EQR with evaluation status PASS does not grant a capability, mint an access token, or require a resource server to execute an operation. This document is deliberately transport-neutral. It does not define a replacement for OAuth, workload identity, RATS, SCITT, or agent communication protocols. Profiles can bind an EQR or an EQR digest to those systems. Watts Expires 16 March 2027 [Page 3] Internet-Draft Evidence-Bounded Agent Authorization September 2026 2. Conventions and Terminology The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY 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. Proposition An exact declarative claim whose support state is being evaluated. Evidence Profile A versioned set of requirements defining what evidence, freshness, contradiction handling, comparison rules, and other checks are required for a proposition class. Evidence Qualification Receipt (EQR) An immutable result object binding a proposition, profile, evidence references, and evaluation outcome. Issuer The system that evaluates the declared profile and produces the EQR. Issuer identity is not proof that the evaluation is substantively correct. Verifier A component that validates an EQR's syntax, integrity, bindings, freshness, and local acceptability before making it available to authorization policy. Authorization System The component that decides whether an actor may perform an action on a resource. It can consume an EQR but remains authoritative for the permission decision. PASS All required profile checks are satisfied within the declared scope and tolerances. FAIL At least one required profile check is contradicted or violated. INDETERMINATE No required check has established FAIL, but one or more required inputs, bridges, freshness conditions, or contradiction resolutions are missing or unresolved. 3. Problem Statement and Non-Collapse Requirements Current agent authorization work correctly focuses on identity, delegation, user consent, policy, transaction binding, and provenance. A separate question arises before a high-consequence action: what evidence supports the proposition that made the action appear necessary or appropriate? Watts Expires 16 March 2027 [Page 4] Internet-Draft Evidence-Bounded Agent Authorization September 2026 Examples include a payment agent acting because it believes an invoice is overdue, an operations agent restarting a service because it believes a health check failed, or a research agent promoting a result because it believes an experiment met a preregistered criterion. The permission to perform an operation and the evidence supporting the premise for that operation are different objects. An implementation conforming to this document MUST NOT interpret PASS as an authorization decision. It MUST NOT interpret receipt integrity as evidence sufficiency. It MUST NOT convert INDETERMINATE into PASS because an action is time-sensitive or because other authorization inputs are valid. The following implication is therefore invalid: authenticated actor + valid delegation + permitted operation + signed evidence object | X does not imply v "the triggering proposition is adequately supported" Figure 1 EQR adds an explicit qualification step without changing which authorization system ultimately controls execution. 4. Architecture Watts Expires 16 March 2027 [Page 5] Internet-Draft Evidence-Bounded Agent Authorization September 2026 proposition + evidence + profile | v +------------------+ | EQR Evaluator | +------------------+ | PASS / FAIL / INDETERMINATE | v +------------------+ | EQR Verifier | +------------------+ | qualified input only | +---------------+----------------+ | identity | delegation | policy | | action | resource | EQR | +---------------+----------------+ | v +------------------+ | Authorization | | System | +------------------+ ALLOW / DENY | v execution Figure 2: EQR in an agent authorization path The evaluator and verifier can be the same deployment component, but their logical responsibilities are distinct. The evaluator determines the profile outcome. The verifier determines whether the receipt can be trusted and used in the current context. An authorization system MAY require no EQR for low-consequence operations and a particular EQR profile for higher-consequence operations. This document does not define those local risk classes. Watts Expires 16 March 2027 [Page 6] Internet-Draft Evidence-Bounded Agent Authorization September 2026 5. Evidence Qualification Receipt Data Model An EQR payload is a JSON object as defined by [RFC8259]. Implementations that compute a digest over a JSON payload SHOULD use the JSON Canonicalization Scheme [RFC8785] before hashing. When an EQR binds a non-JSON proposition, evidence object, profile, context, or action, the applicable profile MUST define the canonical byte representation that is hashed. The following members are defined: version String. This document defines version 1. receipt_id A URI identifying this immutable receipt, using URI syntax from [RFC3986]. issuer A URI identifying the EQR issuer. issued_at and expires_at Timestamps bounding receipt freshness. They MUST use the Internet date/time format defined by [RFC3339]. profile Object containing a stable profile identifier and digest of the exact profile bytes used. claim Object containing a stable claim identifier and digest of the exact proposition evaluated. context_digest Optional digest binding the evaluation to a declared snapshot, transaction, or other context. action_digest Optional digest binding the receipt to a proposed action. High-consequence profiles SHOULD require this member when the proposition is evaluated specifically to justify an action. evaluation Object containing status, requirements_satisfied, and the number or digests of unresolved blocking contradictions. evidence Array of evidence descriptors. Each descriptor binds at least a digest and evidence class; deployments can add local metadata such as freshness or an access-controlled retrieval reference. This document defines sha-256 as the mandatory-to- implement digest algorithm [RFC6234]. Digest values MUST use base64url encoding without padding as specified in [RFC4648]. supersedes Optional receipt identifier of a predecessor EQR superseded by new evidence. The predecessor is not modified. nonce Optional verifier- or transaction-supplied value for replay Watts Expires 16 March 2027 [Page 7] Internet-Draft Evidence-Bounded Agent Authorization September 2026 resistance. 5.1. Evaluation Status The evaluation.status member MUST be exactly one of: pass, fail, or indeterminate. An issuer MUST produce fail when any required profile condition is known to be violated. Otherwise, if any required condition is missing, unresolved, stale, or outside declared tolerance, the issuer MUST produce indeterminate. The issuer MUST produce pass only when all required conditions are satisfied. An empty required-condition set MUST NOT yield PASS. A profile that intentionally requires no evidence does not need an EQR. 5.2. Example EQR Payload Watts Expires 16 March 2027 [Page 8] Internet-Draft Evidence-Bounded Agent Authorization September 2026 { "version": "1", "receipt_id": "urn:uuid:6ac9f8f0-30e1-4b4c-a142-9f5cb5ad58f1", "issuer": "https://qualifier.example", "issued_at": "2026-09-12T23:50:00Z", "expires_at": "2026-09-13T00:05:00Z", "profile": { "id": "https://example.org/profiles/invoice-overdue/v1", "hash_alg": "sha-256", "digest": "BASE64URL(PROFILE_DIGEST)" }, "claim": { "id": "urn:example:claim:invoice-8472-overdue", "hash_alg": "sha-256", "digest": "BASE64URL(PROPOSITION_DIGEST)" }, "context_digest": "BASE64URL(CONTEXT_DIGEST)", "action_digest": "BASE64URL(PROPOSED_ACTION_DIGEST)", "evaluation": { "status": "pass", "requirements_satisfied": true, "blocking_contradictions": [] }, "evidence": [ { "class": "signed_invoice_record", "hash_alg": "sha-256", "digest": "BASE64URL(EVIDENCE_DIGEST)", "fresh_until": "2026-09-13T00:05:00Z" } ], "nonce": "t9mS6wqz2Dbf", "supersedes": null } Placeholder digest text in this example is non-normative. 6. Integrity Protection and Issuer Authentication This document does not define a new signature format. An inter- domain EQR MUST be integrity protected and bound to an authenticated issuer using a mechanism acceptable to the verifier. JWS [RFC7515] and COSE Sign1 [RFC9052] are examples of existing mechanisms that can be profiled for this purpose. Watts Expires 16 March 2027 [Page 9] Internet-Draft Evidence-Bounded Agent Authorization September 2026 A verifier MUST NOT infer substantive evidence quality from successful signature verification. Signature validation establishes integrity and issuer binding; it does not establish that the issuer used an adequate evidence profile or evaluated it correctly. 7. Receipt Production Before producing an EQR, an issuer MUST bind the exact proposition and exact evidence profile. The profile MUST identify each required condition and the rule for handling missing values, stale values, contradictory evidence, and comparison tolerances. Where a profile compares multiple representations of the same property, the profile MUST define the comparison space, units, transformation or bridge, snapshot alignment, and tolerance. A unit mismatch or incompatible comparison type is a profile failure. Missing or unresolved calibration is INDETERMINATE. The issuer MUST NOT silently substitute a different proposition, evidence profile, evidence source, or action after evaluation. Such a change requires a new receipt. 8. Receipt Verification and Use A verifier consuming an EQR MUST perform the following checks before exposing the receipt to authorization policy: 1. Validate syntax and the supported EQR version. 2. Validate required integrity protection and issuer authentication. 3. Validate receipt freshness and, when present, nonce or transaction binding. 4. Validate the proposition digest against the proposition used by the proposed action. 5. Validate the profile identifier and profile digest against an acceptable local profile. 6. Validate context and action digests when required by local policy. 7. Apply local trust policy to the issuer and evidence classes. 8. Expose the EQR evaluation status to the authorization system without rewriting it. Watts Expires 16 March 2027 [Page 10] Internet-Draft Evidence-Bounded Agent Authorization September 2026 A verifier can classify a receipt as syntactically/integrity VALID while its embedded evaluation remains FAIL or INDETERMINATE. Receipt validity and proposition qualification are separate dimensions. 8.1. Fail-Closed Qualification When an authorization policy requires a PASS EQR, FAIL and INDETERMINATE MUST NOT satisfy that requirement. def qualifies_for_policy(eqr, local_policy, action): if not syntax_and_integrity_valid(eqr): return False if not fresh_and_bound(eqr, action): return False if eqr["evaluation"]["status"] != "pass": return False if eqr["evaluation"]["requirements_satisfied"] is not True: return False if eqr["evaluation"]["blocking_contradictions"]: return False return local_policy.accepts_evidence_qualification(eqr, action) Returning true from this procedure means only that one authorization precondition is satisfied. It does not mean the action is authorized. 9. Integration with Authorization Systems Authorization remains a separate function: authorization_decision = local_policy( principal, delegation, proposed_action, protected_resource, current_context, verified_evidence_qualification ) execute only if authorization_decision == ALLOW Figure 3 Watts Expires 16 March 2027 [Page 11] Internet-Draft Evidence-Bounded Agent Authorization September 2026 Existing agent authorization mechanisms can carry an EQR by value, by digest, or by a reference whose dereferencing and trust semantics are defined by a profile. For example, an OAuth deployment could bind an EQR reference to transaction-specific authorization state or to Rich Authorization Requests [RFC9396]. This document does not register an OAuth authorization-details type or token claim. When an evidence challenge mechanism is used to request missing evidence, satisfying the challenge can result in a newly evaluated EQR. The new EQR is still not authorization and does not guarantee execution. 10. Append-Only Lifecycle and Supersession EQR state is append-only. An implementation MUST NOT mutate an existing receipt from INDETERMINATE to PASS, from FAIL to PASS, or from PASS to another state after issuance. New evidence, a corrected profile, a changed action, or a changed evaluation result requires a new EQR with a new receipt_id. The successor MAY identify its predecessor in supersedes. A verifier MUST NOT treat supersession as deletion of the predecessor. EQR:v1 status = indeterminate | | new evidence v EQR:v2 supersedes = EQR:v1 status = pass EQR:v1 remains immutable historical evidence. Figure 4 This lifecycle allows an audit system to reconstruct what was known, missing, or contradicted at the time of each authorization decision. 11. Failure and Error Semantics Profiles and transports can define their own error codes, but implementations should preserve the following distinctions: Watts Expires 16 March 2027 [Page 12] Internet-Draft Evidence-Bounded Agent Authorization September 2026 +===============================================+===============+ | Condition | Result | +===============================================+===============+ | Receipt malformed, signature invalid, or | INVALID | | binding mismatch | receipt | +-----------------------------------------------+---------------+ | Required evidence contradicts profile | VALID receipt | | | with FAIL | +-----------------------------------------------+---------------+ | Required evidence missing, stale, unresolved, | VALID receipt | | or uncertainty crosses a threshold | with | | | INDETERMINATE | +-----------------------------------------------+---------------+ | All required conditions satisfied | VALID receipt | | | with PASS | +-----------------------------------------------+---------------+ | PASS EQR but authorization policy denies | DENY action | +-----------------------------------------------+---------------+ Table 1: Required distinctions Collapsing INVALID, FAIL, INDETERMINATE, and authorization DENY into one generic "false" loses information useful for remediation and auditing. 12. Examples 12.1. Invoice Payment Agent An agent proposes a payment because it claims invoice 8472 is overdue. The authorization system already knows the user delegated payment authority up to a configured amount. Local policy also requires a PASS EQR for the proposition "invoice 8472 is overdue" under a profile requiring a signed invoice record, due-date comparison, duplicate-payment check, and freshness under five minutes. If the invoice record is present but the duplicate-payment service is unavailable, the EQR is INDETERMINATE. The valid delegation does not upgrade that state. The authorization system denies or defers according to local policy. Watts Expires 16 March 2027 [Page 13] Internet-Draft Evidence-Bounded Agent Authorization September 2026 12.2. Operations Agent An operations agent proposes a restart because a health signal exceeded a threshold. A profile requires agreement between two telemetry representations after unit normalization and time-window alignment. A reading of 250 milliseconds and 0.25 seconds can agree after a declared bridge, but this correspondence does not prove that both instruments observed the intended event. If timestamps cannot be aligned, the EQR is INDETERMINATE. If units are declared incompatible, the profile fails. If all required comparisons and freshness checks pass, the EQR can become an input to a separate restart authorization policy. 12.3. Research Promotion Agent A research workflow proposes to promote a result from "candidate" to "supported". The evidence profile requires locked source digests, numeric trace bindings, registered risk criteria, and a reproduction receipt. If independent reproduction is required but absent, the result is INDETERMINATE even when all local checks pass. A local success receipt cannot silently satisfy an independent-reproduction requirement. 13. Implementation Status This section is non-normative and is included to provide transparency about the maturity of the design. The author maintains a local Python reference package for a broader fail-closed theoretical profile. The currently frozen package executes finite boundary checks for three-valued prerequisite conjunction, missing and mistyped comparisons, uncertainty crossing tolerance, empty and tied selections, blocked fiction-to-empirical promotion, and unresolved-evidence promotion. The local verification report records 40 named checks passing. It also records that the package is a frozen theoretical candidate, not an empirical validation or deployment authorization. The referenced local package digest is: e53b16656c9a98a4851bfc0b627bd7df189b83c4df77f753361b58b9b8cd7f33. No interoperable network implementation or independent reproduction is claimed by this -00 draft. Watts Expires 16 March 2027 [Page 14] Internet-Draft Evidence-Bounded Agent Authorization September 2026 14. Relationship to Existing Work AI-agent authentication and authorization work describes how existing identity and authorization standards can be applied to agents [I-D.aiagent-auth]. Agent Operation Authorization defines action- specific authorization proposals and tokens [I-D.agent-operation]. OAuth Authorization Evidence records user confirmation and audit evidence associated with access tokens [I-D.oauth-authz-evidence]. Authorization Evidence Challenge describes how a relying party can request missing authorization evidence [I-D.ae-challenge]. Agent Action Capsule provenance binding relates authorization, memory provenance, and recorded action outcomes [I-D.aac-provenance]. EQR is intended to be complementary. Its narrow question is: under a declared evidence profile, what is the current qualification state of the exact proposition being offered as a premise for an action? It neither replaces user consent evidence nor defines the authorization decision itself. 15. Security Considerations EQR introduces an additional input to authorization systems and therefore creates new downgrade, replay, misbinding, and trust- confusion risks. *Authority laundering:* A verifier MUST NOT treat a valid signature, reputable issuer, neighboring true statement, or PASS result under one profile as authority for a different proposition, profile, context, or action. *Replay:* High-consequence deployments SHOULD bind receipts to a short validity interval and, where appropriate, a nonce, transaction, or action digest. Replaying an old PASS receipt after the relevant evidence became stale can cause unsafe authorization. *Profile substitution:* Both a stable profile identifier and digest are included because a mutable profile URI alone permits semantic substitution. A verifier MUST reject a profile digest that does not match its accepted profile bytes. *Evidence reference attacks:* Optional evidence retrieval references can create SSRF, access-control, and exfiltration risks. A verifier MUST NOT dereference arbitrary locations solely because they appear in a receipt. Retrieval policy is local. *Compromised issuer:* Cryptographic integrity cannot make a dishonest or compromised issuer correct. Authorization systems need explicit issuer trust, profile acceptance, and evidence class policy. Watts Expires 16 March 2027 [Page 15] Internet-Draft Evidence-Bounded Agent Authorization September 2026 *Denial of service:* Evidence graphs and contradiction sets can be large. Profiles should bound input sizes, recursion, remote lookups, and verification cost before evaluation begins. *Confused-deputy execution:* A PASS EQR that is not bound to the intended proposition or action can be reused to justify a different action. Exact proposition and action bindings are recommended whenever an EQR participates in a high-consequence decision. 16. Privacy Considerations Evidence supporting an agent decision can contain personal, confidential, financial, medical, location, behavioral, or proprietary information. EQR is designed to permit digest-only evidence descriptors so that an authorization path need not copy source data into every token or receipt. Implementations SHOULD minimize the proposition text, evidence metadata, retrieval locations, and correlation identifiers exposed across trust boundaries. Where a proposition itself is sensitive, deployments should exchange a digest or privacy-preserving reference and reveal the plaintext only to components that require it. Long-lived globally unique identifiers can create correlation risk. Deployments should scope receipt and claim identifiers to the smallest useful administrative domain unless cross-domain auditability is a requirement. 17. IANA Considerations This document has no IANA actions. A future revision or companion profile that defines a registered media type, OAuth authorization- details type, token claim, or CBOR label will need corresponding IANA considerations. 18. Conclusion Agent authorization systems need to distinguish the permission to act from the support for the proposition that motivated the action. EQR provides a small transport-neutral object for preserving that distinction. The governing rule is simple: evidence can qualify an authorization premise, but it cannot silently become authorization. 19. Normative References Watts Expires 16 March 2027 [Page 16] Internet-Draft Evidence-Bounded Agent Authorization September 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . 20. Informative References [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . Watts Expires 16 March 2027 [Page 17] Internet-Draft Evidence-Bounded Agent Authorization September 2026 [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [I-D.aiagent-auth] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft- klrc-aiagent-auth-03, July 2026, . [I-D.agent-operation] Liu, D., Zhu, H., and S. Krishnan, "Agent Operation Authorization", Work in Progress, Internet-Draft, draft- liu-agent-operation-authorization-02, March 2026, . [I-D.oauth-authz-evidence] Liu, D., "Authorization Evidence and Audit Trail for OAuth 2.0 Access Tokens", Work in Progress, Internet-Draft, draft-liu-oauth-authorization-evidence-01, June 2026, . [I-D.ae-challenge] Schrock, I., "An Authorization Evidence Challenge for High-Risk Agent Actions", Work in Progress, Internet- Draft, draft-schrock-ae-challenge-05, August 2026, . [I-D.aac-provenance] Rampalli, K., "Binding Per-Action Authorization and Memory Provenance into Agent Action Capsules", Work in Progress, Internet-Draft, draft-rampalli-scitt-capsule-provenance- binding-00, July 2026, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . Watts Expires 16 March 2027 [Page 18] Internet-Draft Evidence-Bounded Agent Authorization September 2026 Appendix A. Acknowledgements The author thanks the IETF community authors whose 2026 work on agent authentication, transaction authorization, authorization evidence, evidence challenge semantics, and action provenance helped clarify the specific non-collapse boundary addressed by this draft. Author's Address Deonte Watts Independent Researcher San Francisco, CA United States Email: deonte@goodshyt.fun URI: https://orcid.org/0009-0005-8586-3650 Watts Expires 16 March 2027 [Page 19]