88% of AI Agents Shipped Without Security Sign-Off

A team ships their first AI agent on a Tuesday. By Thursday, it’s made unauthorized API calls that exposed customer data. Nobody asked for security review. Nobody knew they should have.

This isn’t a hypothetical. This is what Gravitee’s 2026 State of AI Agent Security report found: 88% of organizations report confirmed or suspected AI agent security incidents. And the kicker—only 14.4% of those teams had full security approval before deploying in the first place.

The pattern isn’t hard to spot. Agents get treated like features. Features ship fast. Security review gets skipped or happens after deployment. By then, the agent’s already talking to your database.

Answer-First Summary

Gravitee’s 2026 data reveals only 14.4% of organizations secured full security sign-off before deploying AI agents, yet 88% experienced confirmed or suspected security incidents. The gap between how teams ship agents and how they should ship agents has become the defining security failure of the year.

Why We’re Shipping Agents Without Security Approval

The honest answer: speed and confusion about what agents actually are.

Agents feel like features because they look like features. You wire up an LLM, give it access to a few APIs, deploy it. It works. The momentum carries. Nobody stops to ask whether this thing needs identity, authentication, or access controls. Nobody has a checklist. Security teams haven’t written one yet because agent security is only two years old as a practice.

It’s the same pattern that led to unguarded databases in 2015 and misconfigured S3 buckets in 2018. New capability category + no standard practice + fast shipping timelines = security gets left behind.

But there’s something worse underneath: most teams don’t realize agents are identity-bearing entities. That’s the blind spot. Gravitee found that only 21.9% of organizations treat agents as entities that need authentication and authorization controls—the same controls you’d apply to a human user or a service account.

If your agent doesn’t need to prove who it is before it calls your API, someone else’s agent will prove it for them.

The Real Cost: Attack Timelines Got Shorter

This is where data from IBM X-Force and CrowdStrike becomes impossible to ignore.

CrowdStrike’s 2026 Global Threat Report shows that average dwell time—the time between initial compromise and detection—has collapsed to under 72 minutes for AI-driven attacks. IBM X-Force documents the same escalation: AI-powered attacks are getting faster, more precise, and harder to distinguish from legitimate behavior.

A human attacker might take hours to locate valuable data in your system. An agent running in your infrastructure knows exactly where to look because it’s been trained on your codebase and API schema. If it doesn’t need to authenticate, it moves fast. By the time your SOC team gets a Slack notification, the agent’s already made decisions that affect your business.

The math is grim: if your incident response SLA is 4 hours and attackers have 72 minutes to act, you’re not responding to the incident. You’re investigating the wreckage.

What This Looks Like in Practice

Here’s where the human-AI parallel lands hard.

When a person joins your company, you don’t hand them the master database password on day one and tell them to figure out what they can access. You set up role-based permissions. You audit what they touch. You can revoke access in seconds if something goes wrong. You apply the principle that people should only have what they need, when they need it.

Agents should get the same rigor. Better, actually, because agents don’t have judgment. They won’t second-guess a weird instruction the way a human would. They won’t spot a social engineering attack. They’ll just execute.

And yet: most agent deployments skip the entire access control layer. The agent gets permissions. Nobody audits what it actually does. There’s no way to revoke access if it starts misbehaving. This is what an “uncontrolled agent” really means—not broken code, but code with identity nobody controls.

The Signal in the Data

When 88% of organizations report security incidents but only 14% had security approval before shipping, the gap comes down to process.

Process is what Newton and Hawking and every other person who solved hard problems understood: if you want a different outcome, change the system that produces outcomes. You don’t get safer agents by hoping developers think of security. You get safer agents by making security impossible to skip.

That means: agents don’t ship without identity. Period. No API calls happen without authentication. No permissions get granted without audit. No deployment goes live without security team review—and that review happens before the thing is live, not after.

Gravitee’s data reads like a field report from teams that learned this the hard way. The organizations that had full security approval before deploying? They’re not in the 88%. They’re in the 14.4% that got ahead of the problem.

What You Can Do This Week

If you’ve already shipped agents, you need a post-deployment security audit. Not a penetration test. Not a theoretical exercise. An actual review of:

1. What identity does your agent have? Can you name it? Revoke it? Audit what it’s done with it?
2. What APIs can it call? Is that list smaller than “all of them”?
3. What data can it access? Would you let a temporary contractor access that data unsupervised?

If you’re planning to ship agents, the bar is higher: get security sign-off before it’s deployed. Make it non-negotiable. Make it part of your definition of done. The 14.4% of teams that did this are the ones sleeping through the night.

The teams in the 88%? They’re writing incident reports and learning lessons the expensive way.

---

Next in the series: How Fast Can an Attacker Hijack Your Agent?—where we map the 72-minute window and show where the breach actually happens.