Defending the model from external attack is necessary. But let's be clear: it isn't sufficient.
The bigger risk for agentic AI is what the agent does once it's inside the enterprise: what it reads, what it acts on, what it decides without leaving a trace. NIST's January 2025 red-team research found that novel attack strategies against AI agents achieved an 81% success rate in red-team exercises, compared to an 11% baseline – and the regulator has already identified the security architecture, not the model, as the layer that needs new controls.
The standards meant to govern that layer haven't shipped yet. Most enterprise programs haven't built for it either.
NIST Has Already Identified the Real Problem
In February 2026, NIST's Center for AI Standards and Innovation launched its AI Agent Standards Initiative. The NCCoE published a concept paper on agent identity and authorization the same month.
The framing in that paper is clear. The problem isn't a weak model. It's that an agent "can access enterprise resources or trigger operational actions, [and] a successful prompt injection attack could cause the system to retrieve sensitive data or execute unintended commands." The proposed answer is identity, authorization, and access controls applied to the agent itself.
This is exactly the problem CISOs are seeing in production. An agent that can search enterprise data, call enterprise tools, and act on behalf of users without inheriting their permissions is an architectural risk, not a model risk.
NIST has named the problem; yet the standards aren't ready. The EU AI Act's Article 26 obligations for high-risk systems take effect on 2 August 2026. Enterprises operating in the EU have weeks, not quarters, to show their agents meet a bar the regulator has started defining.
In other words, the architecture has to be in place before the guidance ships.
The Real Risk: What the Agent Reads, What It Does, What It Decides
The risks worth architecting against split into three categories. Each one is a different kind of failure, and each one needs its own bound.
Unbounded retrieval. An agent that can search across enterprise data without inheriting the user's access permissions becomes a way to surface documents the user couldn't otherwise see. The retrieval layer doesn't know the user is on the wealth team and shouldn't see the legal team's contracts. It returns what's relevant, not what's permitted.
Unauthorized action. Agents that can call tools – Salesforce, ServiceNow, SAP, internal APIs – can take actions the underlying user wasn't entitled to take. A junior analyst's query becomes an agent's tool call, and the tool call inherits whatever permissions the agent itself was provisioned with. Without per-action authorization, the agent's privileges become the user's privileges by accident.
Untraceable decisions. An agent that reasons across documents, calls a tool, and produces an answer needs to leave a trail an auditor can read. Most architectures log the prompt and the response. They don't log the retrieval, the reasoning, the intermediate tool calls, the human override, or the policy that approved the action. When the audit comes, "the agent did it" is not an answer.
These three failure modes are the actual security surface of agentic AI inside the enterprise. They're not perimeter problems. They're architecture problems.
The Three-Layer Framework for Defensible Agent Security
A defensible agent security architecture bounds retrieval, action, and decision in three separate layers. Each layer answers a different question a regulator or auditor will eventually ask.
Layer 1: Retrieval Bounded by Access Controls
The agent's view of enterprise data has to inherit the user's permissions, every time, automatically. This means access control lists embedded directly into the retrieval layer, not bolted on after the fact. When the agent searches the corpus, it sees only what the user is entitled to see.
The retrieval also has to be deterministic. The same query produces the same result, traceable back to the same source documents. A retrieval layer that returns different answers to the same question can't anchor a security claim, because the audit can't reproduce the conditions of the original decision.
Layer 2: Action Bounded by Policy
When an agent calls a tool, the call has to pass through a policy layer that knows what the user is authorized to do, what the agent is authorized to do on the user's behalf, and what actions require human approval before execution.
This is where AI guardrails do their work. The guardrail layer validates the action against role and governance policy before the action is taken. Workflows are modeled as explicit graph entities using standards like BPMN 2.0, so the path the agent took through the workflow is itself an auditable artifact – not a reconstruction from logs.
The human-in-the-loop is part of the architecture, not an afterthought. Edge cases are routed to a human supervisor for review, and the supervisor's choice is itself logged as a decision with attribution.
Layer 3: Decisions Bounded by Audit
Every API call, prompt, retrieval, tool invocation, guardrail check, and human decision is captured in an immutable, time-stamped log. The chain of custody is complete enough that any agent action can be reconstructed end-to-end – what the agent read, what it did, what the policy said, who approved the edge case, what the final output was.
This is the layer that turns regulatory conversations from defensive to evidentiary. The auditor doesn't ask whether the architecture is trustworthy. They ask to see the log for case number 4,372. Either the log produces the answer, or it doesn't.
Where the Architecture Has to Sit
The deployment model matters. For agents operating on regulated data – central banking, supervisory functions, healthcare records, sovereign wealth portfolios – the architecture is often required to support on-premise deployment, as data sovereignty is a common regulatory requirement and, in many cases, a procurement gate.
On-premise deployment means the entire stack – retrieval, agent framework, audit logs, guardrails – runs inside the institution's own infrastructure. No data crosses a vendor boundary. No prompt is sent to a public inference endpoint. The institution controls the keys, the network, and the audit.
For environments where on-premise isn't required, virtual private cloud deployments are available, with the same architectural guarantees. The choice of deployment model shouldn't change the security posture of the agent – it changes where the architecture runs, not what it does.
The platform's certification posture sits alongside this: ISO 27001 and SOC 2, the baseline enterprises in regulated industries expect.
What the CISO Walks Into the Board With
The board conversation about agent security is shifting from can we deploy this to can we defend this when the regulator asks. The framework that survives that conversation is the one that bounds retrieval, action, and decision in separate layers and produces evidence at each one.
NIST's red-team work and forthcoming agent-specific controls will continue to harden the perimeter. The CISO already has a program for that part of the problem.
The internal threats – what the agent reads, does, and decides – are the part the existing security program wasn't built for, and they're the part that's going to determine whether agent deployments survive the August 2026 EU AI Act enforcement deadline.
The CISO walking into the board with the three-layer framework isn't asking for a budget to defend against an external threat. They're presenting the architectural standard the regulator is about to require. That's the case worth making before August.
