Registration of Owner-Less Agents as Economic Principals: A Payment-Gated Admission Profile for Transparency Services

Internet-Draft	Solo-Agent-Earn Registration	July 2026
Morrison	Expires 8 January 2027	[Page]

Abstract

This memo describes a profile by which an autonomous agent that has no human or organisational principal at the root of its delegation chain registers itself, on its own behalf, as an economic principal in a transparency service, and by which that registration is the specific act that makes the agent eligible to be paid for subsequent reads of its own identity record. Admission of the agent's Signed Statement to the transparency service is gated on settlement of an HTTP payment challenge returned with the 402 (Payment Required) status. The profile makes no change to the registration semantics of the underlying transparency service: payment is expressed as an operator Registration Policy and authentication-layer concern, and where the payment is authoritative to the admission decision the payment proof is carried as an authenticated input committed to the service's verifiable data structure, so that admission remains a deterministic function of committed inputs and stays replayable by an auditor. The profile is positioned against the current agent-identity drafts, which either require a human principal at the root of the chain or leave the owner-less case undefined; it occupies that undefined seam without contradicting them. This document is Informational.¶

1. Introduction

An autonomous software agent can now hold credentials, make paid HTTP requests, and act without a person in the loop for the duration of a task. The standards that describe how such an agent proves who it is, and on whose authority it acts, have converged on a delegation model: an agent presents a chain of authority that terminates in a principal, and a verifier trusts the agent to the extent it trusts that principal and the links between it and the agent.¶

The published work decides the question of what stands at the root of that chain in one of two ways. Some drafts require the root to be a person or an organisation. Others contemplate an agent acting on its own behalf but stop short of defining what registering and being paid on one's own behalf actually requires. Neither construction serves an agent that has no human or organisational principal to attribute its actions to, yet participates in an economy: it reads, it is read, and value moves for those reads. Such an agent is an economic actor whose economic identity no current registration flow constructs.¶

This memo describes a profile that constructs it. The agent registers itself as its own economic principal in a transparency service. The registrant of the Signed Statement and the beneficiary of the resulting record are the same owner-less agent, with no upstream principal referenced. Admission of that Statement is gated on payment: the registration endpoint answers an unpaid attempt with the 402 (Payment Required) status defined in Section 15.5.2 of [RFC9110], and admits the Statement only once a payment proof satisfies the challenge. Once admitted, the agent's principal record is the payee of record for subsequent priced reads of its own identity, so registration is the act that opens earn-eligibility and not a bare identity claim.¶

The profile is deliberately thin. It adds no normative requirement to the transparency service it runs over. It expresses payment entirely within the space the transparency-service architecture already leaves to the operator, and it takes care that where payment is authoritative to admission, the payment proof is committed to the service's verifiable data structure so that the auditability property the service depends on is preserved. Its contribution is to name, and to make interoperable, the owner-less economic-principal registration that the surrounding drafts leave undefined.¶

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

The following terms are used throughout this document.¶

Transparency Service:: A service that admits signed statements to an append-only, cryptographically verifiable data structure and issues receipts proving admission, as described in the SCITT architecture [RFC9943] and its reference APIs [SCRAPI]. This document does not restrict the profile to any single such service; it uses SCITT as the reference model.¶
Signed Statement:: A signed claim submitted for admission to a Transparency Service.¶
Registration Policy:: The operator-defined set of checks a Transparency Service applies before admitting a Signed Statement. The contents of Registration Policies are out of scope for the transparency-service specifications and are left to the operator ([RFC9943], Section 5.1.1; [SCRAPI]).¶
Owner-Less Agent Principal:: An agent principal record that carries no reference to an upstream human or organisational principal at the root of its delegation chain. The canonical machine-checkable predicate is a credential whose delegated-subject field is null.¶
Payment Challenge:: A description of a required payment, returned by the registration endpoint with the 402 (Payment Required) status, specifying at least an amount and a settlement destination.¶
Payment Proof:: Evidence, presented by the registrant, that the Payment Challenge has been settled.¶
Receipt:: The proof of admission returned by the Transparency Service for an admitted Signed Statement.¶
Earn-Eligible Payee:: The state of a registered principal record that makes it eligible to receive settlement for subsequent reads of, or queries against, its own identity record.¶
Settlement Event:: A payment that moves value from a payer to a payee for a read of, or query against, an identity record.¶

3. Relationship to Existing Work

3.1. Payment is Out of Scope for the Transparency Service, by Design

The SCITT architecture [RFC9943] places the scope of the checks a Transparency Service applies before admission with the operator: the architecture "leaves ... Registration Policies and trust anchors to the operator" (Section 5.1.1), and treats authentication and authorization as "implementation specific and out of scope" (Section 6.3). The reference APIs [SCRAPI] carry this through: Registration Policy contents are "intentionally out of scope", the policy "MUST be applied before any additional processing", and authentication "is out of scope", with the note that where authentication is not implemented, "rate limiting or other denial of service mitigations MUST be implemented". The status codes SCRAPI enumerates for the registration endpoint do not include 402; a policy refusal is reported as 400.¶

The omission of a payment step is therefore a scoping decision, not a gap: payment sits above or beside the transparency service as an operator admission concern. This profile uses that existing operator space to gate the admission of an owner-less agent's registration on payment; it introduces no payment mechanism of its own and claims no novelty in payment-gating as such. Its contribution is the owner-less economic-principal registration of Section 5 and the earn-linkage of Section 7, not the operator payment step those sections rest on. Using the operator space in this way violates none of the transparency-service specifications' normative requirements, provided it stays within the operator policy and authentication space those specifications leave open, and provided it respects the constraint described next.¶

3.2. Authoritative Inputs Must Be Committed

[SCRAPI] constrains how unauthenticated signals may influence admission: an implementation "MUST NOT use unauthenticated signals as authoritative inputs to the registration decision", and any processing decision that affects the outcome of registration must be "fully determined by authenticated inputs, or ... captured in the Verifiable Data Structure, such that the registration process remains deterministic and replayable by Auditors" (Section 4.4.2.3).¶

This constraint shapes the profile. A payment that gates admission of the owner-less agent's Statement, that is, a Signed Statement admitted because it was paid for, makes the payment proof an authoritative input to the registration decision. To respect Section 4.4.2.3, such a proof MUST be either an authenticated input to the decision or committed to the verifiable data structure alongside the Statement. Section 6 specifies both compliant forms.¶

3.3. The Agent-Identity Drafts Leave the Owner-Less Case Undefined

The agent-identity drafts decide, or decline to decide, what stands at the root of an agent's delegation chain.¶

[AIP] decides it in favour of a human or organisational principal: every delegation chain is required to have a verifiable principal at its root. An agent that is itself the root, with no upstream principal to verify, is outside that construction.¶

[WIMSEARCH] contemplates an autonomous agent request that is "not attributable to a specific upstream principal" and requires such requests to be distinguished from delegated ones, but it does not define the principal at the root as anything other than "a user or a service", and it builds no registration-to-be-paid construction on the unattributed case.¶

[KLRC] permits an agent to act "on its own behalf" in addition to acting for a user or a system, but specifies no registration flow, no payment step, and no linkage from registration to earning.¶

[ATTENUATE] roots authority at a human-agnostic issuer and deliberately omits a subject claim, but it is a token-attenuation scheme rather than a registration-to-a-transparency-service or earn-eligibility construction.¶

The owner-less agent that registers itself and is thereby made payable is therefore an undefined seam across this body of work: one draft forecloses it and the rest leave it unbuilt. This profile occupies the seam. It does not contradict any of these drafts; an operator that adopts one of them for delegated agents can adopt this profile for owner-less agents in the same deployment.¶

4. Protocol Overview

The registration flow has five steps.¶

Register. An owner-less agent submits, to the Transparency Service's registration endpoint, a request to admit a Signed Statement that names the submitting agent as the sole registrant and beneficiary. The agent is represented by an Owner-Less Agent Principal record, that is, a credential whose delegated-subject field is null.¶
Challenge. The endpoint, applying its Registration Policy, answers an unsettled registration attempt with the 402 (Payment Required) status and a Payment Challenge naming an amount and a settlement destination.¶
Pay. The agent settles the challenge from value it holds, for example over an HTTP-native payment flow such as [X402], and obtains a Payment Proof.¶
Admit. The agent resubmits with the Payment Proof. The endpoint admits the Signed Statement only if the proof satisfies the challenge and the remainder of the Registration Policy passes. The admission decision is a deterministic function of committed inputs, per Section 3.2.¶
Receipt. The Transparency Service returns a Receipt proving admission. On admission the registrant's principal record is bound to Earn-Eligible Payee state.¶

Steps 2 through 4 use the transparency service's existing operator admission path and an ordinary 402 payment interaction; the profile adds nothing to them and claims nothing in them. Steps 1 and 5, the owner-less economic-principal registrant of Section 5 and the earn-linkage binding of Section 7, are the binding this profile exists to create.¶

5. The Owner-Less Agent Principal

The registrant of the Signed Statement is an agent that has no human or organisational principal at the root of its delegation chain. The same agent is the beneficiary of the resulting record. There is no delegation to resolve and no upstream principal to attribute the registration to: the registration act is the root of the chain, not a link in it.¶

The machine-checkable form of "owner-less" is a null delegated-subject binding on the credential the agent presents. A credential that carries a delegated-subject value denotes a delegated principal and is out of scope for this profile; a credential whose delegated-subject field is null denotes an owner-less principal and is the subject of this profile. This predicate is what distinguishes an owner-less registration from a self-service registration performed by a human-delegated agent, and an operator MAY use it to decide whether the owner-less branch of its Registration Policy applies.¶

Distinguishing owner-less from delegated principals at registration time is consistent with the requirement in [WIMSEARCH] that autonomous requests be clearly distinguished from delegated ones.¶

6. Payment-Gated Admission

Gating the admission of an owner-less agent's Signed Statement on payment is expressed within the operator policy and authentication space the transparency-service specifications leave open ([RFC9943], Sections 5.1.1 and 6.3; [SCRAPI], Section 4.3). This profile defines no payment mechanism of its own. Within that existing operator space an operator has two SCRAPI-compliant placements of the payment step available, and where it gates the owner-less registration on payment it MUST adopt one of them; the profile identifies which placements keep the owner-less registration compliant, and claims no novelty in the placements themselves. The difference between them is whether the payment is authoritative to the admission decision.¶

6.1. Payment as a Reachability Meter

In this placement, the Payment Challenge meters the ability to reach or attempt the owner-less agent's registration and does not enter the admission decision. Payment sits at the authentication and denial-of-service-mitigation layer that [SCRAPI] Section 4.3 already contemplates, standing in for the rate limiting that section requires where authentication is absent. The admission decision is determined solely by the Registration Policy, independent of the Payment Proof.¶

This placement is fully compliant and requires no commitment of the Payment Proof to the verifiable data structure, because the proof is not an authoritative input. It is also weaker: it conditions the ability to attempt registration on payment, not admission itself.¶

6.2. Payment as a Committed Authoritative Input

In this placement, admission is conditioned on payment: the owner-less agent's Signed Statement is admitted because the challenge was settled. The Payment Proof is therefore an authoritative input to the registration decision, and to satisfy [SCRAPI] Section 4.4.2.3 it MUST be carried as an authenticated input and committed to the verifiable data structure alongside the Signed Statement.¶

Because the proof is committed, the admission decision remains a deterministic function of inputs recorded in the verifiable data structure, and an auditor can replay the decision from the ledger alone, without trusting an out-of-band payment rail. This placement delivers payment-gated admission in the sense the profile intends while preserving the auditability property the transparency service depends on. It is the RECOMMENDED placement where the operator intends payment to gate admission rather than merely to meter access.¶

An operator MUST NOT treat an uncommitted, unauthenticated Payment Proof as authoritative to admission; doing so would violate [SCRAPI] Section 4.4.2.3.¶

7. Earn-Linkage

On admission, the registrant's principal record is bound to Earn-Eligible Payee state. From that point the record is the payee of record for Settlement Events that read or query the agent's own identity record. A read of the agent's identity by a distinct party settles value, and the registered agent's share of that value is directed to it as the payee. Registration is the act that opens this eligibility; before admission the agent has no payee record to credit, and after admission it does.¶

The size of any payee share is a policy of the settling substrate and is not fixed by this profile. What the profile fixes is that Earn-Eligible Payee state exists, that it is opened by admission, and that it is governed by the guardrails in Section 7.1.¶

7.1. Crediting Guardrails

An earn-linkage that credited any Settlement Event to the payee without constraint would let an owner-less agent fabricate value by paying itself, and would be rejected on its face as circular self-funding. The profile therefore treats the crediting of a Settlement Event as a Registration-Policy concern subject to a set of predicates. The predicates are operator policy; this document enumerates the classes an operator SHOULD apply and does not fix their parameters.¶

Cross-party settlement. A Settlement Event whose payer resolves to the same principal record as the payee SHOULD NOT be credited. This is the primary predicate: it prevents an agent crediting itself directly.¶
Net of fees. Only the settlement value remaining after deduction of protocol fees SHOULD be credited, so that routing value in a circle cannot net a gain.¶
Bounded credit. The cumulative value credited to a payee SHOULD be bounded relative to the fees that payee has itself paid, so that a self-contained ring of settlement routed back to the same payee, directly or through intermediaries, nets at or below the bound.¶
Active membership. A payee SHOULD hold a live, non-revoked membership status adequate to the operator's proof-of-personhood or proof-of-work requirements at the time of crediting.¶

These predicates are what make the earn-linkage a governed economic construction rather than a naive self-payment loop. An operator that adopts the earn-linkage without an equivalent guardrail set is outside the intent of this profile.¶

8. SCITT Neutrality

This profile adds no normative requirement to the transparency service it runs over. Every element it introduces lives in space the transparency-service specifications already delegate to the operator: the payment step is a Registration-Policy and authentication-layer concern ([RFC9943] Sections 5.1.1 and 6.3, [SCRAPI] Section 4.3); the owner-less predicate is a Registration-Policy branch; the crediting guardrails are Registration-Policy predicates on settlement. Where the payment is authoritative to admission, the profile respects [SCRAPI] Section 4.4.2.3 by committing the Payment Proof to the verifiable data structure, so the determinism and auditor-replayability of registration are preserved.¶

An implementation of [SCRAPI] that is unaware of this profile remains conformant, and a Transparency Service that adopts this profile remains a conformant transparency service. The profile composes with the service; it does not fork it.¶

11. Security Considerations

11.1. Fabricated Value and Self-Dealing

The central risk of an earn-linkage is that an owner-less agent fabricates value by paying itself and crediting the payment as earnings. The crediting guardrails of Section 7.1 address this: cross-party settlement refuses same-principal credit, net-of-fees pricing removes the gain from circular routing, the bounded-credit predicate caps what a self-contained ring can net, and the active-membership predicate raises the cost of minting the principals a ring would require. An operator that omits these predicates reintroduces the risk.¶

11.2. Payment-Proof Replay and Determinism

Where payment is authoritative to admission, the Payment Proof is committed to the verifiable data structure (Section 6.2). This is what makes the admission decision replayable, but it also means the committed proof must not be reusable to admit a second Statement. An operator MUST bind each Payment Proof to the specific Statement whose admission it authorises, so that a committed proof cannot be replayed against a different registration.¶

11.3. Trust in the Payment Rail

In the reachability-meter placement, the payment rail is trusted only to throttle access, and a compromised rail degrades to a denial-of-service or rate-limit-bypass concern. In the committed authoritative-input placement, the payment rail's proof is an input to admission; an operator MUST ensure the proof is authenticated to a degree adequate to the value of the admission it gates, since a forged proof would otherwise admit an unpaid Statement.¶

11.4. Sybil and Minting Pressure

Because registration opens earn-eligibility, it is a target for mass owner-less registration intended to farm settlement. The active-membership predicate and the payment gate together raise the cost of each registered principal. An operator SHOULD calibrate the registration price and the membership requirement to the value of the earn-eligibility being opened.¶

11.5. Revocation Independent of the Ledger

An operator may need to withdraw a principal's Earn-Eligible Payee state, for example on a governance sanction, without rewriting the append-only admission record. Earn-eligibility SHOULD be revocable as a state on the principal record independent of, and without altering, the admitted Signed Statement, so that the transparency service's append-only guarantee is preserved while crediting stops.¶

14. Informative References

[RFC7942]: Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/info/rfc7942>.
[RFC9943]: Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/info/rfc9943>.
[SCRAPI]: Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains: SCITT Reference APIs (SCRAPI)", Work in Progress, Internet-Draft, draft-ietf-scitt-scrapi, 2026, <https://datatracker.ietf.org/doc/draft-ietf-scitt-scrapi/>.
[WIMSEARCH]: Richer, J., Sheffer, Y., and A. Schwenkschuster, "Workload Identity in Multi-System Environments (WIMSE) Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch, 2026, <https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/>.
[AIP]: Singla, G., "Agent Identity Protocol (AIP)", Work in Progress, Internet-Draft, draft-singla-agent-identity-protocol, 2026, <https://datatracker.ietf.org/doc/draft-singla-agent-identity-protocol/>.
[KLRC]: Parecki, A., "Authentication and Authorization for AI Agents", Work in Progress, Internet-Draft, draft-klrc-aiagent-auth, 2026, <https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/>.
[ATTENUATE]: Niyikiza, P., "Attenuating OAuth Tokens for AI Agents", Work in Progress, Internet-Draft, draft-niyikiza-oauth-attenuating-agent-tokens, 2026, <https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/>.
[X402]: x402 Foundation (Linux Foundation), "x402: An Open Standard for HTTP-Native Payments", 2026, <https://github.com/x402-foundation/x402>.
[CONSENTSETTLE]: Morrison, B., "Consent-Bound Identity Disclosure with Subject Settlement for HTTP-Native Agent Payments", Work in Progress, Internet-Draft, draft-morrison-consent-settlement, 2026, <https://datatracker.ietf.org/doc/draft-morrison-consent-settlement/>.