AI Agents Need Cryptographic Identity
Every AI agent in production today authenticates the same way: it borrows a human's credentials or shares a service account with every other agent in the system. There is no unique identity, no audit trail tied to a specific agent, and no way to revoke one agent's access without revoking them all. At Google Cloud Next 2026, Google introduced cryptographic agent identities in Gemini Enterprise — unique, verifiable, and traceable per-agent credentials. The move signals that agent identity management is becoming a first-class infrastructure concern. The question is no longer whether agents need their own identities. It is how fast teams can implement them before the current model collapses under scale.
The Problem: Agents Without Identity
Most teams deploying AI agents today use one of two authentication patterns. Neither was designed for autonomous software actors.
Pattern 1: User impersonation. The agent receives a human user's OAuth token or API key and operates with that person's full permissions. The audit log shows "Alice accessed the billing database" when in fact an agent acting as Alice accessed it. If the agent makes a mistake — deleting records, sending emails, modifying configs — the trail points to Alice. If Alice leaves the company, every agent using her token stops working.
Pattern 2: Shared service accounts. All agents share a single service account — svc-agent-prod — with broad permissions. The audit log shows the same identity for every action regardless of which agent performed it. There is no way to determine which agent initiated a change, when it was authorized, or whether the action aligned with its assigned scope. Revoking access for one compromised agent means revoking access for all of them.
Both patterns work at small scale. A team running three agents with well-defined scopes can manage shared credentials. The breakdown begins at the inflection points: when the organization crosses a dozen active agents, when agents from different teams share infrastructure, when agents chain calls to external services, and when regulatory audits require per-action attribution.
The root cause is structural. Current identity and access management systems were built for two entity types: humans and services. AI agents are neither. They are more autonomous than services (they initiate actions based on inference, not triggers) and less accountable than humans (they cannot be held responsible for outcomes). Existing zero-trust architectures assume every request comes from a known, authenticated principal. Agents operating with borrowed identities violate that assumption at the foundation.
The Identity Gap in Numbers
The scale of the problem becomes clearer when mapped against adoption data:
| Metric | Value | Source |
|---|---|---|
| Organizations deploying AI agents in production | 78% | McKinsey, Q1 2026 |
| Agents using shared service accounts | ~90% | Enterprise IAM surveys, 2025-2026 |
| Agents with unique, traceable identities | <5% | Industry estimates |
| Average agent-to-credential ratio in enterprises with 10+ agents | 12:1 | Enterprise surveys, 2026 |
| Security incidents involving compromised agent credentials | +340% YoY | CrowdStrike, 2026 |
| Zero-trust architectures that account for agent identities | <8% | Forrester, 2026 |
The divergence is sharp: adoption of agents is accelerating while identity infrastructure for agents is nearly non-existent. That gap is the attack surface.
How Cryptographic Agent Identity Works
Google's approach in Gemini Enterprise provides a concrete reference implementation. Each agent receives a unique cryptographic identity — a public-private key pair provisioned at agent creation. The identity is not a username and password. It is a verifiable, machine-readable credential that other systems can validate without contacting a central authority.
The model works in four phases:
Phase 1: Provisioning
When an agent is created, the platform generates a unique key pair. The private key stays within the agent's execution environment — never transmitted, never stored in plaintext outside the enclave. The public key is registered with the organization's identity provider, along with metadata: agent name, assigned scopes, creation timestamp, and the team or project that owns it.
Phase 2: Authentication
When the agent makes a request — calling an API, accessing a database, writing to a storage bucket — it signs the request with its private key. The receiving service validates the signature against the registered public key. No token interception or credential theft can compromise the identity without the private key material.
Phase 3: Authorization
Each agent identity carries specific, narrow scopes. A research agent can read from the knowledge base but cannot write to production databases. A deployment agent can push to staging but cannot access customer data. Scopes are attached to the identity, not inherited from a shared service account. This means revoking or narrowing one agent's permissions requires updating only that agent's identity record.
Phase 4: Audit and Traceability
Every action the agent performs is logged with its unique identity as the principal. The audit trail answers: which agent made this change, what scope authorized it, when was it provisioned, and who approved its creation. This is the capability that shared service accounts fundamentally cannot provide.
Exceptions: When Shared Credentials Still Suffice
Cryptographic agent identity is not necessary in every deployment. There are specific scenarios where the overhead is not justified:
- Single-agent prototypes: A team running one agent in a sandboxed environment with no production access does not need unique identity. The cost of provisioning infrastructure exceeds the risk of the credential being compromised.
- Stateless, short-lived agents: Agents that execute a single task and terminate within minutes — a one-off data transform, a batch classification job — generate minimal audit surface. A scoped service account with time-limited tokens is sufficient.
- Air-gapped environments: Systems with no external network access and strict physical security have a fundamentally different threat model. The credential attack surface is already constrained by the network boundary.
- Agents with no lateral movement potential: If the agent can only call one API and that API has no downstream dependencies, the blast radius of a credential compromise is inherently limited.
The pattern to watch: the moment an agent chain calls to a second service, reads sensitive data, or persists for more than a single session, the shared-credential model becomes a liability. The threshold is lower than most teams expect.
The Honest Assessment
Cryptographic agent identity solves the authentication and attribution problem. It does not solve the authorization intelligence problem. An agent with a valid cryptographic identity and overly broad scopes will cause the same damage as a shared service account. The identity proves who acted, not whether the action was correct.
Here is how the current landscape breaks down:
| Approach | Identity Uniqueness | Audit Granularity | Revocation Precision | Implementation Cost |
|---|---|---|---|---|
| User impersonation | None (borrowed) | Per-user (misleading) | All-or-nothing (revoke user) | Low |
| Shared service account | None (shared) | Per-account (ambiguous) | All-or-nothing (revoke all agents) | Low |
| Per-agent service account | Partial (manual) | Per-agent (manual tracking) | Per-agent (manual rotation) | Medium |
| Cryptographic agent identity | Full (unique per agent) | Per-action (automatic) | Per-agent (instant, targeted) | High (today) |
The "High (today)" cost is the real barrier. Google's implementation is tied to Gemini Enterprise. AWS and Azure have not yet shipped equivalent native capabilities. Teams building on other platforms must assemble their own agent identity layer — combining SPIFFE/SPIRE for workload identity, OAuth 2.0 for token management, and custom middleware for agent-to-identity binding. This is feasible but requires infrastructure engineering that most teams have not budgeted.
Rubrik's "undo agent mistakes" tool, also announced at Cloud Next 2026, highlights the adjacent problem: even with perfect identity, agents will take actions that require rollback. Identity makes those actions traceable and attributable. It does not prevent them. The two capabilities — identity and rollback — are complementary, not substitutes.
The MCP security crisis adds urgency. With 150 million-plus MCP SDK downloads and 10 CVEs issued for remote code execution vulnerabilities, the supply chain into agent systems is under active exploitation. When agents share credentials, one MCP vulnerability compromises every agent on the shared account. When each agent has a unique cryptographic identity, the blast radius is confined to the compromised agent's scopes.
Actionable Takeaways
- Audit your current agent credential map. Count how many agents share each service account. If the ratio exceeds 3:1, you have a blast radius problem that will compound with each new agent deployment.
- Implement per-agent service accounts as a bridge. Before cryptographic identity infrastructure matures, assign each long-lived agent its own service account with narrowly scoped permissions. This is the minimal viable improvement over shared credentials — manual but immediately actionable.
- Evaluate SPIFFE/SPIRE for agent workload identity. If your infrastructure runs on Kubernetes, SPIFFE provides a vendor-neutral framework for issuing cryptographic identities to workloads. It is not agent-specific but maps well to the problem: each agent deployment is a workload that can receive a unique SVID (SPIFFE Verifiable Identity Document).
- Build agent identity into your governance framework. Microsoft's open-source AI Agent Governance Toolkit (released April 2026) includes runtime policy enforcement across agent frameworks. Integrate it with your identity provider so that policy violations are traceable to specific agent identities, not shared service accounts.
- Plan for vendor-native agent identity. Google has shipped the first implementation. AWS and Azure will likely follow within 12 to 18 months. Architecture your agent identity layer to be portable — use OIDC as the federation protocol — so that when your cloud provider offers native agent identities, migration is a configuration change, not a rewrite.
- Segregate agent scopes by function, not by team. Research agents, deployment agents, and data-processing agents each need fundamentally different permissions. Scope by capability, not by organizational ownership. This reduces the blast radius of any single identity compromise regardless of which identity model you use.
Agent identity is not a future concern. It is a present gap that widens with every agent deployed. The teams that implement per-agent identity now will avoid the audit failures, credential compromises, and compliance violations that are inevitable when agents operate without unique, traceable credentials. The infrastructure is still assembling. The pattern is clear. Build identity into your agents before you are forced to retrofit it after a breach.