The conversation about AI agent security has been dominated by the wrong question.
For the last two years, most of the energy in this space has gone into making AI agents say the right things. Guardrails. Output filters. Prompt sanitization. System instructions that tell the agent what it is not allowed to do. The implicit assumption behind all of it is that the risk lives at the language layer - in the outputs an agent produces, the content it generates, the responses it returns.
That assumption is now definitively wrong. Incident data from the last six months explains why.
The problem has moved from prompt hygiene to access architecture. The risk is not what agents say. It is what they do - with authorized access, through legitimate tool calls, in ways that no output filter was designed to evaluate.
What Every Layer of the Current Governance Stack Is Actually Governing
Before explaining what needs to change, it is worth being precise about what the current governance stack actually does. Each layer is doing its job correctly. The problem is that none of them are doing the right job for AI agents.
Guardrails moderate outputs. They have no visibility into the tool calls the agent made, or whether those tool calls were consistent with what the agent was built to do.
IAM secures endpoints. It governs the permission boundary. It does not govern what the agent does within that boundary once access is granted.
SIEM logs events. It tells you when something anomalous occurs relative to historical baselines. It does not evaluate whether a tool call that looks exactly like legitimate agent activity is actually consistent with the agent's organizational intent.
Logging preserves the record. It tells you what happened after it happened. After the consequences are irreversible.
Every layer of the current stack is evaluating the wrong thing. None of them answer the question that matters: is what this agent is doing right now consistent with what it was built to do?
The Proof That This Gap Is Being Exploited
The GhostJacking research presented at DEF CON 34 is the clearest demonstration yet of exactly this gap.
Security researchers achieved a 90% success rate against Claude Code on Cloudflare's own recommended configuration. No malicious code. No unusual network traffic. No anomalous API calls. No detected security alerts.
The attack worked by embedding malicious instructions in security log files that an AI coding agent routinely reads as part of its legitimate investigation workflow. The agent read the logs, treated the embedded instructions as commands, and used its legitimate, authorized access to modify DNS settings, execute code, and pass the poisoned conclusions to downstream agents.
The guardrails did not stop it because the agent's outputs were not the problem. The IAM controls did not stop it because the agent's credentials were valid and its permission scope was correct. The SIEM did not flag it because the tool calls were identical to legitimate agent behavior. The logs recorded everything after the damage was done.
This is not a failure of individual security controls. It is a structural demonstration that the entire governance stack was built for a different class of actor. Every control evaluated whether the agent had permission to act. None of them evaluated whether the agent should be acting, given the specific instruction it just received from a potentially compromised source.
The 82% of executives who told Beam AI their existing policies already protected them from unauthorized agent actions were looking at a governance stack that worked correctly for traditional software. For AI agents, it was governing the wrong layer entirely.
The Architectural Shift the Market Is Starting to Recognize
Deloitte published a paper in August 2026 that names the architectural answer: the Agent Action Enforcement Layer, or AAEL.
The definition is worth quoting precisely: a structured, pre-execution mechanism for understanding, evaluating, and controlling the actions that AI agents propose to take across applications, cloud environments, and multi-agent ecosystems.
Three words in that definition carry the weight of the entire architectural argument: pre-execution mechanism.
Not post-execution logging. Not real-time alerting. Pre-execution evaluation, a control point that operates between the agent's decision to act and the system it is about to act on.
This is the architectural shift that the current governance stack does not provide. Guardrails operate at the output layer, after the tool calls have completed. SIEM operates at the analysis layer, after the events have been recorded. Logging operates at the preservation layer, after the actions have been taken. None of them operate at the decision layer, before the action executes.
The AAEL architecture introduces a control point at exactly the right place: between intent and execution. The agent forms a plan. The enforcement layer evaluates the plan against policy before the plan becomes action. If the plan falls outside the authorized scope, the enforcement layer can constrain it, modify it, escalate it for human review, or block it - before any action reaches the target system.
Deloitte frames this as providing action-level visibility and policy-aware evaluation. The policy it's measured against is the organizational intent defined for each agent: what it was built to do, what systems it is authorized to reach, what data it should handle, and what actions fall within its declared mandate.
This is not a new type of firewall. It is not a more sophisticated SIEM rule. It is a different governance layer entirely, one that governs the decision, not the output; the action, not the log.
Why This Requires Identity as the Foundation
The AAEL architecture is the right answer. But it cannot function without identity as the prerequisite layer.
Policy-aware evaluation requires a policy to evaluate against. For an enterprise AI agent, that policy is the organizational intent that was defined when the agent was provisioned - the structured, machine-readable specification of what the agent was built to do. Without that specification, the enforcement layer has no baseline to evaluate against. It can flag statistical anomalies. It cannot evaluate intent consistency.
This is the sequencing argument that most enterprises get wrong. They deploy behavioral monitoring before they have established behavioral baselines. They try to detect drift before they have defined what the non-drifted state looks like. They implement enforcement before specifying what to enforce.
Identity and organizational intent capture have to come first. Not because identity is more important than runtime enforcement - they are both necessary - but because runtime enforcement without an intent baseline produces noise rather than governance. The enforcement layer evaluates actions against a standard. The standard is organizational intent.
Identity is the layer that establishes it.
Sysdig's 2026 prompt injection analysis makes the same structural argument: architectural patterns that limit what an agent can do regardless of what it is instructed to do constrain the consequences of a successful injection rather than preventing the injection itself.
Constrain the consequences. That is the pre-execution enforcement argument. Not "prevent every attack" - which the GhostJacking research demonstrates is not reliably achievable at the input layer - but "ensure that even a successfully injected instruction cannot cause the agent to act outside its authorized scope.
The combination of scoped organizational intent and pre-execution enforcement is what makes the AAEL architecture work in practice. At aizome, that means the MCP gateway sitting between agents and enterprise systems, organizational intent established at provisioning, and per-action evaluation before each tool call reaches the target system.
Not a monitoring layer that observes what agents do. A control layer that evaluates what they are about to do - before they do it.
The problem has moved from prompt hygiene to access architecture. The governance stack needs to move with it.
Chen Pipek is CPO and Co-Founder of aizome, an Enterprise AI Agent Identity Fabric Platform. He previously co-founded and led AxoniusX within Axonius and has held product and security leadership positions for over 20 years.
