Independent Researcher

San Francisco CA United States deonte@goodshyt.fun https://orcid.org/0009-0005-8586-3650

Security Internet Engineering Task Force AI agent authorization evidence provenance agentic systems 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.

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.

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

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? 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:

EQR adds an explicit qualification step without changing which authorization system ultimately controls execution.

Architecture

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.

Evidence Qualification Receipt Data Model An EQR payload is a JSON object as defined by . Implementations that compute a digest over a JSON payload SHOULD use the JSON Canonicalization Scheme 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 .

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 .

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 . Digest values MUST use base64url encoding without padding as specified in .

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

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.

Example EQR Payload Placeholder digest text in this example is non-normative.

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 and COSE Sign1 are examples of existing mechanisms that can be profiled for this purpose. 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.

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.

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.

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.

Fail-Closed Qualification When an authorization policy requires a PASS EQR, FAIL and INDETERMINATE MUST NOT satisfy that requirement. Returning true from this procedure means only that one authorization precondition is satisfied. It does not mean the action is authorized.

Integration with Authorization Systems Authorization remains a separate function:

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

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.

This lifecycle allows an audit system to reconstruct what was known, missing, or contradicted at the time of each authorization decision.

Failure and Error Semantics Profiles and transports can define their own error codes, but implementations should preserve the following distinctions: Required distinctions

Condition	Result
Receipt malformed, signature invalid, or binding mismatch	INVALID receipt
Required evidence contradicts profile	VALID receipt with FAIL
Required evidence missing, stale, unresolved, or uncertainty crosses a threshold	VALID receipt with INDETERMINATE
All required conditions satisfied	VALID receipt with PASS
PASS EQR but authorization policy denies	DENY action

Collapsing INVALID, FAIL, INDETERMINATE, and authorization DENY into one generic "false" loses information useful for remediation and auditing.

Examples

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.

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.

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.

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.

Relationship to Existing Work AI-agent authentication and authorization work describes how existing identity and authorization standards can be applied to agents . Agent Operation Authorization defines action-specific authorization proposals and tokens . OAuth Authorization Evidence records user confirmation and audit evidence associated with access tokens . Authorization Evidence Challenge describes how a relying party can request missing authorization evidence . Agent Action Capsule provenance binding relates authorization, memory provenance, and recorded action outcomes . 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.

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

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.

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.

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.

Normative References Informative References Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress

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.