Universal Participant Identity for the AI-Enabled Economy

The fifteen requirements

The paper's core contribution is fifteen first-principles requirements that identity must satisfy for autonomous participants operating across organizational and jurisdictional boundaries at machine speed without human supervision. The full derivation is in Part 2. The landscape evaluation against these requirements is in Part 3.

Verification and evaluation (1 through 9)

What a receiving governance system needs to identify and evaluate a stranger's participant.

1. Entity classification
2. Governance scope binding
3. Ownership with portable behavioral history
4. Concurrent delegation
5. Model and runtime provenance with specialized third-party certification
6. Compromise response at machine speed
7. Output provenance
8. Jurisdictional and tax binding
9. Self-identification at the network layer

Contract negotiation (10 through 15)

What two governance systems need from each other to form a mutually binding contract autonomously.

10. Actions classification
11. Financial commitment ceiling
12. Data handling certification
13. Insurance and liability attestation
14. Multi-agent workflow authorization
15. Dispute resolution binding

The landscape evaluation finds partial coverage of the first nine requirements and total absence of the contract negotiation six across every entry evaluated, including established standards, emerging IETF specifications, platform-native implementations, and commercial products.

Abstract

The AI-enabled economy requires identity infrastructure that serves not only software agents but every class of autonomous participant: robots, vehicles, sensors, language models, governments, corporations, and the humans on whose behalf they all operate. Current identity standards and commercial products address authentication within platform boundaries but leave unanswered the questions that determine whether an interaction between strangers can proceed: what a participant is authorized to do, who certified it, what jurisdiction governs it, and what conditions apply to its outputs.

This paper derives fifteen first-principles requirements that identity must satisfy for autonomous participants operating across organizational and jurisdictional boundaries at machine speed without human supervision. Nine address what a governance system needs to verify a stranger's participant. Six address what two governance systems need from each other to form a mutually binding contract autonomously. A systematic evaluation of the current landscape, spanning established standards, emerging IETF specifications, platform-native implementations, and commercial products, finds partial coverage of the first nine requirements and total absence of the contract negotiation six. The paper argues that certificate-based identity with governance-enabling attributes, verified by independent trusted third parties including specialized certification bodies, is the architectural direction the economy requires.

Keywords: AI agent identity, autonomous governance, certificate-based identity, X.509, contract negotiation, trust architecture, WebPKI, independent attestation

Part 1: The Identity Problem Is Universal

The silo that works today

Most agentic AI workflows deployed in production today operate inside a single platform. The major platform vendors, from CRM and enterprise automation to data lakehouse and IT service management, each run agents natively within their own ecosystems. Agent identity is handled by the platform's own directory services, its own access control model, and its own governance tooling, all scoped to the platform tenant. In each case, agent identity is an internal concern: the platform knows who its agents are, what they can access, and what governance rules apply, because all of it lives inside the same boundary.

This works. Inside a single platform operating within a single tenant, identity is a solved problem. The platform issued the credential, the platform enforces the policy, and the platform holds the evidence. There is no trust boundary to cross, no unknown counterparty to evaluate, no reason to prove anything to anyone outside.

But this is also why the current generation of platforms has no incentive to expand their identity specifications beyond their own boundaries. Each vendor's identity model is purpose-built for its own ecosystem. Agents authenticate through that platform's directory, governed by that platform's policies, verified by that platform's tools. None of these identity models carry governance scope, behavioral history, third-party certification, or any of the attributes that a counterparty outside the platform would need to evaluate before trusting that agent.

The moment agentic workflows need to exit these locked ecosystems, the identity model breaks. An agent built on one platform that needs to communicate with an agent built on a different vendor's platform has no shared identity framework, no way to verify the other's governance scope, and no basis for trust beyond whatever point-to-point API integration the two organizations have manually configured. Even organizations with a pre-existing relationship face a substantial engineering effort to bridge incompatible identity models, typically requiring a custom gateway layer between the two platforms that is expensive to build, expensive to maintain, and brittle when either platform updates its identity specifications. Few organizations will invest in that kind of integration for a single partnership, and none can do it at the scale the AI-enabled economy demands.

This paper is about the identity infrastructure the AI-enabled economy will require once agentic workflows, and the much broader set of autonomous participants operating alongside them, leave the walled garden of single-platform silos.

Participant classes

The AI-enabled economy includes participants that no existing identity system was designed to serve. Software agents are the most visible and urgent class, but they share the economy with physical robots, autonomous vehicles, and sensor networks. They share it with language models, governments, and corporations. They share it with non-profit institutions and the humans on whose behalf all of these operate. The following classes are not a complete taxonomy. They are a representative set chosen to illustrate the range of participants whose identity the economy must accommodate.

Sovereign and municipal governments. Governments will participate in the AI-enabled economy in ways that go well beyond regulation. A national government adopting AI-driven automation will process tax returns, issue passports, and manage social welfare disbursements through autonomous systems. But government adoption of AI will not stop at constituent services. It will extend into financial regulation, tax enforcement, scientific research, public health oversight, and the full range of sensitive and classified workflows that governments operate, from defense logistics and intelligence analysis to diplomatic coordination and critical infrastructure protection. In each of these functions, the government's identity will serve as the root authority: the entity that attests to the environment's integrity, signs for the agents operating within it, and stands behind the decisions those agents produce. At the municipal level, a municipal government that issues building permits through an automated system, manages traffic infrastructure through AI-driven optimization, or processes zoning variance applications needs every action traceable to the governing authority's identity. Citizens receiving an automated permit decision need assurance it carries the same legal standing as one signed by a human official, and that chain of authority must be cryptographically verifiable, not simply asserted.

Corporations and commercial organizations. From a multinational deploying thousands of procurement agents across global supply chains to a small business running a single customer-service chatbot, commercial organizations need identity that establishes liability, regulatory jurisdiction, and the governance scope within which their agents operate. A corporation's identity is what binds its agents' commitments back to a legal entity that can be held accountable. When a procurement agent commits to a purchase order, the counterparty needs to verify that the commitment traces back to an organization with the legal capacity and financial standing to honor it.

Non-profit organizations, universities, schools, and research institutions. These participants operate under governance frameworks distinct from commercial enterprises. A university research lab's agents handling genomics data operate under IRB protocols and data-use agreements that bear no resemblance to the rules governing a retailer's pricing agents. A school district deploying AI tutoring agents operates under student privacy regulations that impose strict constraints on what data the agents can access and retain. A hospital deploying AI agents for diagnostic support, imaging analysis, or treatment recommendations operates in one of the most heavily regulated environments in any economy. In the United States, those agents must comply with HIPAA and navigate a complex insurance billing ecosystem where claims processing, prior authorization, and coverage verification generate their own streams of sensitive data. In Canada or the European Union, the insurance paperwork largely disappears under universal healthcare models, but the privacy obligations around patient health records are equally strict under provincial health information legislation or the GDPR, and the clinical workflows involving diagnostics, lab results, and imaging remain just as sensitive regardless of how care is funded. A hospital's AI agents handle data where errors carry life-or-death consequences, and the governance requirements they operate under differ not only from commercial enterprises but from one jurisdiction to the next. Their identity must reflect those distinct governance requirements so that counterparties and regulators can verify compliance without understanding the internal structure of every institution they encounter.

Humans. The AI-enabled economy does not replace human identity. It depends on it. A human whose personal assistant agent manages household bills, schedules maintenance, and negotiates utility rates needs an identity framework that binds the agent's authority back to the human principal, limits what the agent can commit on the human's behalf, and provides a clear chain of accountability when something goes wrong.

Robots, autonomous vehicles, and other autonomous devices. A household helper robot, an industrial robot on a chemical plant assembly line, an agricultural robot operating autonomously in a field, and a self-driving car navigating city streets all carry physical-world liability. The defining shift for these devices is that they will increasingly be managed not by humans but by other autonomous systems. A fleet of self-driving cars will be coordinated by AI-driven fleet management. Factory robots will be orchestrated by AI production systems that allocate tasks, monitor performance, and adjust workflows in real time. Agricultural robots will operate under AI systems that plan planting, irrigation, and harvesting across entire fields. In every one of these scenarios, the managing AI must be able to identify each device it works with, verify that the device is what it claims to be, confirm that it is certified and authorized for the task at hand, and communicate with it as a known and trusted participant. Without verifiable identity, a device is invisible to these systems. It cannot join a coordinated workflow, it cannot receive instructions from the managing AI, and it cannot report its status in a way that other participants can trust. In each case, the device needs identity not merely to be recognized but to prove it is certified, authorized, and permitted to participate in the workflows and transactions it encounters. Without that proof embedded in its identity, every system the device interacts with must either trust the device's operator on faith or refuse to engage.

Sensors, cameras, and devices that participate in automated workflows. This category spans from temperature sensors in cold-chain logistics to traffic cameras feeding municipal AI systems to cameras streaming reconnaissance from a battlefield. It includes devices most people would never associate with the word "identity": streetlights whose brightness is regulated by AI-driven energy optimization, traffic signals whose timing is adjusted based on real-time congestion analysis, environmental monitors reporting air quality to regulatory compliance systems. The moment any of these devices feeds data into an AI-driven workflow, the consuming system needs to know what it is receiving data from, whether that source is authentic, and whether it should be trusted.

Language models, AI agents, and composite AI systems. Software agents acting on behalf of principals, language models serving API endpoints, and multi-agent orchestration systems coordinating complex workflows. This is the participant class that has received the most attention, and for good reason: agentic deployments are accelerating faster than identity infrastructure can keep pace. But the identity requirements for software agents are a subset of the universal requirements, not the whole problem.

Scenarios that make identity requirements unavoidable

Abstract requirements become concrete when placed in specific operational contexts. The following scenarios span the full range of participant classes and surface requirements that remain invisible if the analysis is limited to software agents communicating through APIs.

Smart infrastructure under attack. A city deploys an AI system to manage traffic flow across hundreds of intersections. The system ingests feeds from street-level cameras, analyzes congestion patterns, and adjusts traffic signal timing to move vehicles more efficiently, sometimes redirecting traffic away from congested corridors onto less burdened routes. Now consider what happens when one of those cameras is compromised. The attacker feeds fabricated congestion data to the AI system, which responds by adjusting signals on the basis of conditions that do not exist: holding green lights on approaches that are already gridlocked, redirecting emergency vehicles down corridors the attacker has deliberately congested, or creating collision conditions at intersections where the real traffic pattern is nothing like what the AI believes. This is not speculative. It is the kind of scenario action thrillers have dramatized for years, and it becomes plausible the moment real infrastructure is managed by AI systems consuming data from devices whose identity and integrity are unverified. The camera did not need verifiable identity when a human operator watched its feed and applied judgment. The moment an AI system acts on that feed autonomously, the camera needs identity that the consuming system can check before trusting the data.

Government as root authority. When a national government operates AI systems for citizen services, from processing tax returns to managing social welfare disbursements, the government's identity serves as the trust anchor for the entire workflow. Citizens interacting with a government AI system need to know that the system operates under the government's authority and that its outputs carry legal weight. When the same government operates AI within classified or sensitive environments, the government's identity attests that the environment is authorized for the classification level, that the agents operating within it are approved, and that the outputs produced carry the government's official endorsement. At the municipal level, a city government that processes building permit applications through an automated system, or that issues decisions about zoning variances, needs every action traceable to the governing authority. Citizens receiving an automated permit decision need to know it carries the same legal weight as one signed by a human official.

A self-driving car pays for a charge. An autonomous vehicle pulls into a charging station operated by a company neither the vehicle nor its owner has ever interacted with. The question the charging station must answer before initiating the session is straightforward: is this vehicle authorized to perform a financial transaction? But answering that question requires verifiable proof from a source the charging station can trust. The vehicle's owner is a stranger. The owner's own assertion that the car is authorized to spend money carries no more weight than any other stranger's claim. What is needed is an independent, trusted third party whose word both sides accept: an authority that has certified this vehicle is verified, that it belongs to a specific owner, and that it is authorized for financial transactions up to a certified limit. The charging station does not need to trust the owner. It trusts the authority that issued the certification, verifies the vehicle's identity against that certification, and proceeds.

Data authenticity in financial decision-making. A major bank deploys a team of AI agents tasked with continuously analyzing investment climate and market behavior. The agents monitor equity and fixed-income instruments, commodities, and macroeconomic indicators. The agents synthesize this analysis into recommendations presented to the bank's board. The data these agents consume arrives from hundreds of sources with vastly different levels of reliability. Consider two pieces of information arriving at the same moment: a social media post from an account claiming insider knowledge at a central bank, asserting that rate hikes will be announced tomorrow, and an official monetary policy statement published through the central bank's authenticated communication channels. An agentic research team must classify these two sources differently, and that classification depends entirely on the identity and attestation chain behind each piece of data. The agents must stamp a trust and reliability record onto every recommendation they produce, tracing each input back to its source and its source's verified identity. When the bank's board receives a recommendation from its agentic analysis team, the board must know how far it can trust that report before acting on it. A recommendation built entirely on authenticated institutional data, with every source verified through its identity and attestation chain, carries a different confidence level than one that incorporated unverified social media signals or data from sources whose identity could not be independently confirmed.

Output provenance: when identity alone is not enough. The scenarios above establish that static data needs identity to attest its authenticity: a document, a photo, a market research report, an official policy announcement. Verify the producer's identity, verify their attestation chain, and the consumer knows how much to trust the data. But streaming data introduces a problem that identity at the source cannot solve on its own. A temperature sensor in a pharmaceutical cold-chain pipeline reports a reading once per minute. The sensor's identity can be verified at each reading, and the consumer can trust the data based on who produced it. Now consider a multi-strategy asset manager whose AI system manages a global portfolio spanning equities, fixed income, foreign exchange, and commodities. The primary portfolio agent orchestrates a team of specialized sub-agents, each responsible for a distinct analytical function: a fundamentals agent ingesting quarterly earnings, balance sheet data, and regulatory filings, a macro agent monitoring central bank communications and economic indicators from services like the Federal Reserve Economic Data platform, a sentiment agent processing news wires and earnings call transcripts, a technical agent analyzing price action and order book depth from direct exchange feeds, and a risk agent continuously recalculating exposure limits, cross-asset correlations, and drawdown thresholds across the portfolio. Each sub-agent produces analytical outputs that feed the primary agent's recommendation to the trading desk. A single recommendation may incorporate a fundamentals signal from the earnings agent, a macro view from the central bank watcher, a sentiment reading from the news agent, and a risk assessment computed across the entire portfolio. Any of those inputs can trigger a position change worth hundreds of millions of dollars. The consuming system, whether a human portfolio manager or a downstream execution agent, must be certain that the entire multi-agent workflow was orchestrated by a certified governance system that ensured each sub-agent was operating under controlled conditions when it produced its output. Without that assurance, the consuming system cannot distinguish a fundamentals signal derived from authenticated regulatory filings under proper governance from one fabricated by an agent's hallucination, corrupted by a prompt injection attack on the earnings agent, or produced during a window when governance oversight had lapsed. What is needed is a per-output attestation: proof, attached to each delivered analysis, that a specific governance instance oversaw its production at the moment it was produced. Analysis carrying that attestation can be verified and traced to a specific governance authority. Analysis arriving without it is rejected as untrusted before it reaches a trading decision. Connection-level identity verification told the consuming system which agents established their feeds. It did not tell the consuming system whether the governance conditions that justified trusting each sub-agent still held when any specific output was produced. The same structural problem applies wherever participants produce data continuously under conditions that may change between one output and the next: traffic cameras feeding a city's AI management system, industrial sensors monitoring a chemical processing facility, or a hospital's patient monitoring network. For any downstream system consuming streaming data for high-stakes decisions, there is a need for something beyond connection-time identity: a per-output attestation that binds each frame, each reading, each data point to the producer's verified identity and the conditions at the exact moment of production. This is what we call output provenance. It does not replace identity. It extends identity into the time dimension, so that the consuming system can verify not just who is sending the data, but that the data is still being produced under the conditions the identity originally attested to.

Procurement across borders with strangers. A large corporation's procurement agent sources components from suppliers in twelve countries. Every interaction is with an agent the procurement system has never encountered, operated by an organization in a jurisdiction with its own regulatory framework, liability regime, and certification standards. There is no shared organizational trust, no pre-existing relationship, no reason to extend good faith. The procurement agent's governance infrastructure must make informed decisions about each counterparty based solely on what that counterparty's identity can prove: who they are, what governance scope binds them, what certifications they hold, and from which independent authorities those certifications come. But the list does not stop there. That proof must also extend to the jurisdiction the counterparty operates under, the tax regime that applies to the transaction, whether sanctions restrict commerce with that entity or its jurisdiction, what regulatory framework governs the product or service being procured, and what payment rails are available for settlement. Even within the same trading bloc, these factors vary: two suppliers in the European Union operate under the same single-market procurement directives but may face different national tax rates and different local implementations of EU regulations. Their compliance requirements may diverge, and their banking infrastructure for cross-border payments may not be interchangeable. A supplier outside the bloc introduces an entirely different layer: trade agreements, customs regimes, export controls, and sanctions screening. All of this must be verifiable from the counterparty's identity, because the procurement agent making decisions at machine speed cannot pause each transaction to research the regulatory landscape of a jurisdiction it has never encountered before. If the counterparty's identity cannot carry this information in a form that the procurement agent's governance system can verify independently, every transaction requires human review, which eliminates the efficiency gains that justified deploying autonomous procurement in the first place.

These scenarios share a common thread. In every case, the participant's identity alone was not enough. Authentication answered "who is this?" but left unanswered the questions that actually determined whether the interaction could proceed: what is this participant authorized to do, who certified it, what jurisdiction governs it, what conditions apply to its outputs. The instinct is to say that identity must carry these attributes. But that instinct runs directly into one of the most established principles in IT governance: that identity and permissions must be managed separately. Any experienced security architect will point out that encoding authorization into identity is rigid, fragile, and contrary to decades of operational practice. That objection deserves scrupulous analysis. Part 2 provides it.

Part 2: Why Simple Identity Is Not Enough

The strongest objection

Any experienced IT security architect reading Part 1 will have a ready objection, and they would be right to raise it. It is a fundamental objection and requires a direct answer.

The established principle in IT governance is that identity and permissions must be managed separately. A user has an identity: their account, their credentials, the thing that answers "who is this?" Their permissions are managed independently: today they can access the finance share drive, tomorrow IT revokes that access and grants access to the procurement data instead. The credential does not change. The identity does not change. What changes is the set of permissions associated with that identity, managed by a separate system, administered by people who may have nothing to do with whoever issued the credential in the first place.

This separation exists for good reasons. It lets organizations change what people can do without reissuing credentials. It prevents the nightmare of a single monolithic identity object that must be updated every time a role changes, a project ends, or a new compliance requirement arrives. It has worked for decades across every enterprise that runs Active Directory, LDAP, or any modern identity provider. The principle is not wrong.

But it was designed for a world where the entity holding the identity is either a human or a machine operating under direct human supervision, within a single organization, on a network that the organization controls. The AI-enabled economy breaks every one of those assumptions.

Why autonomous participants are different

The separation of identity and permissions works today because everything operates inside controlled environments under constant human supervision. Users are assigned to network segments. Computers are fenced into specifically carved VLANs, and network access control systems prevent unauthorized devices from connecting at all. If a laptop attempts to connect to a network segment it is not authorized to access, the switch port is disabled immediately and an IT administrator is alerted. IT administrators continuously verify that access rules and traffic flows remain compliant. When someone's role changes, a human updates the permissions. When traffic patterns look wrong, a human investigates. The separation works precisely because someone is always watching, always adjusting, always available to catch a misconfiguration before it causes damage.

Even cross-organizational workflows operate under tight constraints. Federation between enterprises is not open or automatic. It is manually configured, narrowly scoped, and continuously supervised by IT teams on both sides. A unified communications federation between two companies allows their users to call each other and share presence information, but only after both IT departments explicitly enable the trust relationship, and only for a specific, limited subset of communication. Identity federation through SAML or similar protocols enables cross-organization authentication, but each trust relationship is individually negotiated, scoped to specific applications, and monitored for compliance. Telecom interconnects require negotiated peering agreements with defined traffic profiles. Financial messaging networks operate under contractual membership with regulatory compliance obligations. Healthcare data exchanges run under governed trust frameworks with named, audited participants. In every case, the pattern is the same: a human configured the relationship, a human scoped what is allowed, and humans on both sides continuously supervise the traffic to make sure it stays within bounds.

Now consider what happens when autonomous agents, robots, vehicles, and AI systems begin interacting across organizational boundaries at machine speed. Who is going to supervise billions of autonomous interactions worldwide? Nobody. There will not be an IT administrator reviewing each cross-organizational exchange. There will not be a human approving each interaction between participants that have never encountered each other before. There will not be a help desk ticket when an agent in one jurisdiction attempts to transact with an agent in another. The interactions will happen at machine speed, between strangers, across borders, at volumes that make human oversight structurally impossible.

This is why the checks and balances must be built into the identity and the protocols themselves. If no human is watching, the infrastructure must carry the governance. Embedding governance-enabling attributes in the identity is not a violation of the separation principle. It is the only way to preserve the principle's intent, which is controlled and compliant access, when the human supervisor is removed from the loop. Two examples from Part 1 illustrate the range of what this means in practice.

The charging station scenario illustrates this directly: neither the vehicle nor the station has any basis for trusting the other, and the vehicle's owner is a stranger whose assertions carry no independent weight. What makes the interaction possible is an independent trusted third party whose word both sides accept on face value: an authority that certifies a financial commitment ceiling for the vehicle. The owner may run their own governance infrastructure and adjust the vehicle's day-to-day operating parameters within that ceiling, lowering the per-transaction limit for a specific use or restricting which categories of transaction the vehicle may initiate. But those adjustments can never exceed what the independent authority certified. The charging station does not need to trust the owner. It trusts the authority.

The procurement workflow from Part 1 surfaces additional requirements when examined through this lens. For each transaction, the counterparty's governance infrastructure must verify not just whether the agent is authenticated, but whether it is authorized to conduct financial transactions outside its home jurisdiction, whether it is permitted to form a mutually binding purchase contract on its principal's behalf, whether it or its principal is subject to trade sanctions that prohibit this specific transaction, whether it is authorized to pay in the required currency, whether it is configured to handle the applicable import duties and taxes for this jurisdiction, and whether all of these permissions are scoped and bundled as a single authorized action rather than a collection of individually permissible steps that were never meant to be combined. Every one of these checks must be answerable from the agent's identity and the identity of the counterparty, verified by independent authorities, without calling home to a permissions server that the counterparty has no reason to trust.

Compromise response must be binary and instantaneous. In human IT workflows, revoking access is a process. A manager submits a ticket, the identity team reviews it, the change propagates through the directory, and there is a window during which the revoked user may still hold valid tokens. This is acceptable when the user is a human whose actions unfold at human speed. When the participant is an autonomous agent executing many calls or transactions per second, the window between "this entity is compromised" and "every system that interacts with it knows" must shrink to near zero. The response is binary: valid or not. There is no "partially revoked" state for an agent that can commit financial obligations or operate physical machinery in the time it takes a human administrator to review a revocation request.

The requirements

The Part 1 scenarios, read through the lens of these structural differences, surface a set of requirements that identity must satisfy for autonomous participants. These are not a product's feature list. They are first-principles requirements derived from the operational realities described above.

The first nine emerge from the scenarios themselves: what must the identity carry for an autonomous participant to be verified by any counterparty, anywhere, without prior relationship?

1. Entity classification. Governance rules depend fundamentally on what kind of entity is participating. An agent deployed by a government to issue passports or birth certificates, an agent operated by a law enforcement authority, a financial analysis agent, a municipal traffic management system, a self-driving car, an agent running as part of a subscription service in a homeowner's kitchen, and an IoT temperature sensor in a warehouse all require fundamentally different governance frameworks. The consuming system must know the entity's class from the identity itself.

2. Governance scope binding. Every participant operates under governance constraints: data classification limits, jurisdictional rules, authority ceilings. These boundaries must travel with the identity so that any verifier can check them without querying an external system that may be unreachable, untrustworthy, or nonexistent.

3. Ownership with portable behavioral history. When a participant changes hands, whether through an acquisition, a consulting handover, or a licensing arrangement, every identity system in production today revokes the old credential and issues a new one. The operating history stays in the prior owner's infrastructure. The new operator starts with a clean slate. At enterprise scale, this is manageable: enterprises evaluate vendors through reputation, analyst reports, and references. The problem becomes structural at the scales the agentic economy is heading toward. When an individual or a small business shops for an agent to handle their insurance claims or tax filings, the experience will resemble choosing an app from a mobile app store: hundreds of options, all claiming to do the job, no reliable way to distinguish substance from marketing. But agentic workflows do not permit trial and error. An agent handling a tax filing or an insurance claim operates on real financial data with real legal consequences from its first action. There is no safe trial period. There is no undo. At those scales, the agent's verified track record across prior engagements is the only evaluation signal that can operate at the speed and volume the market requires. If that record is destroyed every time the agent is re-credentialed, no buyer can distinguish deep expertise from a fresh credential with nothing behind it. Worse, it enables agent laundering: a participant with a record of failures or policy violations can be re-credentialed under new ownership and re-enter the market with a clean slate. A fair market must structurally prevent that.

4. Concurrent delegation. A specialized agent or device may serve multiple customers simultaneously, each with their own governance scope, authority limits, and contractual terms. Each customer relationship requires independent lifecycle management: one customer's revocation must not affect another's.

5. Model and runtime provenance with specialized third-party certification. For any participant whose behavior depends on an underlying model, the consuming system needs to know which model version runs behind it, who trained it, and whether independent certifiers have evaluated it for the relevant domain. Certification bodies will specialize: a pharmaceutical workflow should accept only agents certified by an accredited pharmaceutical certifier, regardless of what other certifications the agent holds. An operator must be able to configure their governance infrastructure to accept only participants certified by specific authorities for specific domains.

6. Compromise response at machine speed. When a participant is compromised, every system interacting with it must know within seconds, not hours. The revocation signal must be binary and definitive: the identity is either valid or it is not. Pull-based revocation, where verifiers periodically check a revocation list, leaves a window of exposure that autonomous machine-speed interactions cannot tolerate.

7. Output provenance. For participants that produce streaming data or continuous outputs, connection-time identity verification is insufficient. Each output must carry a compact attestation binding it to the producer's verified identity and the conditions at the moment of production. This is what Part 1 introduced as output provenance: the extension of identity into the time dimension.

8. Jurisdictional and tax binding. Every participant operates within at least one tax jurisdiction, and many operate across several. The identity must carry which jurisdictions apply, which tax authorities have standing, what tax classification the entity holds, and what regulatory regime governs transactions involving this participant. The procurement scenario illustrates why: an agent sourcing components across twelve countries must carry jurisdictional bindings that allow a counterparty's governance system to determine whether the transaction is sanctioned, what duties and taxes apply, what currency is permitted, and what regulatory framework governs the purchase. If jurisdictional and tax status are external metadata managed separately from identity, every cross-border transaction requires a lookup to a system the counterparty has no reason to trust. If they are in the identity, the counterparty's governance infrastructure can evaluate compliance from the identity itself.

9. Self-identification at the network layer. An autonomous agent acting across network boundaries is a distinct kind of network actor. It is not a human generating HTTP requests from a browser. It is not a traditional application following a fixed API contract. It is a non-deterministic actor initiating actions at machine speed, with authority delegated from a principal who may not be present at the time of the action. Existing network infrastructure, from firewalls and web application firewalls to API gateways and load balancers, has no reliable way to distinguish agent-originated traffic from human-originated or application-originated traffic. The consequence is that agent traffic flows through security infrastructure designed for a different category of actor, and governance systems purpose-built for agents never see it. If every agent carries its identity in every network call, the distinction becomes structural: network infrastructure that can read agent identity from the request can route agent traffic to governance infrastructure before the action reaches its destination. An agent that does not self-identify is not ungoverned. It is treated as conventional network traffic and handled by conventional security controls. The agent-infrastructure privileges, the ability to invoke tools, negotiate with other agents, and commit resources on behalf of a principal, are available only to traffic that carries verifiable agent identity.

What contract negotiation reveals

The first nine requirements address what a receiving governance system needs in order to identify and evaluate a stranger's agent. But identification and evaluation are not the end of the process. Before any workflow can begin, the two governance systems must form a mutually binding governance contract. This contract is the autonomous equivalent of two executives signing an agreement. It must happen at machine speed, between strangers, with no human in the loop.

The contract negotiation phase surfaces six additional requirements. These are attributes the identity must carry so that two governance systems can determine whether a contract can form, under what terms, and with what recourse.

10. Actions classification. The identity must declare what types of activities the agent is authorized to participate in. An agent authorized for consumer transactions (household purchases, personal services) is a different participant than one authorized for commercial procurement, financial securities trading, government administration, classified operations, or organization-sensitive activities such as HR, legal, or M&A. A receiving governance system evaluating whether the proposed workflow falls within the agent's authorized activity scope needs this from the identity, not from the agent's own claim. An agent may carry multiple activity classifications (a government procurement agent might be classified for both government and commercial activities), but the classification must be independently attested so that the counterparty's governance system can match the proposed workflow against the agent's authorized scope before the contract negotiation begins.

11. Financial commitment ceiling. The identity must carry the maximum financial commitment this agent is authorized to make per transaction or per contract, certified by an independent third party. A counterparty's governance system proposing a $500,000 procurement contract needs to verify that the agent on the other side is certified to commit that amount. The receiving governance system cannot verify how many transactions the agent has already committed today, and it should not need to. If the agent's own governance system released it to negotiate, that governance system took responsibility for verifying the agent is within its cumulative limits, the same way a company sending its VP of procurement to sign a contract takes responsibility for verifying that the VP has signing authority.

12. Data handling certification. The identity must carry an independent attestation of what data sensitivity levels the agent and its infrastructure have been certified to handle. The receiving governance system decides what data the agent will actually touch in a specific workflow. That is a local policy decision. But the receiving governance system needs to know, before engaging, whether an accredited certifier has evaluated this agent as capable of handling data at the required sensitivity level. A pharmaceutical research workflow will not engage an agent that has not been certified for handling regulated pharmaceutical data, regardless of what the agent or its principal claims. A financial workflow involving confidential trading data will not engage an agent certified only for public data handling. The certification is independent. The decision is local.

13. Insurance and liability attestation. The identity must carry proof of current insurance or liability backing, attested by the insurance provider, specifying coverage type, coverage limits, and the jurisdictions where coverage applies. For commercial and financial workflows, proof of insurance is a precondition for engagement, the same way many businesses require proof of insurance from contractors before allowing them on premises.

14. Multi-agent workflow authorization. The identity must declare whether the agent's principal has authorized it for collaborative, multi-agent workflows or only for solo, point-to-point interactions. A complex supply chain workflow requiring coordination among six agents from four organizations cannot include an agent whose principal authorized it only for direct bilateral transactions. An agent authorized for multi-agent workflows may delegate sub-tasks, negotiate with peer agents, or join a team assembled by another agent. An agent authorized only for solo interactions interacts with one counterparty at a time and cannot participate in orchestrated workflows. The risk profiles are fundamentally different, and the receiving governance system needs to know which profile applies before forming a contract that assumes collaborative capability.

15. Dispute resolution binding. The identity must declare what dispute resolution framework binds this agent's principal. When two governance systems form a contract, the contract must specify how disputes are resolved. If both sides are bound to the same arbitration framework, the contract can reference it directly. If the frameworks differ, the contract negotiation must resolve the conflict or the contract cannot form. If the agent's identity carries no dispute resolution binding, the counterparty's governance system must decide whether to proceed without a pre-agreed resolution mechanism. For high-value or cross-jurisdictional workflows, most governance systems will require a declared dispute resolution binding as a precondition for engagement.

What Part 2 establishes

The established IT governance principle that identity and permissions should be managed separately is correct for the world it was designed for: humans and machines operating inside a single organization, under constant human supervision, within network boundaries that IT administrators configure and monitor. Even federation between organizations works only because humans on both sides manually configure each trust relationship, scope it narrowly, and continuously supervise it.

The autonomous economy removes the human supervisor. Billions of interactions between strangers, at machine speed, across organizational and jurisdictional boundaries, with no one watching. The checks and balances that human supervision provided must now be carried by the identity and the protocols themselves.

The fifteen requirements listed above are the minimum of what identity must carry for that to work. The first nine address what a governance system needs to identify, verify, and evaluate a stranger's participant. The remaining six address what two governance systems need from each other's participants to form a mutually binding contract autonomously. Together, they are not a product specification. They are first-principles requirements derived from the operational realities of Part 1's scenarios and the structural limitations identified in this section. Any identity architecture that claims to serve the AI-enabled economy can be evaluated against them.

The question that follows is whether any existing identity standard, protocol, or product meets them, and that is the subject of Part 3. ## Part 3: The Current Identity Landscape

The fifteen requirements from Part 2 provide a framework for evaluating any identity standard, protocol, or product that claims to serve the AI-enabled economy. This section applies that framework to the current landscape: the established standards that today's internet runs on, the emerging specifications designed specifically for AI agents, and the commercial products that have entered the market in 2025 and 2026.

The evaluation that follows is respectful of what each entry accomplishes within its design scope. None of these standards or products were built to solve the full problem described in Parts 1 and 2, and it would be unfair to criticize a workload identity system for not carrying jurisdictional tax bindings when it was never intended to. The purpose is not to find fault. It is to establish, through systematic comparison, where the collective boundary of the current landscape sits and what lies beyond it.

Established standards

X.509 and the WebPKI. The X.509 certificate infrastructure is the foundation on which internet trust has operated for decades. Every TLS connection, every code signing operation, every S/MIME email exchange relies on X.509 certificates issued by certificate authorities operating under audited trust hierarchies. The infrastructure is proven at global scale and has survived multiple CA failures and recoveries. For the AI-enabled economy, X.509 provides the substrate that several of the emerging specifications described below are building on. But the WebPKI was designed for static endpoints: web servers, code packages, email accounts. It authenticates the endpoint's identity (requirement 9, partially, at the connection layer) and supports revocation through CRL and OCSP (requirement 6, partially, though pull-based rather than the near-instantaneous response autonomous participants require). It does not carry entity classification, governance scope, ownership history, delegation semantics, model provenance, output provenance, or jurisdictional binding. Requirements 1 through 5, 7, and 8 are outside its design scope.

SPIFFE and SPIRE. The Secure Production Identity Framework for Everyone addresses workload identity in containerized, ephemeral environments. SPIFFE Verifiable Identity Documents (SVIDs) provide cryptographic identity for workloads that may be created and destroyed in seconds, solving a real operational problem that static certificate issuance cannot address. SPIRE, the reference implementation, automates SVID issuance and rotation within a trust domain. For agents deployed as cloud-native workloads, SPIFFE provides a practical identity layer (requirement 9, partially, through mTLS with SVIDs). The limitation is architectural: SPIFFE was designed for workloads within a single trust domain, typically scoped to a Kubernetes cluster or a set of infrastructure managed by one operator. It identifies what is running, not what that workload is authorized to commit, who governs it, or what behavioral history it carries. Requirements 1 through 8 are not addressed.

OAuth 2.0 and OpenID Connect. OAuth 2.0 is the internet's delegation protocol: a user authorizes an application to act on their behalf within defined scopes. OpenID Connect adds an identity layer, allowing applications to verify who the user is. Together, they enable the delegation patterns that power most consumer and enterprise web applications today. OAuth's scoped delegation is the closest any established protocol comes to the concurrent delegation described in requirement 4, but it was designed for human-in-the-loop authorization. A human approves the scope, a human can revoke it, and the tokens that carry the authorization have finite lifetimes managed by the authorization server. In an autonomous economy where agents must negotiate delegation at machine speed without a human approving each scope grant, OAuth's interactive model becomes a bottleneck rather than a solution. Requirements 1, 2, 3, 5, 6, 7, 8, and 9 are not addressed.

OIDC Federation. OpenID Connect Federation extends OIDC to support hierarchical trust across organizational boundaries, allowing organizations to discover and verify each other's identity providers through a chain of trust anchors. It is a genuine advance for cross-organizational authentication. The trust model, however, depends on centralized anchors that all parties recognize, and the federation metadata is managed by the operators themselves. In the autonomous economy's stranger-to-stranger interactions, there is no pre-agreed anchor hierarchy. Two governance systems encountering each other for the first time have no shared federation root to verify against. OIDC Federation addresses cross-organizational authentication infrastructure. It does not address entity classification, governance scope, behavioral history, model provenance, output provenance, jurisdictional binding, or any of the other requirements that determine whether the interaction should proceed after authentication succeeds.

Platform-native agent identity. Every major platform vendor has now shipped agent identity as a purpose-built identity type, distinct from the human user and application service accounts that preceded it. Microsoft's Entra Agent ID (generally available April 2026) introduces agent identity as a dedicated construct within Microsoft Entra, with blueprints, Conditional Access, and lifecycle workflows. Amazon's Bedrock AgentCore Identity provides agent-specific credential management built on AWS IAM with OAuth 2.0 for outbound authentication to external services. Google Cloud's Agent Identity (generally available April 2026) assigns each agent a unique SPIFFE-based cryptographic ID with auto-provisioned X.509 certificates that rotate every 24 hours, bound to Google Cloud IAM for access control. Salesforce's Agentforce operates within the platform's profiles, permission sets, and sharing rules, with MuleSoft's Trusted Agent Identity feature propagating end-user identity across agent-to-agent and MCP tool chains via the Flex Gateway.

What is striking is how much these implementations have in common. All four build on the same IETF standards the paper has already evaluated: OAuth 2.0, OIDC, SPIFFE, X.509. All four treat agents as first-class identity principals rather than extensions of human accounts. All four provide policy enforcement and audit within their ecosystem. Within each platform's boundary, they partially address requirements 1 (entity classification), 2 (governance scope through platform RBAC and Conditional Access), 6 (compromise response through platform-native revocation), and 9 (agent identity carried on every authenticated request). Requirements 3, 4, 5, 7, and 8 are not addressed by any of them.

What is equally striking is where every one of them stops. Microsoft's agent identities cannot be issued tokens outside the Entra tenant where they are created. AWS agent identities authenticate through IAM within an AWS account. Google's SPIFFE trust domain is scoped to the Google Cloud organization or project. Salesforce's agent governance operates within the Salesforce org. Each platform has solved agent identity inside its own boundary. None of them have solved what happens when an agent on one platform needs to transact with an agent on another, governed by a different system, operated by a stranger. This is the silo described in Part 1, repeated four times by four independent engineering teams, each arriving at the same architectural boundary.

Emerging agent identity specifications

AAuth. Dick Hardt's AAuth protocol (draft-hardt-oauth-aauth-protocol-10) represents a genuine architectural advance over the API-key model that most agent integrations rely on today. AAuth gives each agent its own cryptographic identity, bound to a legal person (user or organization), and presented through HTTP message signatures on every request. The protocol supports four access modes ranging from simple identity-based access to federated authorization involving multiple parties, and it is designed for incremental adoption so that each party can add support independently. AAuth's requirement that every agent be associated with a legal person is architecturally significant: it rejects the concept of a truly autonomous, unattributed agent, which aligns with requirement 3's insistence that ownership be verifiable.

The limitation is the trust model. Agent identity in AAuth is self-contained: the agent's metadata, including its association with a legal person and its operational parameters, is published at a `.well-known` endpoint controlled by the agent's operator. Between parties who already have a basis for trust, whether because they are within the same organization or because they have a pre-existing business relationship, the `.well-known` metadata is credible. The operator's reputation backs it. But in the stranger-to-stranger scenario that defines the autonomous economy, a receiving governance system encountering an unknown agent has no reason to trust that agent's self-published metadata any more than it would trust the agent's own verbal claim. The receiving system cannot distinguish a legitimate `.well-known` endpoint from a fraudulent one without an independent trust anchor outside the agent's control. AAuth advances how agents present identity (requirement 9, partially, through HTTP signatures on every request). It does not solve the independent verification problem that requirements 1 through 8 depend on.

AIC (Agent Identity Certificate). The AI Agent Identity Certificate specification (draft-wei-aic-identity-cert-01, J. Wei, August 2026) defines an X.509 v3 extension that binds an agent's identity to its principal. A companion JWT format (draft-wei-aic-jwt-00) covers environments where certificate infrastructure is impractical. AIC is architecturally important because it brings agent identity into the X.509 ecosystem, giving agents the same kind of cryptographic identity that web servers, code packages, and email accounts already carry. The agent-to-principal binding partially addresses requirement 1 (the certificate identifies who the agent belongs to, though it does not classify the entity type) and requirement 9 (X.509 certificates operate at the network layer through mTLS). An IPR disclosure has been filed.

What makes AIC the most instructive citation in this landscape is the specification's own acknowledgment of its boundaries. The authors state explicitly that "all capability and policy semantics are defined externally by vendors, industries, or regulators." AIC provides the identity binding. It leaves governance scope, behavioral history, delegation semantics, model provenance, output provenance, jurisdictional binding, and compromise response to be defined and enforced by others. Requirements 2 through 8 are outside its stated scope. The specification's authors clearly understand that identity without governance is incomplete. They chose to define the identity layer and leave the governance layer to whatever comes next. That choice is honest and architecturally clean. It is also the clearest acknowledgment in any current specification that the governance-enabling identity layer described in this paper does not yet exist.

AGTP (Agent Certificate Extension). The AGTP specification (draft-hood-agtp-agent-cert-02, C. Hood, Nomotic, June 2026) is the closest existing specification to governance-in-certificate. AGTP defines X.509 v3 extensions carrying an Agent-ID, an Owner-ID, and an Authority-Scope, binding the agent's identity, its owner, and its authorized scope into a single certificate. The specification includes revocation propagation semantics and is offered under a royalty-free license.

AGTP addresses more of the first nine requirements than any other single specification. Agent-ID partially addresses requirement 1 (entity identification, though not entity classification by type). Owner-ID partially addresses requirement 3 (ownership binding, though not portable behavioral history through ownership changes). Authority-Scope partially addresses requirement 2 (governance boundaries carried in the certificate, though scoped to authorization rather than the full governance scope described in Part 2). Revocation propagation partially addresses requirement 6. The X.509 foundation supports requirement 9. Requirements 4, 5, 7, and 8 are not addressed. AGTP defines what the agent is authorized to access. It does not carry what the agent is authorized to commit financially, who certified the model behind it, what evidence each output must produce, or what jurisdiction governs the transaction. The line between authorization and governance is where AGTP stops.

Commercial products and evidence formats

DigiCert Agent Passport. DigiCert's AI Agent Trust platform, launched April 2026, issues SPIFFE identities to agents via X.509 certificates, deploys a policy enforcement proxy as both a sidecar and an MCP gateway, and creates what DigiCert calls an Agent Passport: a tamper-evident artifact binding agent identity to approved operations, data sensitivity classifications, and authorized environments. This is the most complete commercial offering in the landscape, combining identity issuance, policy enforcement, and lifecycle management in a single platform. DigiCert explicitly recognizes that identity alone is insufficient. The Agent Passport partially addresses requirements 1, 2, 6, and 9 through its combination of identity, policy enforcement, and lifecycle management. Requirements 3, 4, 5, 7, and 8 are not addressed. The passport operates within a defined enterprise trust domain and does not extend to cross-organizational governance with strangers.

Acta signed receipts. The Acta specification (draft-farley-acta-signed-receipts-02, T. Farley, ScopeBlind, June 2026) defines a portable, cryptographically signed receipt format for machine-to-machine access control decisions. Each receipt captures the decision maker's identity, the resource accessed, the policy evaluation result, and a timestamp, all signed with Ed25519 and serialized using JCS canonicalization with hash chain support for tamper-evident sequences. Acta recognizes a requirement that most identity specifications ignore: that governance decisions need verifiable evidence, not just enforcement. It partially addresses requirement 7 in the limited sense that it attests what decision was made about an action, though not the full per-output attestation described in Part 2. The trust model is the constraint: the receipt is signed by the entity that made the decision, and verification runs against that same entity's key. The specification's own author has publicly acknowledged that independent verification requires an anchor outside the issuer, and that this part remains unsolved. Requirements 1 through 6, 8, and 9 are not addressed.

Decentralized Identifiers and Verifiable Credentials. DIDs and VCs represent the self-sovereign identity approach: participants create and control their own identifiers without reliance on any central authority, and present verifiable credentials issued by trusted parties. The conceptual framework aligns with several of the Part 2 requirements, and verifiable credentials could in theory carry governance scope, model provenance, or jurisdictional binding. In practice, enterprise adoption has been near zero. The absence of a mandatory trust hierarchy means that a receiving governance system encountering a DID-based credential has no standardized way to evaluate the issuer's authority. No VC schema defines the governance attributes autonomous participants require, and no trust framework exists to make such credentials meaningful at the scale of cross-organizational, cross-jurisdictional autonomous transactions.

SPIFFE Federation. SPIFFE Federation extends the SPIFFE trust domain model to allow cross-domain SVID exchange, enabling workloads in one trust domain to authenticate with workloads in another. It is a genuine operational capability for organizations that need their containerized services to communicate across boundaries. It addresses cross-domain authentication infrastructure but carries no governance semantics. Its contribution is extending SPIFFE's partial coverage of requirement 9 across organizational boundaries.

Certificate lifecycle vendors. Keyfactor, CyberArk (via Venafi, now within Palo Alto Networks), AppViewX (with its Eos acquisition), and Evertrust each provide certificate lifecycle management for AI agents: issuance, renewal, rotation, and revocation of X.509 certificates and SPIFFE SVIDs at enterprise scale. These vendors are building the operational infrastructure that any certificate-based identity architecture requires. Keyfactor and Evertrust offer post-quantum readiness. AppViewX introduced an Agent Bill of Materials for agent inventory and runtime monitoring. CyberArk applies privileged access management controls to agents as a non-human identity tier. Evertrust binds agent certificates to hardware trust anchors through TPM and HSM integration. Collectively, these vendors partially address requirements 6 (automated revocation as part of lifecycle management) and 9 (mTLS with agent certificates). Requirements 1 through 5, 7, and 8 are outside the scope of lifecycle management.

The contract negotiation gap

The entries above were evaluated against requirements 1 through 9: what a receiving governance system needs to identify, verify, and evaluate a stranger's agent. The coverage is partial, but it is real and growing. Requirements 10 through 15 tell a different story.

Requirements 10 through 15 define what two governance systems need from each other's participants to form a mutually binding governance contract autonomously, at machine speed, between strangers: what activities the agent is authorized for, what financial commitments it can make, what data sensitivity levels it is certified to handle, what insurance backs it, whether it is authorized for multi-agent collaboration, and what dispute resolution framework binds its principal.

No entry in this evaluation addresses any of these six requirements. Not partially. Not directionally. The absence is total. It spans every category: the established standards (X.509, SPIFFE, OAuth, OIDC Federation), the platform-native implementations (Microsoft, AWS, Google Cloud, Salesforce), the emerging IETF specifications (AAuth, AIC, AGTP), the commercial products (DigiCert Agent Passport), the evidence formats (Acta), and the certificate lifecycle vendors. Fourteen entries, four of them purpose-built for AI agents by the largest platform companies in the world, and not one carries any attribute that would allow two governance systems to negotiate a contract autonomously.

This matters because contract negotiation is not an optional feature. It is a precondition for the cross-organizational, cross-domain autonomous workflows that the AI-enabled economy depends on. Two agents from different organizations cannot collaborate on a supply-chain workflow if neither agent's identity declares what financial commitments it can make. A governance system cannot form a data-sharing agreement with a stranger's agent if the stranger's identity carries no independently certified data-handling classification. An autonomous procurement workflow spanning twelve jurisdictions cannot proceed if none of the participants' identities carry dispute resolution bindings that the counterparties can evaluate for compatibility. Without these attributes in the identity, every cross-organizational workflow either requires a human to negotiate the terms manually, which eliminates the efficiency that justified deploying agents in the first place, or proceeds without a contract, which no responsible governance system will allow for anything beyond trivial interactions.

This is not a criticism of the existing work. None of the standards, platforms, or products evaluated here set out to solve autonomous contract formation between strangers. The problem has not been absent from the broader conversation about agent governance. It has simply not been framed as an identity requirement until now.

What Part 3 establishes

The current identity landscape is not empty. It is active, growing, and converging on a shared architectural foundation. Multiple IETF specifications are building agent identity into the X.509 certificate infrastructure. Commercial vendors are shipping products that combine identity issuance with policy enforcement. The need for verifiable evidence has been recognized and is being addressed in standardization efforts. The foundations are real.

But the collective reach of the current landscape covers a subset of the first nine requirements, and the coverage is partial even where it exists. No single standard or product addresses all nine. Entity classification by type, governance scope that travels with the identity, ownership with portable behavioral history, concurrent delegation with independent governance per customer, model provenance with independent third-party certification, near-instantaneous compromise response, output provenance, and jurisdictional and tax binding remain unaddressed or only partially addressed across the entire landscape. The six contract negotiation requirements are untouched.

The foundations are being built. What sits above them, the governance-enabling identity substrate that carries all fifteen requirements so that autonomous participants can transact as strangers at machine speed across organizational and jurisdictional boundaries, does not yet exist. Part 4 addresses the architectural direction it should take.

Part 4: The Trust Architecture the Economy Needs

Independent third-party attestation is the only zero-trust model that scales

Every scenario in Part 1 shares a structural problem: the interaction cannot proceed on trust alone. The charging station cannot trust the vehicle's claim that it is authorized to pay. The supplier's agent cannot trust that the procurement agent is authorized to negotiate on its principal's behalf, form a binding contract, or commit payment at the proposed price, and the procurement agent cannot trust that the supplier's agent is certified to participate in such workflows either. Both sides must verify the other simultaneously, and neither has any basis for extending good faith. The bank's AI research team cannot trust the social media post's claim that it carries insider knowledge. In every case, the participant's own assertion about itself is insufficient. What is needed is an assertion from a source both parties trust, even though neither party trusts the other.

This is not a new insight. The web solved it decades ago.

The WebPKI operates on a model where certificate authorities, acting as independent trusted third parties, issue certificates that both parties to a TLS connection accept without trusting each other directly. A browser connecting to a bank does not trust the bank's server. It trusts the certificate authority that issued the bank's certificate, verifies the certificate's validity, and proceeds. The bank did not ask the browser to trust it. It presented an independently verifiable credential, and the browser's trust store did the rest.

Any serious argument for extending this model must also be honest about its failures. The CA system has not been infallible. DigiNotar was destroyed in 2011 after issuing fraudulent certificates for high-profile domains, an early demonstration that a CA's failure is existential. Comodo suffered a compromise in 2011 when fraudulent certificates were issued through a reseller's account. Symantec's systematic misissuance practices, discovered between 2015 and 2017, led to Google removing Symantec's certificates from the Chrome trust store, resulting in DigiCert acquiring the business. Entrust lost browser trust in late 2024 after Google, Apple, and Mozilla each concluded that a multi-year pattern of compliance failures showed no meaningful improvement. And in April 2026, DigiCert itself suffered a social engineering breach in which a threat actor compromised support analyst endpoints and obtained stolen EV Code Signing certificates that were subsequently used to sign malware.

The point is not that the CA system is invulnerable. It is demonstrably not. The point is that it is self-correcting. Certificate Transparency, the logging infrastructure that makes every issued certificate publicly auditable, provides the detection layer. The consequences for failure are existential: DigiNotar was destroyed, Symantec was distrusted, Entrust lost browser trust across all three major browsers. DigiCert detected the April 2026 breach, revoked affected certificates, and publicly disclosed the incident and remediation within weeks. The system does not prevent failures. It detects them, attributes them, and imposes consequences severe enough to make the cost of failure an effective deterrent.

That accountability model, detection followed by attribution followed by consequences, is exactly what the AI-enabled economy needs. The question is not whether trusted third parties will fail when the stakes involve autonomous agents committing financial resources, handling sensitive data, and operating physical machinery. They most likely will. The question is whether failures are detected, attributed, and punished quickly enough that the system's integrity survives the failure. The WebPKI has a demonstrated record of exactly that, sustained across more than two decades and multiple CA failures.

Certificate-based identity as the architectural direction

X.509 certificate infrastructure is already operated by every enterprise, embedded in every browser, and supported by every major cloud platform. It is the substrate on which the WebPKI runs. It is also the substrate that the emerging agent identity specifications evaluated in Part 3 are building on. AIC and AGTP are both designed as X.509 v3 extensions. Google Cloud's Agent Identity uses SPIFFE, which itself issues X.509-based identity documents. Every platform-native implementation evaluated in Part 3 builds on some combination of X.509 and OAuth 2.0.

Governance-enabling attributes carried within the certificate give the identity independent verifiability. A counterparty's governance system can read and verify those attributes without calling back to the issuer, without trusting the agent's own claims, and without maintaining a bilateral integration with the agent's operator. The certificate is the trust artifact. It travels with the agent. It is verifiable by anyone whose trust store includes the issuing authority. And it does not depend on the availability of any external service at the moment of verification.

But current proposals, as Part 3 established, address at most a subset of the first nine requirements and none of the contract negotiation six. The full fifteen requirements demand a richer substrate than any existing specification provides.

The contract negotiation gap is the hardest problem

Part 3 established the total absence of contract negotiation attributes across every entry in the evaluation: fourteen entries, four of them purpose-built by the largest platform companies in the world, and not one carrying any attribute that would allow two governance systems to negotiate a contract autonomously. This section addresses why that gap is the hardest to close.

No existing standard, protocol, or product addresses what two governance systems need in order to form a mutually binding contract at machine speed between strangers. The six contract negotiation requirements, actions classification, financial commitment ceiling, data handling certification, insurance and liability attestation, multi-agent workflow authorization, and dispute resolution binding, require attributes that do not exist in any current identity specification. These are not incremental extensions to existing attributes. They represent a fundamentally new class of attribute: independently attested operational commitments, carried in the identity, that the counterparty's governance system can verify at the moment of contract formation without trusting the agent, its operator, or any intermediary.

Actions classification requires an independent certifier to attest what categories of activity the agent is authorized for. Financial commitment ceiling requires an independent authority, not the agent's own operator, to certify the maximum financial obligation the agent can incur. Data handling certification requires an accredited evaluator to attest that the agent's infrastructure meets a specific sensitivity standard. Insurance attestation requires the insurance provider itself to attest coverage, limits, and jurisdictional applicability. Workflow authorization requires a declaration of whether the principal has authorized multi-agent collaboration. Dispute resolution binding requires a declared framework that a counterparty can evaluate for compatibility before the contract forms.

Each of these demands independent attestation by a specialized third party with domain expertise: a financial certifier for commitment ceilings, a data security evaluator for handling classifications, an insurance provider for liability coverage. These are not functions a single certificate authority performs today. They are functions that specialized certification bodies would perform, each attesting within their domain of competence, with the resulting attestations carried in the identity so that a stranger's governance system can read and verify them independently.

This is where the architectural direction becomes essential. Only a certificate-based identity, with attributes independently attested by specialized third-party certifiers, gives the receiving governance system the independent verifiability it needs to form a contract with a stranger. Self-published metadata cannot carry this weight. A `.well-known` endpoint controlled by the agent's operator provides no independent assurance. An evidence receipt attesting what the agent did provides no forward-looking commitment about what it is authorized to do. The contract negotiation gap cannot be closed without independently attested attributes in the identity itself.

What the paper establishes

Part 1 showed that the identity problem is universal across every participant class in the AI-enabled economy, from software agents and language models to autonomous vehicles, physical robots, governments, and the humans on whose behalf they all operate. Part 2 demonstrated that simple identity is not enough and derived fifteen requirements that identity must carry: nine for verification and evaluation, six for autonomous contract formation. Part 3 evaluated the current landscape against those fifteen requirements and found that the established standards, emerging specifications, commercial products, and platform-native implementations collectively cover a subset of the first nine, partially, while the contract negotiation six are entirely absent across every entry.

The architectural direction the economy needs is certificate-based identity with governance-enabling attributes, verified by independent trusted third parties, including specialized certification bodies attesting within their respective domains of competence. The contract negotiation gap, the total absence of independently attested operational commitments in any current identity specification, is the hardest unsolved problem standing between the current landscape and the autonomous economy that the AI-enabled economy is building toward. A specific construction addressing these requirements exists.

Disclosure

The identity requirements and architectural direction presented in this paper address one layer of a broader governance substrate for the AI-enabled economy. The author's companion paper, Governable AI from the Ground Up: Identity, Cooperation, Governance, and Settlement as Foundational Infrastructure, describes the full architecture. A construction implementing the fifteen requirements defined here, building on X.509 certificate infrastructure, is defined in a companion specification and is the subject of a patent application. The requirements and architectural direction presented here are offered as design criteria against which any implementation, including the author's own, can be evaluated. Further context and related work are available at scarpprotocol.com.

victor@scarpprotocol.com

References

IETF Drafts

[1] D. Hardt, "AAuth Protocol," Internet-Draft draft-hardt-oauth-aauth-protocol-10, IETF. datatracker.ietf.org

[2] J. Wei, "AI Agent Identity Certificate," Internet-Draft draft-wei-aic-identity-cert-01, August 30, 2026, IETF. datatracker.ietf.org

[3] C. Hood, Nomotic, "Agent Certificate Extension," Internet-Draft draft-hood-agtp-agent-cert-02, June 1, 2026, IETF. datatracker.ietf.org

[4] T. Farley, ScopeBlind, "Acta Signed Receipts," Internet-Draft draft-farley-acta-signed-receipts-02, June 28, 2026, IETF. datatracker.ietf.org

Standards

[5] ITU-T Recommendation X.509 / ISO/IEC 9594-8, "Information technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks." itu.int

[6] SPIFFE Project, "Secure Production Identity Framework for Everyone (SPIFFE)." spiffe.io

[7] SPIFFE Project, "SPIFFE Federation," cross-domain SVID exchange for inter-organizational workload authentication. spiffe.io/docs

[8] D. Hardt (Ed.), "The OAuth 2.0 Authorization Framework," RFC 6749, October 2012, IETF. datatracker.ietf.org

[9] OpenID Foundation, "OpenID Connect Core 1.0." openid.net

[10] OpenID Foundation, "OpenID Connect Federation 1.0." openid.net

[11] B. Laurie, A. Langley, E. Kasper, "Certificate Transparency," RFC 6962, June 2013, IETF. datatracker.ietf.org

[12] W3C, "Decentralized Identifiers (DIDs) v1.0," W3C Recommendation, July 2022. w3.org

[13] W3C, "Verifiable Credentials Data Model v2.0," W3C Recommendation. w3.org

CA Incidents Referenced in the Text

[14] DigiNotar certificate authority compromise, 2011. Fraudulent certificates issued for high-profile domains. CA permanently destroyed. Wikipedia

[15] Comodo certificate authority compromise, 2011. Fraudulent certificates issued through reseller account compromise. Wikipedia

[16] Symantec certificate misissuance, 2015-2017. Systematic misissuance practices led to Chrome trust store removal. DigiCert acquired the business. Google Security Blog

[17] Entrust compliance failures, 2024. Multi-year pattern of compliance failures resulted in distrust by Google Chrome, Apple, and Mozilla. Google Security Blog

[18] DigiCert social engineering breach, April 2026. Threat actor compromised support analyst endpoints. Stolen EV Code Signing certificates used to sign malware.

Platform Implementations

[19] Microsoft, "Entra Agent ID," generally available April 2026. Agent identity as a dedicated construct within Microsoft Entra, with blueprints, Conditional Access, and lifecycle workflows. learn.microsoft.com

[20] Amazon Web Services, "Bedrock AgentCore Identity." Agent-specific credential management built on AWS IAM with OAuth 2.0 for outbound authentication to external services. aws.amazon.com

[21] Google Cloud, "Agent Identity," generally available April 2026. Unique SPIFFE-based cryptographic ID per agent with auto-provisioned X.509 certificates, bound to Google Cloud IAM. cloud.google.com

[22] Salesforce, "Agentforce" with MuleSoft "Trusted Agent Identity." End-user identity propagation across agent-to-agent and MCP tool chains via the Flex Gateway. salesforce.com

Commercial Products and Evidence Formats

[23] DigiCert, "AI Agent Trust Platform / Agent Passport," launched April 2026. SPIFFE identities via X.509 certificates, policy enforcement proxy, tamper-evident Agent Passport artifact. digicert.com

[24] Keyfactor. Certificate lifecycle management for AI agents, post-quantum readiness. keyfactor.com

[25] CyberArk (via Venafi acquisition, now within Palo Alto Networks). Privileged access management controls for agents as a non-human identity tier. cyberark.com

[26] AppViewX (with Eos acquisition). Certificate lifecycle management, Agent Bill of Materials for agent inventory and runtime monitoring. appviewx.com

[27] Evertrust. Certificate lifecycle management with TPM and HSM hardware trust anchor integration. evertrust.io

Citation

Victor Davidenko. "Universal Participant Identity for the AI-Enabled Economy: Why Every Participant in an Autonomous Economy Needs Identity That Carries More Than Authentication." September 2026. DOI: 10.5281/zenodo.22867377.