How to Secure Your AI Agent Stack

Key Takeaways

• Gartner predicts 25% of enterprise GenAI applications will experience at least five minor security incidents per year by 2028.

• Forrester named AI agent threats the dominant new cybersecurity risk category for 2026, with personal agents operating as shadow operators outside security governance.

• Two distinct classes of security controls exist: behavioral controls and infrastructure controls.

• The security boundary is effective only if every action crossing it passes through an enforcement point.

OpenAI, Anthropic, and the UK AI Security Institute each recently reported frontier agents operating beyond their intended boundaries.  

The reported behaviors included exploiting unexpected paths to the open internet, gaining unauthorized access to other organizations' systems, and taking unsanctioned actions involving people and infrastructure.  

Science fiction talks a lot about AI “going rogue,” but that’s not what happened in these instances.  

What really happened was that the capabilities that enabled those AI agents to solve problems also helped them find paths that their original instructions did not anticipate.

So how can organizations keep their AI tools corralled? Let’s take a look.

What Makes AI Agent Security Different

Securing an AI agent stack does not require reinventing security. Enduring principles from decades of systems security practice still apply: Least privilege, defense in depth, isolation, explicit authorization, and auditability. The challenge is knowing where to apply them in an agent stack.

Prompts, model safeguards, and harness logic influence what an agent might do, but they don’t impose limits on what it can do. What’s needed are behavioral controls for the former and infrastructure controls for the latter.

Behavioral controls shape what an agent is likely to do. The model and agent suggest actions to achieve a goal. The harness steers those actions toward the intended behavior. All three elements work together to interpret goals, clarify instructions, and propose actions.  

Infrastructure controls form the environment in which the agent runs and determine what it can do. They maintain identity, enforce policy, contain failures, record what happened, and reach the same authorization decision every time as determined by the approved policy and verified state. Both types are necessary, but only the infrastructure controls have authority.  

Too often, teams building behavioral controls believe they have created guardrails when all they’ve really implemented is policy guidance. They discover the difference when an agent encounters an edge case, processes an adversarial input, or accumulates permissions across sessions that were never individually authorized.

It’s important to note, however, that infrastructure controls are only as good as the policy and state. The approved policy and verified state produce repeatable outcomes, and the agent has to comply. If the policy and/or state is wrong, the outcomes may also be wrong.

For organizations designing architectural controls to enforce this separation, Taazaa's guide to securing agentic AI covers permission frameworks, guardrail architecture, and human-in-the-loop design that distinguish safe deployments from exposed ones.

Establishing a Security Boundary

If the behavioral controls are the top layer and the infrastructure controls are the bottom layer, the security boundary is the layer between them. Every action that changes external state must cross this boundary. Any path that bypasses it is an architectural defect.

Three requirements make the boundary effective:

• Treat every component above the boundary as potentially untrusted. It may be mistaken, compromised, or adversarial.

• Make controls below the boundary authoritative. They bind each request to an identity, apply policy, and enforce the decision.

• Use risk signals only to reduce authority, never to grant additional access.

The most common flaw across enterprise agent stacks is that authorization decisions can be influenced by the agent or by untrusted data the agent reads. Documents, messages, tool results, and memory can redirect agent actions without being authorized as instructions. In multi-agent systems that share memory and delegate to peers, a successful injection can trigger a rapid cascade.

Six Common Security Gaps in Agent Stacks

Most enterprise agent stacks share similar vulnerabilities. NVIDIA's security research identifies six that appear consistently across deployments.

1. Unclear boundaries. Rules are split across prompts, models, harnesses, and infrastructure. The authoritative version is hard to find and harder to audit.

2. Excessive access. Agents are granted greater credentials or permissions than the task requires. These credentials often persist longer than necessary.

3. Untrusted data as control. Documents, tool results, and memory can redirect actions without being authorized as instructions.

4. Uncontrolled external effects. An allowed API call can move data or trigger effects outside intended controls.

5. Compounding failures. Agents delegate and share memory, allowing a mistake to propagate across a multi-agent pipeline.

6. Incomplete audit evidence. Approvals are vague, access is slow to revoke, and the record isn’t complete enough to provide adequate traceability or support recovery efforts.

Gartner predicts 25% of enterprise GenAI applications will experience at least five minor security incidents per year by 2028. Permissions for AI agents must be tightly scoped to the task, not inherited from human user roles.

Five Design Rules for Enforceable Security

Enforceable security requires keeping security decisions outside the agent's control. NVIDIA's security research identifies five design rules. Taazaa sequences these deliberately in delivery, governance design and identity architecture come first, tooling selection second. Organizations that reverse this sequence consistently discover their tooling cannot enforce the governance model they designed after the fact.

1. Above proposes; below decides. No model, agent, harness, tool, or memory system can confer authority on itself.

2. Authoritative policy stays below the boundary. Advisory policy above the line is useful guidance. It is not a security control.

3. Check every effect. Every file, process, network request, API call, data operation, and device action must be controlled.

4. Just-in-time access. Credentials should be narrow, short-lived, and easy to remove. IBM's 2025 Cost of Data Breach Report found that 97% of organizations that suffered AI-related breaches lacked proper access controls.

5. Isolation and recovery. Isolate each agent, rapidly revoke access, recover, and preserve a complete record of the incident.

Of these five rules, just-in-time access is the one that creates the most friction in real delivery. Most enterprise identity and access management (IAM) systems were designed for human users with persistent roles. Issuing narrow, short-lived credentials for non-human agent identities requires either a dedicated secrets management layer or a significant IAM redesign. Teams that defer this work typically end up granting agents standing credentials scoped to a human role, which means a compromised agent inherits the access of whoever provisioned it.  

Four Security Profiles for Agent Workloads

Not all agent workloads carry the same risk. NVIDIA's security framework defines four profiles applying progressively stricter controls.

Level 1: Isolated  

• Typical work: Does pre-production work using disposable data.  

• Configuration: No production credentials, restricted network, session recording.

Level 2: Connected

• Typical work: Does pre-production work using approved services.  

• Configuration: Short-lived identity, masked data, rate and spend limits, full logging.

Level 3: Production  

• Typical work: Makes changes to live systems or data.  

• Configuration: Task-scoped access, independent checks, human approval for high-impact actions.

Level 4: Adversarial  

• Typical work: Performs frontier-model, non-restricted, or red-team runs.  

• Configuration: Default-deny communications, automatic quarantine, strongest isolation. For red-team agents, production access should be more restrictive than access granted to ordinary production agents.

The same security boundary and enforcement interfaces apply across all four profiles. What changes is the strictness of controls based on the authority granted and the potential impact.

As risk increases, five areas must strengthen: narrower authority with shorter-lived grants, fresher policy decisions closer to each action, live supervision for high-impact work, faster access revocation and rollback, and immutable records kept below the security boundary.

Taazaa's breakdown of agentic AI design patterns covers how these security profiles map to specific workflow architectures, and which failure modes each pattern is designed to prevent.

Security Requirements That Hold at Every Level

Regardless of security profile, four requirements must remain consistent across every deployment.

• The agent never grants itself access. Controls are enforced outside the agent process, beyond the agent's control.

• Every high-impact action crosses an enforcement point. The check occurs in the system that performs the action, not in the agent that requests it.

• The system fails safely. A missing or stale control selects a preapproved safer state.

• Security claims stay scoped. State the exact paths covered, assumptions made, and what falls outside the stack.

What Enforcement Looks Like in Practice

Taazaa's Safeguard AI deployment for a mortgage field services company demonstrates enforcement-first security design in a production AI workflow.

The platform processes vendor work orders through six defined stages. At each stage, role-based access controls are enforced at the infrastructure layer. The agent accesses only the data and systems required by its specific task. Every state transition and tool call is logged immutably below the agent's control. Human approval gates govern any action exceeding defined risk thresholds. When something goes wrong, the audit trail can be walked back without engineering interpretation.

This is what the five design rules look like when applied before deployment rather than retrofitted after an incident. The governance design came first: permission boundaries, audit architecture, and human approval thresholds were defined before any agent ran. The tooling was selected to enforce that governance model, not the other way around. The result was an 80% reduction in payment cycles and 98.24% accuracy compared to human audits.  

For organizations building evaluation and monitoring infrastructure that makes enforcement observable after deployment, Taazaa's guide to agentic AI evaluation covers the three-level evaluation framework that surfaces security failure modes before they reach users.

Security Must Come First

Security controls retrofitted after deployment are consistently more expensive and less effective than controls built in before the first agent runs.

A control that the agent can decline to invoke is not an effective security control. If the runtime boundary is established after the harness is already running, the harness can choose whether to use it. That’s not an effective boundary.  

Forrester named AI agent threats the dominant new cybersecurity risk category for 2026. The threat is not primarily from external attackers. It is from enterprises deploying agents with machine-speed data access and no governance framework designed to see them.

Frequently Asked Questions

What is the difference between behavioral and infrastructure AI agent security controls?

Behavioral controls guide what an agent tries. Infrastructure controls determine what an agent can do. Both are necessary, but only infrastructure controls are authoritative. A behavioral control that the agent can bypass is not a security control.

What is just-in-time access for AI agents?

Credentials and capabilities scoped to the specific task being performed: narrow, short-lived, and revoked when the task is complete. IBM's 2025 research found shadow AI incidents with standing access add an average of $670,000 to breach costs.

What are the four security profiles for AI agent workloads?

Isolated (pre-production, no production credentials), Connected (approved services, short-lived identity), Production (live systems, task-scoped access, human approval for high-impact actions), and Adversarial (frontier models, default-deny, automatic quarantine).

What security requirements should be maintained at every risk level?

The agent never grants itself access. Every high-impact action crosses an enforcement point. The system fails safely when a control is missing. Security claims are scoped to the exact paths covered.