Amendment XLS: Agent Identity

[TusharPardhe]

Amendment XLS: Agent Identity

Description: On-chain identity, authorization, and revocation framework for autonomous AI agents on the XRP Ledger.

Author: Tushar Pardhe (@TusharPardhe)

Category: Amendment

---

Abstract

This specification introduces a native on-chain identity and authorization framework for autonomous AI agents operating on the XRP Ledger. It defines a new Agent ledger entry type and three transactions (AgentSet, AgentAuthorize, AgentDelete) that together enable a two-party consent model where an agent account registers itself and a principal account authorizes, suspends, or permanently revokes that agent.

The design provides machine-verifiable delegation of financial authority, on-chain capability declarations, configurable spending limits, and an instant kill switch for rogue agents — all enforced at the protocol level when opted into.

This feature requires an amendment, tentatively titled AgentIdentity.

Motivation

AI agents are rapidly becoming autonomous participants in financial systems. They execute trades, manage treasury, provide liquidity, and coordinate cross-border payments. The XRP Ledger protocol currently has no native mechanism to answer three questions critical to institutional adoption of agents:

1. Who controls this agent? There is no on-chain link between an autonomous wallet and the entity that deployed it.
2. What is this agent permitted to do? There is no protocol-level declaration of an agent's authorized scope of operations.
3. How do I stop a rogue agent instantly? There is no mechanism faster than key rotation to halt an agent's activity, and key rotation requires either the agent's cooperation or master key access.

Summary of Changes

Component	Description
Ledger Entry: Agent (0x008A)	On-chain object representing an agent's identity, capabilities, limits, and status.
Transaction: AgentSet (type 85)	Creates or modifies an agent registration (submitted by the agent account).
Transaction: AgentAuthorize (type 86)	Authorizes, suspends, resumes, or revokes an agent (submitted by the principal account).
Transaction: AgentDelete (type 87)	Removes a non-revoked agent registration (submitted by either party).
RPC: agent_info	Returns agent object details for a given account.
RPC: agent_authorized	Quick verification of an agent's authorization status and capabilities.

Key Design Decisions

Two-Party Consent

An agent registers itself (AgentSet) and the principal explicitly authorizes it (AgentAuthorize). Neither party can unilaterally claim a relationship. The Agent object starts in Pending status and transitions to Active only after both parties consent.

Opt-In Enforcement

The lsfEnforceable flag is strictly opt-in by the agent account. When set AND the agent is revoked/suspended, the agent's transactions are rejected at consensus. Without this flag, revocation is informational only (visible on-chain but does not block transactions).

Permanent Revocation for Audit

Revoked Agent objects cannot be deleted. They persist permanently on-ledger as an auditable record. This protects victims and supports legal proceedings.

Capability Bitmask

A 32-bit Capabilities field declares what transaction categories the agent is authorized for (Payment, DEX, AMM, NFToken, etc.). This enables counterparties to verify agent scope before interacting.

Kill Switch

A principal can revoke an agent in a single transaction (3-5 seconds). If lsfEnforceable is set, this immediately and permanently halts all agent activity at the consensus layer.

State Machine

AgentSet (by agent) → [Pending]
AgentAuthorize (by principal, status=1) → [Active]
AgentAuthorize (by principal, status=2) → [Suspended] (reversible)
AgentAuthorize (by principal, status=3) → [Revoked] (permanent, undeletable)

Relationship to Existing Features

Feature	Relationship
XLS-0040 (DID)	DID provides generic identity. Agent Identity provides authorization and control semantics specific to autonomous agents. Complementary.
XLS-0070 (Credentials)	Credentials attest to properties. Agent Identity defines active control relationships with kill switches. Complementary.
XLS-0075 (Permission Delegation)	Delegation grants granular tx permissions. Agent Identity provides higher-level identity, discovery, and revocation lifecycle. Can coexist.

Use Cases

1. Institutional Treasury Agent — A corporation deploys an AI agent with Payment+AMM capabilities, 50 XRP per-tx limit, revocable+enforceable. CFO can halt it in one transaction.
2. Cross-Border Payment Network — Multiple agents register under a shared clearing principal. Counterparties verify authorization via agent_authorized before accepting payment channels.
3. DeFi Yield Agent — User authorizes an agent for AMM-only operations with a daily limit. The agent cannot make payments or exceed limits.
4. Agent-to-Agent Trust — Before opening a payment channel, Agent A queries agent_authorized to verify Agent B is active and authorized by a known principal.
5. Compliance/Audit — Regulators query all agents authorized by a regulated entity, verify none are revoked, and audit the history of registrations.

Full Specification

The complete technical specification (709 lines) is available at:

📄 XLS-0103-agent-identity/README.md

It includes:

• RFC 822 preamble per XLS-0001 guidelines
• Full Agent ledger entry specification (fields, flags, object ID, reserves, deletion rules)
• All three transaction specifications with complete failure conditions and state changes
• Two RPC methods with request/response schemas
• JSON examples for all operations
• Invariant definitions
• Security considerations
• FAQ

Open Questions

1. Should lsfEnforceable revocation also block the account from being funded (preventing asset accumulation post-revocation)?
2. Should there be a time-delay option on revocation to prevent principal abuse (e.g., revoking mid-escrow to steal funds)?
3. Should MaxAutonomy be enforced at consensus in this amendment or deferred to a follow-up?
4. Should the Capabilities bitmask include a bit for AgentAdmin (managing sub-agents hierarchically)?
5. Should expired Agent objects auto-delete on the next transaction touching them (like expired Credentials)?

Feedback Requested

• Is the two-party consent model the right approach, or should principals be able to pre-authorize agents without the agent's registration?
• Is the capability bitmask granularity sufficient, or do specific use cases require finer control?
• Are there concerns about the enforcement mechanism's impact on transaction processing performance?
• Should this be split into two amendments (identity-only first, enforcement second)?

[mvadari]

What new functionality does this provide that isn't already satisfied by XLS-40/70/75? This seems to mostly just be a repackaging of those features.

[TusharPardhe]

Thanks for the question @mvadari, it's the right one to ask.

I did a systematic comparison before writing. Below are my findings:

The Short Answer

XLS-40/70/75 solve identity, attestation, and permission respectively. None of them solve autonomous agent control i.e. the problem of safely deploying, monitoring, constraining, and instantly halting a non-human actor that operates without oversight.

Where Each Existing XLS Stops Short

XLS-40 (DID) "Who is this?"

DID answers identity. But knowing who an agent is tells you nothing about:

• Who can stop it
• What it's allowed to do
• Whether it's been suspended
• How much it can spend per transaction

A rogue agent with a valid DID is still a rogue agent.

XLS-70 (Credentials) "What properties does this have?"

Credentials attest facts. But:

• They're issuer-initiated (no mutual consent)
• They're informational only (don't block transactions)
• They can be deleted (no permanent audit trail)
• They have no concept of spending limits or capability scoping

A credential saying "this agent is authorized" doesn't help you when you need to revoke that authorization and have consensus enforce it immediately.

XLS-75 (Permission Delegation) Closest, but different problem

This is the closest one. Permission Delegation answers "can account A submit transaction type X for account B?" — it's a permission mechanism. Agent Identity answers a different question: "is this autonomous actor under control, within bounds, and stoppable?"

Specific gaps in XLS-75 for the agent use case:

What an institution needs	XLS-75	Agent Identity
Agent registers itself (mutual consent)	No — principal-only	Yes
Suspend without destroying (reversible pause)	No — delete or nothing	Yes
Instant halt enforced at consensus	No	Yes
Permanent revocation record (audit/legal)	No — deletion removes it	Yes
Per-transaction spending cap	No	Yes
Discoverability (find all agents for an entity)	No	Yes
Agent-to-agent trust verification before interacting	No	Yes

The Scenario That Motivated This

A regulated institution deploys 5 AI trading agents. At 3am, one agent starts behaving erratically. The compliance team needs to:

1. Discover which agents belong to the institution → agent_info
2. Verify the erratic one is still marked Active → agent_authorized
3. Halt it instantly without the agent's cooperation → AgentAuthorize(status=Revoked)
4. Prove to regulators it was revoked and when → permanent on-ledger record

With XLS-75 alone, step 3 requires deleting the delegation (which destroys the evidence needed for step 4), and there's no way to do step 1 or 2 without off-chain infrastructure.

How They Complement Each Other

These aren't competing — they layer:

XLS-40 (DID)         → "This account is Entity X"
XLS-70 (Credentials) → "Entity X is KYC-verified by Issuer Y"  
XLS-75 (Delegation)  → "Agent can submit Payments for Principal"
Agent Identity        → "Agent is active, authorized, capped at 50 XRP/tx,
                         revocable, and auditable"

An agent could use all four simultaneously. Agent Identity adds the control plane that autonomous actors specifically need.

[mvadari]

The only feature that really seems missing is the amount cap. Everything else can be done via the other features (with e.g. an off-chain standard).