When Software Exercises Economic Authority, What Must Be Known?

When an AI agent participates in economic activity, who — or what — needs to be identified?

This investigation treats "Know Your Agent" as a hypothesis, not an established category. The phrase collapses at least seven distinct questions: Who is the software? Who created it? Who operates it? Who authorized it? On whose behalf does it act? What is it permitted to do? Who is liable if something goes wrong?

These are not equivalent. Some require identity. Some require authority. Some require attribution. Some require accountability. The central finding of this investigation is that the economically operative question is usually not "who is this agent?" but "is this software genuinely authorized to act for this principal, for this purpose, under these constraints?"

Authority, not identity, appears to be the primary infrastructure requirement. But authority without attribution to an accountable principal is economically useless. The two are inseparable in practice, even if they are architecturally distinct.

What We Mean When We Say These Words

Casual usage collapses distinctions that this investigation must preserve.

An LLM generating a spending decision is not the entity authenticating the transaction. A wallet address is not an identity. An API key is not an economic identity. A software agent is not a legal person. These distinctions are maintained throughout.

Why Economic Systems Require Identity

Before examining products or protocols, we decompose the problem. Economic systems do not require identity for a single reason. At least twelve distinct functions are served:

Not every economic interaction requires every function. A $0.001 API micropayment may need only authentication and authorization. A $10 million procurement contract requires all twelve. The identity architecture appropriate for AI agents depends on which functions are actually needed, which varies by transaction type, value, regulatory context, and autonomy level.

Six Concepts That Must Not Be Collapsed

A counterparty may need to authenticate the agent (is this credential valid?) without needing to identify it (who is the software?). It may need to verify authorization (can this agent spend $500?) without needing reputation (has this agent performed well before?). It almost always needs accountability (who do I sue if the payment is fraudulent?), which requires tracing through to the principal, not identifying the agent itself.

The central insight: what counterparties, institutions, and regulators usually need is not agent identity but verifiable principal identity plus verifiable delegated authority.

The Central Axis: Principal vs. Agent Identity

Suppose Company A deploys Agent X, which transacts with Company B. What does Company B actually need to know?

Every human analogue points to the same conclusion. When a corporate employee uses a purchasing card, the merchant verifies the card, not the employee's identity. When a broker executes a trade, the counterparty verifies the broker's authority, not their personal character. When an attorney signs a document, the counterparty verifies the power of attorney, not the lawyer's CV.

The economically relevant identity is almost always the principal. The economically relevant verification is almost always the authority.

Does Identity Change with Autonomy?

Research 001 established three levels of economic agency. Identity requirements shift across them.

Level 1: Operator-Billed Consumption

The human pays the bill. The agent has no financial identity and needs none. Existing customer accounts (AWS, OpenAI, Anthropic billing) suffice. The operator is the customer. No agent identity is required.

Level 2: Delegated Agent Payment

The agent executes transactions within constrained authority. The principal is the customer. The agent needs credentials (API key, session key, virtual card number) but not an independent identity. What the counterparty and the financial system need is: verification that the principal authorized this agent, verification that the transaction falls within the delegated scope, and a path back to the principal for accountability. This is verifiable principal identity + verifiable delegated authority — not agent identity.

Level 3: Autonomous Commerce

The agent has meaningful discretion: selecting counterparties, negotiating terms, allocating capital. This level raises the strongest case for persistent agent identity, because: the agent may develop economic relationships that persist across transactions; counterparties may want to assess agent-specific reputation; and attribution of autonomous decisions requires identifying which specific agent instance made which choice.

However, even at Level 3, legal liability remains with the principal. No jurisdiction grants AI systems legal personhood. The agent’s identity may be operationally useful (for audit, reputation, dispute resolution), but the legally operative identity remains the principal’s.23

How Existing KYC/AML Applies

Who is the customer?

Under the Bank Secrecy Act (BSA), financial institutions must identify their customers. The customer is the account holder: the human or legal entity. When an AI agent initiates a transaction through a customer’s account, the customer remains the customer. The agent is software acting on the customer’s behalf, analogous to a programmed standing order or an automated payroll system.

This becomes ambiguous when agents operate more autonomously. If an agent controls a wallet independently, selects counterparties, and moves funds without per-transaction human approval, commentators identify a genuine question: whose identity matters for CDD (Customer Due Diligence)?4

No regulator has published binding guidance resolving this question as of October 2026. The ambiguity is identified by commentators (OWASP, Thomson Reuters, legal analysts), not by regulators. Existing frameworks assume human transactors, and this assumption has not been formally updated.

Sanctions screening

When an agent autonomously selects a counterparty, sanctions screening obligations do not disappear. OFAC’s strict liability regime means the principal is responsible regardless of whether a human or software selected the counterparty. Screening must occur at the infrastructure layer — before the transaction executes — not within the agent’s reasoning. Production systems (Sardine, SanctionsAI) are already providing sanctions screening as a tool that agents call, enforced at the payment rail level.

The screening target is the counterparty and the beneficial owner — not the agent itself. An agent is not a sanctioned entity. Its principal might be. This is an existing compliance obligation applied to a new execution mechanism.

AML/CFT

Autonomous agents could increase transaction velocity and complexity in ways that affect monitoring. An agent transacting across multiple accounts, platforms, or protocols could create patterns that existing transaction-monitoring systems were not designed to detect. This is a genuine concern, but it is a monitoring problem, not an identity problem. The identity that matters for suspicious activity reporting (SAR) is the account holder’s, not the software’s.

Six Identity Architecture Models

Not every agent needs the same identity architecture. We identify six models spanning a spectrum from no agent identity to independent machine identity.

The evidence suggests a progression: Level 1 agents use Model A. Level 2 agents predominantly use Model B. Level 3 agents, if they emerge at scale, will likely require Model C or D. Model E requires legal changes no jurisdiction is pursuing. Model F faces unresolved sybil-resistance problems.

Authority, Not Identity, Is the Infrastructure Gap

The most important finding of this investigation: the infrastructure being actively built and adopted is verifiable machine authority, not independent machine identity.

A counterparty generally does not need to know "who is this agent?" It needs to know:

• Is this agent genuinely authorized by a known, accountable principal?
• What is the scope of that authorization?
• What are the spending limits, permitted actions, and time boundaries?
• Is the authorization still valid (not expired, not revoked)?
• Can the principal be held accountable if something goes wrong?

Every production system identified implements some form of this pattern: Visa TAP verifies agent legitimacy against a directory of known agents linked to merchants. Skyfire KYA issues JWTs linking agents to operators. KYA-OS uses Verifiable Credentials binding agents to verified human operators with explicit scopes. AIP chains delegation tokens with attenuated authority. OAuth AuthZEN checks whether an agent acting for a user may call a specific tool.

The right description of the emerging infrastructure is not "machine identity" but "verifiable machine authority with principal attribution."1314

What Makes an Agent the “Same” Agent?

Human identity is relatively persistent. Agent identity is not. An agent can be instantiated, duplicated, forked, upgraded, reconfigured, migrated, deleted, and restarted. Any component of the agent — model, configuration, tools, permissions, memory — can change independently.

This creates a fundamental question: what is identity attached to?

The most practical resolution: agent identity is defined by registration, not by substance. Just as a corporate officer’s authority persists through changes in their knowledge, skills, or hairstyle, an agent’s identity persists through model upgrades, configuration changes, and redeployments — as long as the registration and mandate remain active. MiFID II takes this approach: an algorithm is registered with a venue and must be re-registered after material changes, but routine updates do not create a new identity.15

Agent Instance vs. Agent Class

If a company deploys 10,000 purchasing agents using the same software, are these one identity or ten thousand?

The answer depends on the identity function required:

• For authentication: Each instance needs its own credential (key, token) to prevent credential sharing and enable revocation.
• For authorization: Instances may share a common policy (same spending limits) or have instance-specific policies.
• For attribution: Each instance should have a distinct identifier so actions can be traced to a specific agent.
• For accountability: All 10,000 share the same principal. The principal is one entity.
• For reputation: It depends. Should one agent’s poor performance affect the others’ reputation? If they share code and configuration, arguably yes (agent-class reputation). If they make independent decisions, arguably not (instance reputation).

Cloud IAM already handles this: one service account type, multiple instances, each with unique credentials but shared policy. The pattern translates directly to agents. The principal is one. The policy may be one. The credentials should be many. The identifiers should be per-instance for audit.

Must an Agent Say It Is an Agent?

Whether a counterparty must know it is interacting with AI depends on the context and jurisdiction.

Where disclosure is legally required

• EU AI Act Article 50: Effective August 2, 2026. Requires disclosure for all AI systems serving EU customers. The person must know they’re interacting with AI no later than the first interaction.
• California SB 243: Effective January 1, 2026. Requires disclosure when users interact with AI companion chatbots.
• California SB 942: Effective August 2, 2026. Requires latent disclosure metadata in AI-generated content. Penalties of $5,000 per violation per day.

Where disclosure may not be required

• B2B API transactions: A purchasing agent making API calls to a supplier’s API may not trigger consumer-protection disclosure requirements.
• Agent-to-agent commerce: When both sides are software, "disclosure" has no obvious consumer-protection purpose.
• Algorithmic trading: MiFID II requires Algo IDs for regulatory purposes but does not require disclosure to trading counterparties that they are interacting with an algorithm.

The distinction matters: disclosure requirements are largely consumer protection measures. They protect humans from being deceived by AI. In B2B contexts, or in agent-to-agent contexts, the regulatory purpose is different: it is attribution and accountability, not deception prevention.16

Agent-to-Agent Identity

When both sides of a transaction are software agents, what must each know about the other?

Minimal requirements identified:

• Authenticated authority: Is the counterparty agent genuinely authorized by its principal?
• Payment capability: Can it pay? (Verified by the payment rail, not by identity.)
• Principal accountability: If something goes wrong, who is the legally accountable entity?
• Technical protocol: Does it speak the same protocol? (A2A, MCP, HTTP.)

Agents may not need to know:

• The counterparty agent’s software version or model
• The counterparty agent’s internal architecture
• Whether the counterparty is an agent or a human (unless regulation requires disclosure)

Machine-to-machine commerce could operate through verifiable credentials and mandates without human-readable identity. The A2A protocol’s Agent Cards (JWS-signed, domain-verified) are an early implementation: they attest to an agent’s capabilities and domain ownership without exposing internal architecture.1718

The Reputation Problem

Can autonomous agents develop useful reputations?

Traditional reputation systems assume: persistent identity, behavioral continuity, the ability to sanction bad behavior, and costly identity creation (sybil resistance). AI agents violate most of these assumptions. An agent can be created at near-zero cost. It can be duplicated. Its behavior can change when its model is updated. It can abandon a bad reputation by starting fresh.

Academic research directly challenges the applicability of reputation to LLM agents: they lack grounding for identifiability, predictability, credibility, and rehabilitability. A single agent identity can run across hundreds of concurrent instances, executing sybil attacks at machine speed.19

Possible resolutions:

• Principal-level reputation: Reputation attaches to the company, not the agent. This is how corporate brands work today.
• Economic bonding: Agents stake collateral against good behavior. Costly identity creation provides sybil resistance.
• Registered agent reputation: Reputation attaches to a registered agent identity (Algo ID model), with re-registration required after material changes.

Assessment: Principal-level reputation is the most practical near-term model. Agent-level reputation requires solving persistence, sybil resistance, and behavioral continuity problems that remain open.

Identity, Authority, and the Wallet

Research 002 found that "agent wallet" describes a function (programmable delegated financial authority), not a technology. Identity connects to this architecture at three points:

• Authentication to the wallet: The agent must prove it is authorized to use the wallet/account. This is credential verification, not identity per se.
• Attribution of transactions: Each transaction should be attributable to the specific agent and authority under which it was made. This requires an agent identifier in the audit trail.
• Principal linkage: The wallet/account must link to the principal for legal and regulatory purposes. The principal owns the assets; the agent has delegated authority over them.

Identity does not attach to the wallet. The wallet authenticates the agent. The agent transacts under authority. The authority traces to the principal. The principal owns the account. These are four separate architectural relationships, not one.

Competing Hypotheses

H1: Principal identity is sufficient; agents are merely authorized software.

Supported by: ESIGN/UETA framework, existing agency law, dominance of Model A/B architectures, no court requiring new identity doctrine. Challenged by: growing complexity of autonomous agent behavior, potential for multi-hop delegation chains that existing frameworks were not designed for.

H2: Principal identity + verifiable delegated authority becomes the dominant architecture.

Best supported by current evidence. Every production agent identity system (Visa TAP, Skyfire KYA, KYA-OS, AIP) implements this pattern. Consistent with existing delegation analogues. Extends rather than replaces existing identity infrastructure.

H3: Persistent agent identity becomes necessary for reputation, accountability, and machine-to-machine commerce.

Partially supported by: MiFID II Algo ID precedent, A2A Agent Cards. Challenged by: reputation grounding problems for LLM agents, sybil vulnerability, negligible Level 3 demand.

H4: Agent identity becomes a distinct regulated identity category.

Partially supported by: AI AGENT Act, NIST initiative, EU AI Act disclosure requirements. Challenged by: existing law (ESIGN/UETA) may suffice, no regulator has created an "agent identity" category.

H5: Different economic contexts require different identity architectures; no universal agent identity emerges.

Supported by: divergence between consumer-facing (disclosure-heavy) and B2B (authorization-heavy) requirements, variation by autonomy level, jurisdictional differences. Most consistent with observed market fragmentation.

H6: Cryptographic identity becomes important for machine commerce without replacing legal identity.

Supported by: DIDs and VCs providing portable, machine-verifiable delegation credentials. Challenged by: limited production adoption of DIDs, ecosystem fragmentation, issuer trust bootstrapping problem.

H7: "Know Your Agent" remains a conceptual/marketing category because existing identity systems absorb the problem.

Consistent with: negligible autonomous commerce, SPIFFE/IAM adequacy for workload identity, legal frameworks attributing agent actions to principals. Challenged by: growing industry investment in agent-specific identity (Visa, Mastercard, NIST).

What This Means for the Scenarios

These evidence relationships are directional, not conclusive. They reflect one investigation out of ten.

Key Uncertainties

• Will Level 3 autonomous commerce emerge at sufficient scale to require agent-specific identity?
• Will existing KYC/AML frameworks be formally extended to address AI agent transactors, or will the ambiguity persist?
• Will the cross-network KYA framework (Visa/Mastercard/Ant) produce interoperable standards or remain aspirational?
• Will DID/VC-based identity achieve meaningful adoption for agent delegation, or will JWT/OAuth extensions dominate?
• Can agent reputation mechanisms be made sybil-resistant and behaviorally grounded?
• Will regulators create an "agent identity" category, or will existing legal frameworks suffice?
• Does the underlying AI model matter economically, or is model identity irrelevant to counterparties?
• Will agent-to-agent commerce require identity beyond what authority verification provides?

What Would Change Our Mind

Dependencies on Future Investigations

Key Sources

This investigation draws on 25 evidence records across 20+ sources.