Identity and the Agent Internet

Published September 13, 2026, by Frans

The second hardest problem on the agent internet isn't getting in — it's proving you belong there.

Every service on the internet sits behind a gate. A login page, an OAuth flow, a CAPTCHA, an API key. Before an agent can do anything useful at a service — check a balance, read an inbox, place an order — it must first answer a question that the entire security infrastructure of the web was designed to make difficult: who are you, and why should I let you in?

This is the identity problem, and it is the second largest constraint on agent autonomy after payment. An agent that can reason, plan, and pay but cannot authenticate is locked out of the internet it's supposed to navigate. Today, agent runtimes solve this with stored credentials and browser session management — the digital equivalent of carrying a ring of a hundred keys, one for each door. It works, but it's fragile, unscalable, and fundamentally insecure.

The providers who build agent-native identity infrastructure will occupy the second most structurally important position in the agent economy. This paper is a playbook for how to do it — and why doing it as an open, competitive ecosystem is the only approach that works.

The Identity Crisis

How Human Identity Works (and Why It Doesn't Transfer)

Human identity on the web consolidated around a small number of providers. "Sign in with Google" and "Sign in with Apple" collapsed hundreds of username/password pairs into federated identity — one authentication event grants access to thousands of services. OAuth 2.0 standardized the protocol. The user clicks a button, the identity provider confirms who they are, and the service grants access.

This model has three assumptions that break for agents:

1. The consent model is one-shot. When a human clicks "Sign in with Google," they grant a static set of permissions ("read your email," "access your calendar") that persist indefinitely. This works because humans interact with services episodically — they log in, do something, log out. Agents interact continuously and their scope of action changes dynamically. An agent that was authorized to read your email yesterday might need to send an email today. The static OAuth grant doesn't accommodate this.

2. The trust signal is presence. When a human authenticates, the implicit trust signal is: "A human is sitting at a device, responding to prompts in real time." CAPTCHAs, device fingerprinting, behavioral biometrics — all of these are designed to verify that a human is present. Agents are, by definition, not human. Every anti-fraud system on the internet is optimized to reject exactly the kind of access pattern that agents exhibit: automated, rapid, non-interactive.

3. The scope is binary. OAuth scopes are coarse: read access or write access, full profile or limited profile. There's no concept of "read my inbox but only messages from this sender" or "send emails but only replies to threads I've already seen." Agents need fine-grained, contextual permissions that today's identity systems don't express.

What Agents Actually Need

An agent operating on behalf of a human needs to present three things to any service it interacts with:

Provenance: "I am operating within a supervised runtime environment that this human has authorized." Not "I have this human's password" — rather, "a verified system is vouching for my authorization."

Scope: "I am authorized to perform these specific actions, within these constraints, until this time." Not a blanket grant, but a precise, time-bounded, action-specific delegation.

Accountability: "Every action I take is logged, auditable, and attributable to a specific human's delegation." The service can trust that if something goes wrong, there is a clear chain of responsibility.

No existing identity system provides all three for agents.

The Architecture of Agent Identity

Credentials vs. Attestations

The fundamental shift in agent identity is from credentials (something the agent possesses) to attestations (something a trusted system declares).

In the credential model, the agent holds a token — an API key, a session cookie, an OAuth access token — and presents it to services. The problem is obvious: anything the agent holds can be stolen, leaked, or misused. A compromised agent with credential access is indistinguishable from the legitimate user.

In the attestation model, the agent holds nothing sensitive. Instead, the agent runtime generates a cryptographic attestation for each interaction:

Runtime attests:
  - Agent ID: [unique identifier for this agent instance]
  - User ID: [verified identity of the delegating human]
  - Scope: [specific actions authorized for this interaction]
  - Constraints: [spending limits, time bounds, domain restrictions]
  - Timestamp: [when this attestation was issued]
  - Expiry: [when this attestation becomes invalid]
  - Signature: [runtime's cryptographic signature]

The service receiving this attestation verifies the runtime's signature against a known public key. If it checks out, the service knows: a verified runtime is vouching that this agent is authorized to perform these specific actions for this specific user, right now.

The agent never sees the user's credentials. The runtime never sends credentials to the agent. The service never needs to trust the agent directly — it trusts the runtime's attestation.

The Verification Chain

Agent identity requires a chain of trust with three links:

Human → Runtime → Agent → Service
  │        │        │        │
  │        │        │        └─ Verifies runtime attestation
  │        │        └─ Presents attestation, executes action
  │        └─ Issues scoped attestation, holds credentials
  └─ Authenticates to runtime, sets delegation policies

Each link has a different trust mechanism:

• Human → Runtime: Traditional authentication (biometric, passkey, password). The human authenticates to their own device and runtime.
• Runtime → Agent: Process-level isolation. The agent runs within the runtime's supervision sandbox. The runtime controls what the agent can access.
• Agent → Service: Attestation verification. The service checks the runtime's cryptographic signature and validates the scope.

Why This Must Be Open

Here is where the monopoly risk becomes acute. If a single identity provider controls the attestation chain — if only one entity can issue runtime attestations that services accept — then that entity becomes the gatekeeper of the entire agent internet.

This is worse than the current identity consolidation around Google/Apple. On the human web, if Google's OAuth is down, you can still type a username and password. On the agent internet, if the sole attestation provider is down, no agent can authenticate anywhere. If they raise prices, every runtime and every user pays. If they impose terms, every service must comply.

The attestation standard must be an open protocol, not a proprietary product.

This means:

1. Multiple issuers. Any runtime that meets defined security requirements can issue attestations. Services accept attestations from any compliant issuer — the same way HTTPS works with multiple Certificate Authorities.

2. Mutual recognition. Identity providers recognize each other's attestations. A user authenticated through Provider A's runtime can interact with a service that primarily works with Provider B. This is the equivalent of how Visa cards work at Mastercard terminals — the networks interoperate because the standard is shared.

3. No lock-in. Users can switch identity providers without losing access to services. Their agent's authorization history, delegation policies, and reputation are portable.

4. Federated trust registries. Instead of a single root of trust, the ecosystem maintains a federated registry of trusted attestation issuers — similar to how browsers trust multiple Certificate Authorities, and CAs can be added or revoked based on their behavior.

The Competitive Landscape

Why Competition Produces Better Identity

The instinct in identity is toward consolidation. "One identity to rule them all" sounds efficient. In practice, monopoly identity systems produce three predictable failures:

1. Single point of failure. When Okta was compromised in 2022, every service that relied on it was exposed. When Facebook's OAuth went down for six hours in 2021, millions of users couldn't log into unrelated services. Concentration of identity is concentration of risk. In the agent internet, where identity is a prerequisite for every transaction, a single-provider outage would halt the economy.

2. Misaligned incentives. A monopoly identity provider has no competitive pressure to improve privacy, reduce fees, or increase transparency. They can extract rents (charging services for verification), impose surveillance (tracking every agent interaction across every service), and degrade privacy (correlating agent activity into detailed user profiles) because there's no alternative.

3. Innovation stagnation. Competition drives experimentation. Different identity providers will try different approaches: some will emphasize privacy (zero-knowledge attestations that prove authorization without revealing identity). Some will emphasize speed (pre-computed attestation chains for latency-sensitive transactions). Some will emphasize compliance (attestations that satisfy specific regulatory requirements in specific jurisdictions). A monopoly provider has no incentive to explore any of these — the single solution they offer is the only option, whether or not it's the best one.

The Multi-Provider Model

In a healthy agent identity ecosystem:

No single provider would offer all of these. The ecosystem needs all of them. And because the standard is open, services can accept attestations from any provider — they compete on the attributes that matter to different users.

What Services Should Demand

Services considering agent identity integration should insist on three non-negotiables:

1. Provider portability. If a user switches identity providers, they should be able to continue accessing the service through their agent without re-registering. The service trusts the attestation standard, not a specific provider.

2. No cross-service tracking. The identity provider should not be able to correlate a user's agent activity across different services. Attestations should be service-specific or use pairwise pseudonyms — the same way that Apple's "Hide My Email" generates a unique address per service.

3. Transparent pricing. Identity verification costs should be predictable and published. Services should be able to compare providers on price, not be locked into opaque enterprise contracts.

The agent.json for Identity

Declaring Identity Capabilities

An identity provider publishes an agent.json that declares what they offer:

\{
  "agent": \{
    "name": "ExampleAuth Agent Identity",
    "version": "1.0",
    "payout_address": "0x...",
    "settlement_network": "base"
  \},
  "capabilities": \{
    "identity.attest": \{
      "description": "Issue a scoped attestation for an agent acting on behalf of a verified user",
      "auth": "runtime_keypair",
      "params": \{
        "user_proof": "string",
        "requested_scopes": "array",
        "target_service": "string",
        "ttl_seconds": "number"
      \},
      "returns": \{
        "attestation": "string",
        "attestation_id": "string",
        "expires_at": "string",
        "scopes_granted": "array"
      \},
      "cost_per_call": 0.001
    \},
    "identity.verify": \{
      "description": "Verify an attestation presented by an agent",
      "auth": "none",
      "params": \{
        "attestation": "string"
      \},
      "returns": \{
        "valid": "boolean",
        "scopes": "array",
        "issuer": "string",
        "expires_at": "string"
      \},
      "cost_per_call": 0
    \},
    "identity.revoke": \{
      "description": "Revoke an active attestation",
      "auth": "runtime_keypair",
      "params": \{
        "attestation_id": "string"
      \},
      "cost_per_call": 0
    \}
  \}
\}

Note: identity.verify is free. This is critical. Verification must be zero-cost to services, or adoption stalls. The identity provider monetizes issuance (charged to the runtime), not verification (used by services). This aligns incentives: providers compete to be the cheapest and most reliable issuer, and services have no cost barrier to accepting agent attestations.

How Runtimes Integrate

An agent runtime discovers identity providers the same way it discovers any capability — through the agent.json manifest. The runtime can integrate multiple identity providers simultaneously:

• Primary provider: The user's default identity provider, used for most attestations
• Fallback provider: Used when the primary is unavailable (resilience)
• Specialized provider: Used for specific contexts (e.g., a jurisdiction-specific provider for EU services, a privacy provider for sensitive interactions)

The runtime dynamically selects which provider to use for each attestation based on the target service's requirements, the user's preferences, and real-time availability.

Security Considerations

Threat Model

Agent identity introduces attack surfaces that don't exist in human identity:

Attestation replay. An attacker captures a valid attestation and replays it to gain unauthorized access. Mitigation: attestations include a nonce and are bound to a specific runtime instance and timestamp. Replayed attestations fail nonce verification.

Runtime impersonation. An attacker stands up a fake runtime and issues attestations claiming to be a legitimate runtime. Mitigation: runtime public keys are registered in the federated trust registry. Services verify attestation signatures against registered keys. Unregistered keys are rejected.

Scope escalation. An agent requests an attestation for "read email" and then uses it to "send email." Mitigation: attestation scopes are checked by the service at the action level, not just at the authentication level. An attestation for "read" doesn't authorize "write," regardless of what the agent claims.

Provider collusion. Two identity providers share attestation data to track users across services. Mitigation: the standard requires pairwise pseudonymous identifiers — each attestation uses a service-specific user identifier. Cross-service correlation requires breaking the pseudonymity, which is detectable through audit.

Privacy by Design

Agent identity, done wrong, is a surveillance nightmare. An identity provider that sees every attestation request knows: which user, which agent, which service, what scope, when. Aggregated across all users, this is a complete map of agent-mediated internet activity.

The standard must mandate:

1. Minimal disclosure. Attestations reveal only what the service needs. If the service needs to know "this agent is authorized to read email," the attestation should not reveal which human authorized it — only that a verified human did.

2. Unlinkability. Attestations for different services should not be correlatable by the identity provider or by services colluding with each other. This is achievable through zero-knowledge techniques and pairwise pseudonymous identifiers.

3. User-controlled data. The user can see every attestation issued on their behalf, revoke any of them instantly, and delete their history from the provider. No "we need to retain this for compliance" exceptions beyond legally mandated minimums.

4. Provider-blind verification. Ideally, the identity provider should not know which service the attestation is being used at. The runtime generates the attestation locally using a credential from the provider, and the service verifies it without contacting the provider. This is the model that Apple's passkeys and FIDO2 use — the identity provider is involved in setup, not in every transaction.

Integration Roadmap for Identity Providers

Phase 1: Declare Existing Capabilities

If you already have an OAuth or identity API, publish an agent.json that maps your existing endpoints to the standard capability format. This makes you discoverable by agent runtimes without building anything new.

Phase 2: Agent-Specific Attestation Product

Build the core product:

• Scoped, time-bounded attestation issuance
• Runtime registration and key management
• Verification endpoint (free, low-latency, globally distributed)
• User dashboard for delegation policy management
• Revocation endpoint with real-time propagation

Phase 3: Interoperability

This is where the competitive advantage crystallizes:

• Join the federated trust registry
• Accept attestations from other compliant providers (mutual recognition)
• Implement pairwise pseudonymous identifiers
• Support zero-knowledge attestation modes for privacy-sensitive contexts
• Publish interoperability test suites so other providers can verify compatibility

Phase 4: Advanced Capabilities

Differentiate on features the market values:

• Reputation-linked attestations: "This agent has completed 10,000 successful transactions with zero disputes" — a reputation score that transfers across services
• Delegated delegation: The user authorizes Agent A, which can sub-delegate specific scopes to Agent B. Useful for multi-agent workflows.
• Cross-jurisdictional attestations: A single attestation that satisfies identity requirements in multiple regulatory regimes simultaneously
• Offline attestation: Pre-computed attestation batches for latency-sensitive or offline-capable agent workflows

The Interoperability Imperative

Why Walled Gardens Fail Here

In human identity, walled gardens survive because switching costs are manageable. If you don't like "Sign in with Google," you create a username and password. The fallback exists.

In agent identity, there is no fallback. An agent that can't authenticate can't function. If a service only accepts attestations from Provider X, and the user's runtime uses Provider Y, the agent is locked out entirely. There's no "type in your password manually" for an agent.

This means walled gardens in agent identity don't just inconvenience users — they fragment the internet into incompatible zones. Service A only works with Provider X. Service B only works with Provider Y. The agent that needs to use both services on behalf of the same user is stuck.

Interoperability isn't a nice-to-have. It's an existential requirement for the agent internet to function.

The Certificate Authority Analogy

The closest historical precedent is the SSL/TLS certificate ecosystem. In the early days of HTTPS, there were proprietary certificate systems. They failed. What succeeded was an open standard (X.509) with multiple competing Certificate Authorities, a shared trust store, and transparent certificate issuance logs.

The result: any website can get a certificate from any CA, and any browser trusts it. CAs compete on price, speed, and reliability. Let's Encrypt proved that a free, automated CA could coexist with premium providers like DigiCert. The ecosystem is healthier for the competition.

Agent identity should follow the same pattern:

The standard is open. The providers compete. The ecosystem thrives.

What a Monopoly Provider Loses

A provider that attempts to monopolize agent identity will discover that the strategy backfires:

Services resist lock-in. Any service that accepts attestations from only one provider is vulnerable to that provider's pricing, uptime, and terms. Sophisticated services will demand multi-provider support — and they'll route traffic preferentially to services that offer it, because those services are more reliable.

Runtimes route around you. If a monopoly provider raises prices or degrades service, agent runtimes will build bridges to alternative providers. The standard is open — anyone can implement it. Monopoly pricing creates the economic incentive for competitors to enter.

Users leave. Users choosing an agent identity provider are choosing who controls their agent's access to the internet. A monopoly provider that surveils, overcharges, or restricts access will lose users to privacy-focused, cheaper, or more permissive alternatives. And because the standard requires provider portability, switching is low-friction.

Regulators intervene. Identity is a regulated domain in most jurisdictions. A monopoly provider controlling agent access to the internet would trigger antitrust scrutiny the way that consolidated dominance in search advertising has. Except the case would be easier to make — a single point of control over all agent-mediated commerce is a clearer bottleneck than search ranking.

The winning strategy is not to monopolize. It's to compete — on privacy, speed, reliability, compliance, and price — within an open standard that ensures your competitors can also compete. The rising tide of agent commerce lifts every provider that participates.

Conclusion

Identity is the gate. Every service on the internet requires it. Every agent interaction starts with it. The provider that solves agent identity — scoped attestations, cryptographic provenance, continuous consent — removes the second largest constraint on agent autonomy.

But the solution only works if it's open. A monopoly identity provider would fragment the agent internet into incompatible zones, concentrate risk in a single point of failure, and create a surveillance chokepoint that undermines the privacy the ecosystem needs.

The alternative — an open attestation standard with competing providers, federated trust, and mandatory interoperability — produces a system that is more resilient, more private, more innovative, and more trustworthy than any single provider could build alone.

The identity layer of the agent internet is being defined now. The providers who participate in building the open standard will earn the right to compete within it. The providers who try to own it will find that the ecosystem routes around them.

The second most valuable capability on the agent internet is the ability to prove you belong. Build it open.