The headline figure circulating this year is that 88% of organizations have had an AI agent security incident. It comes from Gravitee’s State of AI Agent Security 2026 report, which surveyed more than 900 executives and technical practitioners.

Before building an argument on it, the number needs two qualifications, because they change what it can support.

First, the measure is “confirmed or suspected.” The report’s own phrasing is that 88% of organizations “confirmed or suspected security incidents this year.” Confirmed and suspected are very different epistemic states, and collapsing them into a single percentage inflates the certainty. A more defensible reading of that figure is the share of organizations that have seen something they could not rule out — which is still meaningful, and is arguably the more interesting number given how thin agent observability currently is.

Second, this is a vendor survey with a partially disclosed methodology. The public summary gives the sample size but not the geographic distribution, industry breakdown, sampling method, or field dates. That does not make it worthless; it makes it a directional indicator rather than a measurement.

Cited with those qualifications, it is usable. Cited as “88% of organizations have been breached via AI agents,” it is not what the source says.

The finding underneath the headline is the durable one

The same report puts the share of teams that treat AI agents as independent, identity-bearing entities at 22%. Against that, 45.6% still rely on shared API keys, and 27.2% have fallen back to custom hardcoded logic.

That structural finding is more robust than the incident percentage, because it describes an architecture rather than an event count — and it is corroborated elsewhere. A January 2026 survey of 383 IT and security professionals by the Cloud Security Alliance with Oasis Security found 92% were not confident their existing IAM tooling could manage AI and non-human identity risk, and 78% had no documented policy for creating or removing agent identities.

Two independent surveys pointing at the same gap, from different angles, is a stronger signal than either percentage on its own.

Why shared credentials break the security model specifically

The problem with an agent operating on a shared API key is not that the key is weak. It is that the key destroys the properties your entire detection and response model depends on.

Attribution disappears. When five agents and a CI pipeline authenticate as the same principal, an anomalous action cannot be traced to an actor. Your incident response starts from “something using this key did this” — which is where most of the investigative value has already been lost.

Least privilege becomes unenforceable. A shared credential’s permission set is necessarily the union of what every consumer needs. Add a sixth consumer requiring one additional scope, and all five existing consumers silently receive it. Permission sets on shared credentials only ratchet upward.

Revocation becomes an outage decision. If you suspect a single agent is compromised and it shares a credential with production workloads, killing the credential is a production incident. That converts a containment action into a business-impact tradeoff, and in practice it means containment gets delayed while someone finds out what else will break.

Lifecycle management has no anchor. Human identities have joiners, movers, and leavers, and the HR system is an authoritative source for all three. An agent spun up for a project has no equivalent event to trigger deprovisioning. The 78% figure on missing creation-and-removal policy is the direct measurement of this gap.

None of these are new problems — this is the non-human identity problem that service accounts have posed for two decades. What is new is the rate of creation. Agents get instantiated by developers, by platform features, and increasingly by other agents, on a timescale that a quarterly access review cannot track.

What “identity-bearing” needs to mean in practice

Treating an agent as a first-class identity is a concrete set of properties, not a posture statement:

  • A unique, non-shared principal per agent, so that every action is attributable to exactly one actor.
  • Short-lived, automatically rotated credentials rather than long-lived static keys. Workload identity federation is the mature pattern here; it exists precisely so that a workload can prove what it is without holding a secret that can be stolen.
  • A scoped permission set derived from what that agent does, and an owner recorded against it who is accountable for that scope.
  • A defined lifecycle with an expiry, so that an unused agent identity ages out by default rather than persisting until someone audits it.
  • Independent revocability, so that containing one agent does not require taking down others.
  • Action-level logging that records the agent principal, not just the upstream service account or the human who originally deployed it.

The standards picture is moving

This is not a space where you have to invent primitives. The IETF published a draft agent identity management specification in March 2026 that composes WIMSE, SPIFFE/SPIRE, and OAuth 2.0 rather than defining a parallel stack, and NIST’s NCCoE issued a companion concept paper in February 2026 with a public comment period that ran through April.

The practical implication for a security team today is to avoid building a bespoke agent-identity scheme that will need unwinding. SPIFFE/SPIRE-style workload identity is deployable now and is the substrate the emerging drafts are converging on.

Where to start if you are in the 78%

The first move is not tooling. It is an inventory: which agents exist, what credential each one authenticates with, what that credential can reach, and who owns it. In most environments that inventory does not exist, and assembling it surfaces the specific problems worth funding — usually a small number of extremely over-scoped shared keys doing most of the work.

The second move is a hard rule that new agents get unique identities, applied from a fixed date forward. Retrofitting every existing agent is a long project; stopping the population from growing is not.

One closing note on the survey data, because it points at the organizational shape of this problem: 82% of executives reported confidence in their existing protective policies, while respondents estimated that under half of their agents were actively monitored. The confidence gap is the thing to manage. An inventory is also the fastest way to close it, because it replaces an impression with a count.