Your AI agents are sharing an API key

Here is my nomination for the least surprising security statistic of 2026: in Gravitee’s State of AI Agent Security survey of more than 900 executives and practitioners, 45.6% of organizations said they authenticate agent-to-agent communication with shared API keys, and only 21.9% treat agents as independent identity-bearing entities. The rest of the report follows from those two numbers the way a root cause follows from an incident: 88% of organizations reported a confirmed or suspected agent-related security incident in the past year, rising to 92.7% in healthcare.

Attribution and salt, before anything else. Gravitee sells agent and API governance, this is a single vendor survey, and “confirmed or suspected” is a wide net. I’d treat the specific percentages as directional. What I wouldn’t dismiss is the shape, because I watch the same shape from the inside: agents arrived in production years before the controls did. The same survey has 80.9% of technical teams past planning into testing or production, while only 14.4% report that all their agents were deployed with full security and IT approval. Adoption at eighty percent, full approval at fourteen. That gap is the story, whatever the error bars.

Why shared keys break worse with agents

A shared credential was already the classic infrastructure sin. Agents make it qualitatively worse in three ways that ordinary services don’t.

Agents act autonomously on non-deterministic logic, so you can’t reason from the code what the credential will be used for. A service with a shared key does what it was written to do. An agent with a shared key does what a model decided in context, which is precisely the thing you want an audit trail for and precisely what a shared identity erases: when every agent is the same principal, logs answer “something did this” and nothing more.

Agents multiply. In Gravitee’s data, 25.5% of deployed agents can spawn and task other agents. A spawned agent inherits whatever access pattern its parent had, and with shared keys that means the population of things acting as one identity grows at runtime, unbudgeted.

And agents concentrate blast radius. The large-enterprise picture is blunt: in the 2026 CISO AI Risk Report, a Cybersecurity Insiders survey of 235 CISOs and CIOs at 5,000-plus-employee enterprises sponsored by Saviynt, 92% said they lack full visibility into the AI identities in their environment, and only 5% were confident they could contain a compromised agent. Those are large-enterprise numbers with a vendor sponsor, so read them as a leading indicator rather than a measurement of mid-size reality. The mid-size version is usually the same gap with a smaller security team standing in front of it.

The identity floor, concretely

This is infrastructure work, and it’s work I do in my day job, where the agentic tooling ships changes toward production behind guardrails I built. The floor looks like this.

One principal per agent. Every agent gets its own identity, an IAM role, a service account, a workload identity, whatever your platform’s primitive is, and shared keys between agents go away entirely. This single change converts “something with the key did it” into “agent X did it,” which is the difference between an investigation and a guess.

Least privilege, scoped to the task. An agent that reviews Terraform plans needs read access to plans, and nothing else. Mine run read-only for triage and review work, and anything that writes goes through an automated create-only gate that runs before any apply, plus a human approving every production-affecting change. Autonomy is granted per capability, never as a general property.

Short-lived credentials, never stored ones. Agents authenticate the way modern CI does, via identity federation that issues expiring credentials, so there is no long-lived secret to leak, share, or forget. This site’s own deploys work that way, with zero stored cloud keys, and agents deserve the same standard.

Per-agent audit, plus a kill switch. Logs keyed to agent identity, and a tested way to revoke one agent’s access without turning off all of them. The Gravitee finding that organizations monitor, on average, less than half of their agents describes exactly the population this fixes.

Spawn control. If agents can create agents, that power is itself a permission: scoped, logged, and off by default.

None of this is novel security thinking. It’s the boring, known identity discipline your services already follow, extended to a new kind of principal that arrived faster than the paperwork. The reason to do it now is that the alternative has a failure mode you can’t investigate: an incident, one shared key, and no way to say which of your agents was the one that acted. Getting agent identity in place before granting more autonomy is the order of operations, and it’s the buildout I do for teams that want the agent throughput without betting the account on it. The governance layer that sits above these controls, who approves an agent, who owns the inventory, what the standards bodies are doing about it, is its own piece.