82% of Companies Run AI Agents.
Only 28% Have Security Policies for Them.
The governance gap isn't theoretical. It's already inside your production environment — and it widens every time you deploy a new agent.
By Dave Ginsburg, Marketing Advisor, Skyrelis · 5 min read
Okta's AI Agents at Work 2026 report landed last month with a stat that should be on every CISO's radar: 82% of enterprises are deploying AI agents, and only 28% have a security governance policy in place for them. That's a 54-point gap between adoption and control.
Security leaders already know something is wrong. What they're still working out is where exactly the risk lives — and what to do about it before an incident forces the answer.
"The gap isn't between knowing and not knowing. It's between when an agent acts and when your security team finds out."
— SkyrelisWhat the Gap Actually Means at Runtime
Most conversations about "AI governance" still happen at the policy level — frameworks, principles, guidelines. That work matters. But here's the problem: agents don't act at the policy level. They act at runtime.
An agent executing a customer support workflow doesn't pause to consult your AI governance framework. It calls the tools it has access to, makes decisions based on the context it's given, and takes actions — right now, at machine speed — with no human in the loop.
By the time your security team reviews a log, the action has already happened. Files have been read. APIs have been called. Data has moved. The 72% of enterprises without a governance policy aren't just unprotected on paper. They're unprotected in the moment that counts.
This is what makes agentic AI different from every other software risk category. The risk isn't in the model. It's in the space between what the agent is allowed to do and what it actually does — and right now, for most organizations, that space has no walls.
Three Failure Modes Already Happening
Based on what we're seeing in conversations with enterprise security teams, three failure modes are already showing up in production agentic deployments:
1. Tool Abuse
Agents are built with access to tools — APIs, databases, external services. In a well-scoped deployment, those tools are constrained to what the agent needs. In practice, tool permissions tend to be set broadly at deployment time and rarely revisited. An agent that should only read from one database ends up with write access. An agent that should query internal docs can also call external endpoints. Nobody explicitly authorized the overage. Nobody explicitly blocked it either. The agent just had access.
2. Policy Drift
Enterprise customers have different compliance requirements. A healthcare customer has HIPAA constraints. A financial services customer has SOX controls. A government customer has data residency rules. If you're an AI-native company selling into enterprise, each of those customers effectively needs their own policy layer — and without runtime enforcement, you're managing that in code, in conversation, or not at all. Policy drift happens quietly, one edge case at a time, until an enterprise customer's audit finds it first.
3. Data Exfiltration in Multi-Agent Chains
This is the one that surprises people. In single-agent deployments, the blast radius is relatively contained. In multi-agent systems — where Agent A orchestrates Agent B which calls Agent C — data moves between agents without the visibility that exists for human-to-human communication. There's no email trail. There's no chat log. There's no record of what passed between agents unless you explicitly build one. Most organizations haven't built one.
What "Runtime Governance" Actually Looks Like
Here's what I tell security teams when they ask what Skyrelis does: governance can't live only in the design phase. It has to run with the agent.
Runtime governance means that every time an agent takes an action — calls a tool, accesses data, passes output to another agent — there is a policy layer that evaluates that action in context. Not after the fact. Not in a weekly audit. Before the action completes.
That means:
Per-session policy enforcement — each agent session runs under the policies that apply to this customer, this workflow, this context. Not a generic ruleset. Customer A's controls are enforced for Customer A's data, automatically, without forking your codebase.
Tool-level visibility — every tool call is observed, logged, and evaluated against policy before it executes. If an agent attempts to use a tool outside its authorized scope, that action is blocked and flagged — not discovered in a post-incident review.
Audit-ready chain of custody — in multi-agent systems, the entire decision chain is logged: what each agent received, what it decided, what it passed downstream. When your enterprise customer asks "what did your AI do with our data?" you have an answer.
The companies getting this right aren't the ones with the most sophisticated AI. They're the ones that treated governance as an infrastructure problem, not a compliance checkbox. The infrastructure has to run at the same speed as the agents — which means it has to run at runtime.
What's Your Current Agent Security Posture?
We built a free assessment that helps security and AI platform teams identify governance gaps in their current agentic deployments — takes about 15 minutes.
Take the Agent Risk Assessment →Dave Ginsburg is a marketing advisor to Skyrelis, which provides always-on runtime security and governance for agentic AI. Follow on LinkedIn.
Tags: Agentic AI Security · AI Governance · Runtime Enforcement · CISOs · Enterprise AI · Okta 2026