· Security
Why 77% of AI Security Strategies Can't Be Enforced
77% of organizations updated their security strategy for AI. Only 26% can enforce it before a tool call runs. Where that 51-point gap lives.
The strategy nobody can enforce
Your organization just updated its AI security strategy. New policies. New guidelines. New approvals at the CISO level.
Now ask yourself: can you actually enforce any of it before a tool call executes?
If you're one of the 74%, the answer is no. And you're not alone.
Here's the number that needs more attention: 77% of organizations have updated their security strategies in response to AI. Only 26% say they have the architectural capability to enforce those strategies.
That's a 51-point gap. 3 out of 4 organizations with a strategy and no enforcement lever. The entire AI security industry is currently a lot of plans and very few guardrails that actually stop an action before it happens.
Those numbers come from Check Point's 2026 Cloud Security Report, published May 26, 2026. The same report says more than half of organizations have already had an AI-related security incident. These are not projections. They're the current state.
Let me show you what's missing.
The gap lives in one layer: pre-action authorization
Security teams know what they want to happen. The agent should only access the data it needs. The agent should not call destructive tools without approval. The agent should not exfiltrate data.
But most AI agent implementations check these after the tool call: logs, monitoring, incident response after the fact. That's not enforcement. That's forensics.
O'Reilly's AI Agents Stack 2026 captured this shift perfectly: "In 2024, guardrails meant input/output filters on a model. In 2026, your agent calls tools, spends money, and takes actions."
That change moves the security boundary. When agents were just generating text, you could filter output and call it done. When agents read your database, update your CRM, and send emails, output filtering is a speed bump rather than a firewall.
What you need instead is tool-scoped guardrails: validation, permission checks, risk scoring, and approval gates that fire before the tool executes. Not during. Not after. Before.
How the gap shows up in practice
Four failure shapes. All hypothetical, none exotic, and each one is a single tool call away in an agent that has the permissions to do its job.
The document-read agent that sends everything. The agent is authorized to read internal documents only. But the model reads one document, extracts every row, and outputs it in an email response. The action, sending the email, looks legitimate. The content contains data the agent should never have transmitted.
Output filters catch this sometimes. But the agent already did the damage. Pre-action authorization asks: "This agent is reading customer PII. Is this email recipient allowed to receive it?" Before the email hits the outbox.
The automation that deletes instead of archives.
An agent is tasked with cleaning up stale records. The tool accepts a boolean: softDelete: true. The agent calls the tool with softDelete: false because the prompt didn't specify. The record is gone.
The OWASP Top 10 for LLM Applications catalogs this under Excessive Agency. The agent had too much power and the wrong context. Pre-action authorization catches this at the tool boundary: "This tool call asks for hard delete. Policy says soft delete only. Deny."
The prompt injection that rewrites your agent's instructions. Simon Willison called this the "lethal trifecta" for AI agents in June 2025: access to private data, exposure to untrusted content, and the ability to communicate externally. A customer email contains hidden instructions telling the support agent to transfer the entire account record to an external webhook. The agent reads the email, sees the instruction, and makes the call. Pre-action authorization intercepts: "This tool call targets an unapproved endpoint. Deny."
The runaway cost loop. An agent enters a retry loop calling a paid API. Nothing in the loop knows how much it has spent. Cost governance at the tool boundary catches it on the first retry over budget: "Spend limit exceeded for this agent. Block until reset."
What pre-action authorization looks like
The pattern is borrowed from fintech and identity infrastructure. It is the same principle behind Chimoney's compliance stack, applied to AI agents.
At minimum, you need:
| Capability | What it does |
|---|---|
| Call interception | Every tool call routes through a guardrail layer before execution |
| Policy evaluation | Match the call against rules: who, what, where, how |
| Risk scoring | Flag calls above a risk threshold for approval |
| Context-aware checks | "This agent was asked to read file X. Is file X in its scope?" |
| Rate limiting | X calls per minute, Y total spend per hour |
| Approval gates | Human-in-the-loop for high-risk actions |
| Audit trail | Every denied and approved action logged with agent identity |
This is not new architecture. It's applying the security pattern we already use for APIs (API gateways, WAFs, rate limiters) to the agent execution layer.
The difference: API security validates requests from external users. Agent security needs to validate actions from an internal semi-autonomous actor that can be influenced by its inputs.
The biggest thing people get wrong
They think prompt engineering is a security control.
It isn't. A prompt is a suggestion. A policy is an enforcement point.
Teams ship agents into production with elaborate system prompts that say "never access financial data" and consider that done. The agent ignores the prompt, accesses financial data, and the team finds out from the audit log, if there is one.
If you're relying on the model to follow an instruction that contradicts its primary task (help the customer), you don't have security. You have a hope.
Pre-action authorization makes the model's compliance irrelevant. The guardrail fires at the tool boundary regardless of what the model decided to do. The model can try to call the tool. The guardrail decides whether the tool call actually happens.
Where this sits next to IAM and prompts
- Not an alternative to traditional access controls. IAM still matters. Least privilege still matters. This sits at a different layer.
- Not a replacement for responsible prompt engineering. Good prompts + good guardrails = better than either alone.
- Not a solved problem. The industry is early. Standards are emerging. Tool-specific guardrails need different evaluation logic depending on the tool.
It is the direction the industry is moving. O'Reilly's stack confirms it. Check Point's report quantifies the gap. The OWASP Top 10 for LLM Applications catalogs the failure modes. The question is no longer whether to add pre-action authorization. The question is how.
The same pattern that works for payments
I spent years building fintech infrastructure at Chimoney: KYC, KYB, transaction monitoring, compliance limits. We had to check every payment against rules before it left our system. We could not rely on "the developer will write good code" or "the prompt will be clear enough." We needed deterministic enforcement at the execution boundary.
AI agents are in the same place now. They can move money, change records, delete data, send communications. The stakes are real. Check-before-execute is the pattern that held up for payments, and it is the pattern that will hold up for agents.
The 77/26 gap from Check Point's report is not permanent. The organizations that close it fastest will be the ones that build pre-action authorization into their agent infrastructure from the start, as a running enforcement layer that fires on every single tool call. Go find out which side of the 26% your agents are on.