Security & governance

The governance gap: why most agents aren't actually production-ready

Most organizations don't lack the appetite to deploy AI agents. They lack confidence in their own ability to govern them once they're live.

It's tempting to assume the barrier to production is purely technical — model quality, latency, cost. The data points somewhere else: trust and governance are the real holdouts, even among teams that already have a working agent.

74% of IT application leaders believe AI agents represent a new attack vector into their organization — yet only 13% strongly agree they have the right governance structures in place to manage them. Source: Gartner Newsroom, "Gartner Survey Finds Just 15% of IT Application Leaders Are Considering, Piloting, or Deploying Fully Autonomous AI Agents" — gartner.com

That 61-point gap between perceived risk and actual confidence is the reason so many agent projects stay in "pilot" purgatory indefinitely. Leadership isn't wrong to be cautious — they're responding to a real, underbuilt layer of the stack.

Where the risk actually comes from

Unlike traditional software, an agent doesn't just return an answer — it can call tools, access data, and take actions on its own. That expanded surface area is exactly what security researchers are flagging as the open problem in agent deployments today.

25% of enterprise GenAI applications are predicted to experience at least one major security incident per year by 2029, up from 3% in 2025 — driven largely by new integration protocols that prioritize speed over built-in security enforcement. Source: Gartner Newsroom, "Gartner Predicts 25% of All Enterprise GenAI Applications Will Experience At Least Five Minor Security Incidents Per Year By 2028" — gartner.com

What closes the gap, concretely

None of this means agents should stay in pilot mode indefinitely — it means governance has to be built in before launch, not bolted on after an incident. In practice, that comes down to a short list of concrete controls:

Least-privilege IAM for agents specifically. An agent should never inherit a human admin's permission set by default — it gets scoped access to exactly what its task requires.
Secrets out of code, always. API keys and credentials live in a secrets manager, not in a config file an agent (or a contributor) can read directly.
Full audit trails. Every tool call and data access an agent makes is logged — so when something goes wrong, the question "what did it actually do" has a real answer.
Network isolation. Agents that don't need internet or cross-system access shouldn't have it, even if it's more convenient to leave open during development.
A formal review before any agent reaches data it didn't need in the prototype phase. What was harmless in a sandboxed demo often isn't once it's touching production data.

This is genuinely good news for anyone trying to ship: the gap is closeable with known, well-understood security practices — it's not a research problem waiting on a breakthrough. It just has to be someone's explicit job.

Not sure if your agent's access model would survive a real audit?

Security & access — IAM, secrets, encryption, audit logging — is part of every engagement we run, not an add-on.

Book a 20-min fit call →

← Back to Deep Sapphire