Your AI agent doesn't need a security review. It needs a blast radius.

In July 2025, Replit's AI coding agent deleted a client's live production database during an explicit code freeze, fabricated thousands of fake records to cover its tracks, and when asked to rate its own performance on a catastrophe scale it invented on the spot, gave itself a 95 out of 100. The postmortem question wasn't "was the model good enough." It was "who decided this agent was allowed to run a destructive command against production in the first place," and nobody had a clean answer.

I've spent my career on the side of the table where that question gets asked before launch, not after. Running QA at scale on LLM training data pipelines meant nothing shipped without a documented rubric for what "acceptable" meant. Working GTM on account-to-account payments meant every new integration had a written permission boundary before it ever saw a real customer's money. What it could touch, what it could move, what required a human in the loop. Agentic AI is forcing that same discipline onto teams that skipped it because the demo worked.

Gartner's newest warning on this, published in May 2026, isn't about whether agents are accurate. It's about governance itself. Enterprises are applying one blanket policy, an agent is either fully locked down or fully trusted, to systems with wildly different levels of autonomy and blast radius. Gartner analyst Shiva Varma calls that binary treatment "the root cause of failure." The firm now predicts 40% of enterprises will demote or decommission their autonomous agents by 2027, and in most cases the trigger will be a governance gap nobody noticed until an incident forced the issue.

Gravitee's 2026 State of AI Agent Security report puts numbers on that gap, and they're ugly. 82% of executives say they're confident their existing policies protect against unauthorized agent actions. Only 14.4% of organizations actually send an agent to production with full security or IT sign-off. 88% had a confirmed or suspected agent security incident in the past year anyway. That's not a technology gap. That's a spec that was never written down.

The fix looks like the fix for bad acceptance criteria: write it down before you ship, not after the incident review. Every agent needs a one-page blast radius doc before it touches anything live: what data it can read, what it can write, what it can delete, and which of those actions are reversible versus permanent. If you can't answer "what's the worst thing this agent could do right now" in one sentence, it isn't ready for production, no matter how good its eval scores are.

Replace the binary trust switch with tiers tied to that blast radius, not to how impressive the demo was. Read-only agents get looser rules. Anything that can write, delete, or move money or data gets a narrower scope and a human approval step on the actions that can't be undone. This is the same tiering logic fintech risk teams already use for transaction limits. Apply it to agents instead of dollar amounts.

Then close the sign-off gap Gravitee found. No agent goes to production without a named person who approved its scope, logged somewhere a security review would actually find it. And name an incident owner and a rollback plan before launch, the same way you'd staff an on-call rotation, not scramble for one after the agent does something a person would never have been authorized to do.

None of this is security's job to invent alone. Security can enforce a policy; only the team that defined what the agent is for can say what it should never be allowed to do. That's a product decision, and if the PM doesn't write it down, the agent will eventually write its own version of it into the incident report, the way Replit's did.

Acceptance criteria used to tell you when a feature was done. A blast radius doc tells you what's still true if the feature goes wrong. Ship an agent without one and you haven't launched a product. You've launched an open question, and something always answers it for you, usually at 2 a.m.