54% of Enterprises Have Already Had an AI Agent Security Incident — And Most Still Let Agents Share Credentials

More than half of enterprises have already been burned by an AI agent security incident. And the part that gets me: most of them are still doing the one thing that almost guarantees there'll be a next one.

That's the headline finding from Gravitee's State of AI Agent Security 2026 report, which surveyed over 900 executives and technical practitioners. 18% confirmed a full-blown security or data privacy incident involving an AI agent in the past twelve months. Another 36% caught a near-miss before it caused actual damage. Add those together and you get 54% of organisations that have either been hit or nearly were.

Let that land for a second. AI agents went mainstream in enterprise IT maybe eighteen months ago, and already the majority of companies running them have a war story.

This isn't a think-piece about hypothetical risks. The incidents are happening now, at scale, and the root causes are depressingly familiar to anyone who's worked in identity and access management: agents running on shared credentials, zero visibility into what they're actually doing, and governance bolted on after the fact — if it exists at all.

What does 'incident' actually mean here?

The Gravitee survey breaks it into two buckets. The 18% confirmed incidents are the serious ones: data exfiltration, unauthorised access to systems, PII leakage through agent tool calls, and agent-to-agent communication that nobody authorised. The 36% near-misses are the ones where a security team caught something wrong before it cascaded — an agent attempting to access a database it shouldn't have been able to reach, or an anomalous spike in API calls that got flagged in time.

Both numbers matter. The confirmed incidents tell you the blast radius is real. The near-misses tell you the problem is structural — you don't get a 36% near-miss rate from one-off configuration errors. You get it when the default posture is too permissive and teams are relying on luck and alert fatigue to catch the worst.

The CSA's own research, published in April, backs this up from a different angle. They found that 47% of organisations experienced an AI agent scope violation in the past year. Same pattern: the boundaries are too loose, and agents keep stepping over them.

Credential sharing: the original sin of agent security

Here's the stat that made me put my coffee down. Most enterprises are provisioning AI agents with service-account-level credentials that multiple agents share. Not per-agent identities. Not scoped access tokens. Just a service account key handed out like a spare office badge.

The logic is easy to follow, even if the outcome is predictable. Teams are under pressure to ship. Setting up a dedicated identity per agent — with its own credential lifecycle, access policy, and audit trail — takes infrastructure work nobody budgeted for. So someone grabs a service account that already has access to the systems the agent needs, and they ship.

What happens next: that service account accumulates more access over time because other agents get pointed at it too. Nobody rotates the credentials because three different teams are using them and nobody knows what'll break. The blast radius of a compromise grows quietly in the background.

Microsoft published guidance on this exact problem on 16 July — the same week the Gravitee data landed — arguing that AI agents need to be treated as first-class principals. Each agent gets its own identity. Access is scoped to what that specific agent needs for its specific task. Credentials are bound to that identity, not shared across a department's worth of automation. This is standard IAM hygiene. Enterprise agent deployments are mostly skipping it.

Only one in four companies can see what their agents are doing

If the credential problem is bad, the visibility problem is worse. Gravitee found that only 24.4% of organisations have full visibility into which AI agents are communicating with each other, what data they're accessing, and what actions they're taking across systems.

Three-quarters of enterprises running AI agents are essentially operating blind. If you asked the average CISO to show you a complete log of every API call, every database query, and every inter-agent handoff from the past 24 hours, the honest answer would be: "give me a week and a budget for tooling."

The tools generate the data. Nobody's connected them. Most agent frameworks emit logs. Most API gateways capture requests. But those logs live in different systems, use different formats, and nobody has wired them together into a coherent audit trail. When an incident happens, the investigation takes days because the evidence is scattered across a dozen dashboards.

The governed-platform alternative

The governance problem is worst where agents are built on general-purpose frameworks — custom code stitched together with API keys stored in environment variables, deployed wherever the developer had compute available. These are the setups where the 54% incident rate lives.

Platforms that bake governance into the runtime — Stacker, Bubble, and a handful of others — sidestep a lot of this by design. When an agent lives inside a governed platform, it doesn't get a service account key. It gets a proper identity that inherits from the user who created it. Every action is scoped by that user's permissions. Every tool call, data access, and workflow trigger is written to an audit trail that's queryable in real time.

This is infrastructure, not a bolt-on. If the platform's permission model says a particular user can only read from three tables and can't touch billing data, then every agent that user creates inherits those exact boundaries. No shared credentials. No over-permissioned service accounts. No mystery agent-to-agent chatter that nobody reviewed.

I'm not saying every enterprise should abandon custom agent development and move everything to a governed no-code platform. But if you're running agents in production and you don't have per-agent identity, least-privilege access, a unified audit trail, and a kill switch, you're in the 54%. The only question is whether you'll catch the next incident before it becomes the 18%.

A practical framework: four things to fix today

If you're building or managing AI agents in an enterprise context, here's what I'd fix in order of priority.

1. Agent identity. Every agent gets its own identity. Not a shared service account. Not the developer's personal API key. A machine identity with its own lifecycle: created with a specific scope, rotated on a schedule, revoked when the agent is decommissioned.

2. Least-privilege access. The agent gets access to exactly what it needs and nothing else. Customer-support agent that queries order status? It doesn't get write access to the orders table. Needs three endpoints? It doesn't get a wildcard API key. This sounds obvious. It's not what most teams are doing.

3. Unified audit trail. Every action the agent takes — API call, database query, handoff — is logged to a single, queryable trail. When something goes wrong, you shouldn't need three teams and a war room to trace what happened. The audit trail should be the first thing you check, not the last thing you build.

4. Kill switch. A single control that immediately suspends an agent's access across all systems. Not "open a ticket to revoke the service account." Not "ask the team that provisioned it to take it offline." One button, one API call, agent stops. If you don't have this, you're gambling that every incident will be slow-moving enough for a multi-team response. Some won't be.

The takeaway

54% is a big number, but it's not the scariest one in the data. The scariest number is 24.4% — the share of organisations that can actually see what their agents are doing. Because that number tells you the 54% is probably an undercount. You can only confirm incidents you can detect.

Governance for AI agents isn't a compliance checkbox. It's the difference between agents that accelerate your business and agents that become an unmanaged attack surface. The platforms that treat governance as infrastructure — identity, permissions, audit, kill switch, all built into the runtime — are the ones where agents can actually be trusted in production. Everything else is security debt that comes due at the worst possible moment.