Independent

wdhawkins46@gmail.com

Security attestation agent payment SCITT RATS Autonomous software agents increasingly initiate payments on behalf of principals. Existing agent-payment mechanisms authenticate the human principal, the operator, or possession of a key; none of them establishes that the software authorized to spend is the software that was reviewed. A key held by a compromised or silently modified agent authenticates exactly as well as one held by an honest agent. This document defines a payment authorization scope bound to a key whose protection properties are attested by hardware, and registers the resulting authorization as a Signed Statement on an SCITT Transparency Service. The binding reuses the EAT confirmation and key-attributes claims without modification; the contribution is the authorization scope, the verification procedure a payment executor performs before settlement, and the transparency record that makes the authorization auditable independently of the agent and of the executor.

Introduction Protocols for agent-initiated payment have converged quickly. They differ in mechanism but agree on what they bind: the consent of a human principal, the identity of an operator, or possession of a private key. What none of them binds is the identity of the running program. This distinction is not academic. Measurements of deployed agent-payment traffic report that a large fraction of settlement volume is either fictitious or internal to linked clusters , and that a majority of entries in at least one agent identity registry could not be reached at all. Possession of a key is compatible with all of these outcomes: it demonstrates that some party controls a secret, not that a particular program is running, nor that its behavior is the behavior that was authorized. Meanwhile the primitives needed to close the gap exist and are specified. binds a subject key to an attested execution environment using the EAT "cnf" claim and a "key-attributes" claim describing key protection properties. defines a Transparency Service on which signed statements about an artifact can be registered and later audited. Nothing joins them: no specification makes hardware attestation normative for a payment authorization decision, and no deployed system consults an attestation before releasing funds. This document defines that join. It is deliberately small: it adds no new attestation format, no new key binding, and no new transparency mechanism. It specifies (1) what an authorization scope contains, (2) the verification a payment executor MUST perform, and (3) what is registered so that a third party can later audit an authorization without trusting either the agent or the party that executed the payment.

Non-Goals This specification does not:

• define agent identity, naming, or discovery;
• define or require any particular payment protocol, settlement rail, or currency;
• establish the correctness of the attested software. An attestation proves that the running code is the endorsed code; it says nothing about whether that code is correct. Presenting the former as the latter is the central misuse this document warns against ();
• replace principal consent mechanisms. Attested authorization composes with them and is not a substitute: consent establishes that spending was wanted, attestation establishes which program may do the spending.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Agent:

An autonomous software instance that initiates payments.

Payment Executor:

The party that performs or submits settlement on an agent's instruction. In deployed systems this is typically a facilitator, gateway, or custodial service.

Authorization Scope:

The bounded permission to spend, defined in .

Attested Payment Key (APK):

The Subject Key of when used to authorize payments under this specification.

Overview An agent operating in an attested environment generates a key pair inside that environment and obtains an Entity Attestation Token (EAT) carrying the "cnf" claim for the public key and the "key-attributes" claim describing its protection properties, per . The agent's principal (or an operator acting for it) issues an Authorization Scope naming that key and the bounds within which it may spend. The scope, the attestation evidence, and the endorsed software identity are registered together as a Signed Statement on a Transparency Service , yielding a Receipt. When the agent later instructs a payment, the Payment Executor verifies the attestation, verifies that the instruction is signed by the APK, verifies that the payment falls within the scope, and verifies the Receipt before settling. Each of these is a pre-execution check: the authorization decision is made before funds move, not reconstructed afterward from logs.

The Authorization Scope An Authorization Scope is a CBOR map. The following members are defined; unknown members MUST be ignored.

apk (REQUIRED):

The thumbprint of the Attested Payment Key. This is the key whose "cnf" appears in the attestation evidence.

code (REQUIRED):

The endorsed software identity the attestation is expected to report, expressed as a digest. This is the value that makes the authorization specific to a program rather than to a deployment.

limits (REQUIRED):

The spending bounds. At minimum a maximum amount per payment and a maximum aggregate amount over a stated interval, each with an explicit unit. A scope with no upper bound MUST NOT be registered.

expiry (REQUIRED):

The time after which the scope is invalid. Scopes are short-lived by design; see .

rails (OPTIONAL):

The settlement systems on which the scope is valid. Absence means the scope is rail-agnostic, which relying parties SHOULD treat as broader than intended rather than as permission.

payees (OPTIONAL):

Constraint on permitted counterparties.

An Authorization Scope MUST NOT be widened by any party other than its issuer, and an agent MUST NOT be able to widen its own scope by any means, including by presenting a newer attestation. Narrowing MAY be performed by the executor.

Verification Before Settlement Before executing a payment presented under this specification, a Payment Executor MUST perform all of the following checks, and MUST NOT settle if any of them fails or cannot be completed:

1. The attestation evidence verifies against the expected Attester's trust anchors, and the freshness value in "eat_nonce" was supplied by the verifying party for this transaction. A replayed attestation MUST NOT be accepted.
2. The "cnf" key in the evidence equals the "apk" named in the scope.
3. The "key-attributes" claim asserts that the private key is non-extractable and was generated within the attested environment. An extractable payment key MUST be rejected: an extractable key can authorize payments from outside the environment whose properties are being relied upon.
4. The software identity reported by the attestation equals the "code" value in the scope.
5. The payment instruction is signed by the APK, and the instruction's terms are covered by that signature. Terms not covered by the signature MUST NOT be treated as authorized.
6. The payment falls within "limits", and the executor's own record of prior spending under this scope confirms the aggregate bound is not exceeded.
7. "expiry" has not passed.
8. A valid Receipt for the scope's registration is available from the Transparency Service, and the scope has not been superseded ().

An executor MUST distinguish, in whatever it reports to the instructing party, between "authorization refused" and "authorization could not be evaluated". Collapsing the two allows an outage in an attestation or transparency service to be indistinguishable from a policy decision, which in practice produces pressure to fail open. Executors MUST fail closed. An executor that cannot complete the checks above MUST NOT settle.

Registration on a Transparency Service The Authorization Scope, together with a reference to the attestation evidence and the endorsed software identity, is registered as a Signed Statement per . The resulting Transparent Statement and Receipt make three properties available to parties who were not present at authorization time:

• that a scope with these bounds existed and was registered before the payment, rather than reconstructed afterward;
• that the authorization named a specific software identity, which an auditor can compare against a build they can reproduce; and
• that the record is held by a party with no interest in how the transaction is later characterized, satisfying the common requirement that an agent's audit trail not depend on the agent's own account of events.

Registration Policy for a Transparency Service accepting these statements SHOULD require that the attestation evidence referenced by a scope verifies at registration time. A service MAY register statements whose evidence it cannot verify, but MUST NOT represent such registrations as attested. Evidence and scopes SHOULD be referenced by digest rather than by location alone, so that a later auditor can detect substitution of the artifact a Receipt refers to.

Expiry and Revocation Authorization under this specification is short-lived by construction. A scope SHOULD have an "expiry" no longer than is operationally necessary, and issuers SHOULD prefer reissuance to long lifetimes. This is a deliberate design choice. Revocation that depends on a signal reaching an executor in time is only as reliable as that signal; expiry requires no message to arrive, no service to be reachable, and no action by the revoking party. An issuer that stops reissuing has revoked, and the maximum exposure is bounded by the remaining lifetime. Where an explicit revocation signal is also available, it MAY be registered as a superseding statement on the Transparency Service. Executors SHOULD consult it, but MUST NOT rely on its arrival as the only bound on exposure. Implementers are warned that revoking authorization stops subsequent authorized payments; it does not by itself reverse or cancel obligations already created on a settlement system. Documents profiling this specification for a particular rail SHOULD state precisely what revocation does and does not undo on that rail.

Security Considerations Attestation proves provenance, not correctness. A verified attestation establishes that the running software is the endorsed software. It does not establish that the software is free of defects, that its authorization logic is sound, or that its behavior is desirable. Systems that present attested execution as a correctness guarantee will mislead the parties relying on them. Where the endorsed code is itself the authorization logic, the value of attestation is exactly that the logic cannot be silently replaced -- no more. Extractable keys void the property. If the private component of the APK can leave the attested environment, then a payment signed by it evidences nothing about where it was signed. This is why the "key-attributes" check in is mandatory rather than advisory. Attestation freshness. An attestation not bound to a freshness value supplied by the verifying party can be replayed by any party that has observed it, including after the attested environment has stopped running. The "eat_nonce" check is not optional. Scope inflation. The most likely deployment error is a scope broad enough to be operationally convenient -- unbounded aggregate, no expiry, no payee constraint -- which preserves the appearance of attested authorization while removing its effect. Registration Policies SHOULD reject unbounded scopes. Transparency is not confidentiality. Registering scopes publicly may disclose commercially sensitive information about an agent's spending authority. Implementers SHOULD register digests rather than plaintext where disclosure is a concern, and SHOULD consider that the existence and timing of registrations is itself observable. Verifier and Transparency Service availability. Because executors MUST fail closed, an unavailable verifier or Transparency Service denies service rather than degrading security. Deployments SHOULD plan for this explicitly; the alternative -- failing open under load -- is worse and MUST NOT be implemented. The Attester is trusted. This specification inherits the trust model of : relying parties trust the Attester's hardware root and its endorsers. A compromise of that root compromises every authorization derived from it.

Privacy Considerations Attestation evidence can be highly identifying, potentially including platform and firmware detail beyond what a payment decision requires. Deployments SHOULD convey to executors only the claims their policy consumes, and Transparency Service registrations SHOULD reference evidence by digest rather than embedding it. Correlation across payments is possible where the same APK is reused. Where unlinkability matters, issuers SHOULD scope keys narrowly and rotate them, accepting the additional attestation cost.

IANA Considerations This document has no IANA actions at this revision. A future revision is expected to request a CBOR tag or media type for the Authorization Scope, and registration of any new EAT claims should further revisions require them; the present design deliberately reuses existing claims.

Implementation Status Per . The author operates a payment facilitator in which the settlement key is generated inside an Intel TDX confidential computing environment and never exists outside it; the environment's software identity is endorsed on-chain and an open verifier checks the attestation, the endorsement, and the key binding before the service is treated as attested. A second deployment issues short-lived credentials gating access to a permissioned trading venue, where the issuing key is likewise generated inside the attested environment and credential lifetime is the bound on exposure, as described in . These deployments predate this document and do not implement it as written; they are offered as evidence that the pattern is operable, not as a conformant implementation.

References Normative References Informative References arXiv preprint 2607.12575

Acknowledgments This document exists because two specifications were written and not connected. The key binding it depends on is the work of the authors of , and the transparency model is that of . Reviewers in the x402 community materially improved the author's understanding of what payment executors can and cannot verify in practice.