Beyond model guardrails, part 1: containing the agent

Building the enterprise control plane for AI agents

AI agents are beginning to occupy a fundamentally different position inside the enterprise.

A conventional chatbot receives a question and generates an answer. But an agent may retrieve internal files, invoke APIs, execute code, create tickets, modify repositories, interact with cloud services or coordinate other agents. And it may operate through an approved service account, an employee's identity, OAuth tokens, cloud roles or credentials exposed through tool integrations.

This exposure to sensitive resources and the ability to take actions change your security strategy significantly.

In When the AI sits inside the perimeter: from cyber capability to AI governance, we examined what happens when increasingly capable AI systems operate through trusted enterprise identities, tools and network paths. While an AI chatbot might give a wrong or even unsafe answer, it can’t take action like an AI agent. The risk comes when that action can be performed through legitimate access that the organization intentionally gave the agent.

The previous post identified a dangerous combination:

untrusted input + trusted identity + privileged capability + insufficient external control

Agent autonomy intensifies that risk by allowing a system to select tools, chain operations, retry failed actions, delegate tasks and pursue a goal at machine speed without requiring a human decision at every step.

How should organizations control that authority?

The answer cannot be limited to system prompts, model refusals, or input and output classifiers. Those mechanisms may influence what a model generates, but they do not independently prevent a valid credential from being used, an authorized API from being called or a destructive operation from being accepted by a production system.

Agentic security therefore requires a control plane outside the model.

The agent is a software principal

A useful starting point is to treat an enterprise AI agent as a software principal rather than as a conversational feature.
Like any other software principal, an agent has an identity, permissions, network access, credentials, tools, data sources, an execution environment and an operational purpose.

Unlike conventional software, however, the agent may dynamically interpret natural-language instructions, reason over untrusted content, select tools at runtime and decide how to complete a task without following a fully deterministic execution path.

In enterprise identity terminology, many agents operate through non-human identities, or NHIs. They may authenticate through service principals, workload identities, API tokens, OAuth applications or cloud roles rather than through an interactive human account.

However, identity is only one part of the agent's security boundary. The model's context, available tools, delegated permissions, network access, execution environment and degree of autonomy determine how that identity can actually be used.

An agent may also operate through several identities during one workflow. It might retrieve documents under the initiating employee's permissions, execute code through a workload identity and invoke an external SaaS platform through a separate OAuth application.

Governance therefore needs to account for the complete identity and delegation chain rather than treating the agent as a single account.

OWASP describes the related problem as excessive agency. The principal causes include excessive functionality, excessive permissions and excessive autonomy. The resulting impact depends on the systems and operations available to the application and can affect confidentiality, integrity and availability. The security objective is to ensure that reasoning cannot redefine authorization, not to prevent the model from running at all.

The model may propose an operation. It should not decide whether that operation is permitted.

Four AI security controls

Successful AI governance requires guardrails. “AI guardrails” is a broad term that encompasses multiple aspects of AI security:

• Model guardrails influence what the model generates or refuses to generate.
• Execution containment limits what agent-controlled code can reach from its runtime environment.
• Authority containment limits what the agent can accomplish through identities, credentials, tools, APIs, MCP servers and delegated permissions.
• Monitoring and recovery limit the consequences when preventive controls fail.

Effective agentic security depends on layering these controls rather than expecting any one of them to become the security boundary. For example:

• A model refusal may stop one dangerous command from being generated, but it does not remove the underlying permission.
• A sandbox may stop generated code from reading the host filesystem, but it will not prevent a valid API credential from deleting a remote database if that operation is allowed.
• A policy engine may stop an unauthorized delete operation, but it does not provide forensic evidence if logging is incomplete.
• An immutable backup may recover lost data, but it does not prevent the incident.

Effective agentic security depends on layering these controls rather than expecting any one of them to become the security boundary.

Start with effective authority

The controls required for an agent should follow what that agent can (or cannot) actually do. For example:

• A public-documentation chatbot does not need the same containment architecture as an autonomous vulnerability-research agent.
• An assistant that reads an employee's email introduces different risks from a coding agent that can execute shell commands.
• A workflow that creates a draft ticket is different from one that can modify production infrastructure.

Security teams should determine whether the agent can access private data, communicate externally, invoke enterprise tools, execute code, modify persistent states, reach production systems, use privileged credentials, delegate to other agents or act without human approval. Every increase in capability should produce a corresponding increase in containment, authorization, monitoring and recovery controls.

The agentic security control plane

The complete architecture can be organized into five connected security planes:

1. Governance and classification
2. Execution and network containment
3. Identity, credentials, tools and MCP
4. Authorization and action safety
5. Input trust, visibility, resilience and recovery

No individual plane is sufficient on its own. For instance, a stronger sandbox cannot compensate for an over-privileged cloud token, nor can an approval workflow compensate for missing logs or unusable backups.

The AI model is only one component of how AI fits into your systems. The model proposes actions; it does not authorize or directly execute them. Understanding how this authorization happens is important to your AI security.

Generated code executes within an isolated runtime path. Enterprise API and MCP operations pass through mediated tool and credential paths. Both remain subject to authorization, network restrictions and independent monitoring.

Audit telemetry should be collected from the context layer, agent, policy enforcement point, policy decision point, approval system, credential broker, sandbox, tool gateway, network controls and destination service.

The architecture is layered to constrain different forms of authority based on the operation performed, which is why it’s crucial to defend all five security planes.

1. Governance and classification

Before an organization can secure its agents, it must know that they exist and understand what authority they possess.

Traditional software inventories often record an application owner, business purpose, hosting environment and data classification.

Agent inventories need to also capture the model, tools, identities, credentials, network destinations, data sources, autonomy level, approval requirements and downstream systems that the agent can influence. A change to any one of these elements may materially change the agent's risk.

Adding a new MCP server, enabling shell execution, expanding repository access, allowing external communication, or replacing read-only access with write access may be more consequential than changing the underlying model.

Governance and classification controls:

Agent inventory

• What it should include: Agent name, owner, business purpose, model, tools, identities, data sources, network reach, autonomy and deployment environment
• When customers should use it: Every enterprise AI deployment
• Why it matters: Organizations cannot govern authority they have not identified

Capability classification

• What it should include: Private-data access, tool use, code execution, write access, production reach, external communication and delegation
• When customers should use it: Before deployment and after every material change
• Why it matters: Determines which technical controls the agent requires

Risk ownership

• What it should include: Named business, technical, data, identity and security owners
• When customers should use it: Every production agent
• Why it matters: Prevents responsibility from becoming distributed across teams

Change control

• What it should include: Review of new models, prompts, tools, MCP servers, credentials, integrations and permissions
• When customers should use it: Whenever effective authority changes
• Why it matters: Small product changes can create new security boundaries

Adversarial testing

• What it should include: Prompt injection, tool abuse, credential harvesting, delegation and production-boundary tests
• When customers should use it: Before deployment and repeatedly afterward
• Why it matters: Tests the deployed system rather than only the model

Retirement and revocation

• What it should include: Disable identities, revoke tokens, remove integrations, terminate sessions and retain required evidence
• When customers should use it: When an agent is decommissioned
• Why it matters: Prevents abandoned agents and credentials from remaining active

The NIST AI Risk Management Framework organizes AI risk-management activities through four functions: Govern, Map, Measure and Manage. The framework is voluntary, but its lifecycle approach is useful.

Its generative AI profile applies that lifecycle structure to generative AI systems and provides a useful basis for assigning ownership, mapping agent capabilities and dependencies, measuring control effectiveness and managing identified risks over time.

Agent governance is not a one-time approval performed before launch; it must continue as capabilities, integrations and operational contexts evolve.

2. Execution and network containment

Execution isolation becomes necessary when an agent can run code, invoke a shell, install packages, process untrusted binaries or launch subprocesses.

A basic implementation might use a rootless container with a non-root user, read-only base filesystem, restricted mounts, dropped Linux capabilities, resource limits and controls such as seccomp and AppArmor.

Kubernetes security contexts support non-root execution, seccomp profiles, AppArmor profiles, restricted Linux capabilities, read-only filesystems and other workload restrictions.

For agents that execute arbitrary or attacker-controlled code, stronger isolation may be appropriate:

• gVisor places an application kernel between the workload and the host kernel, reducing direct exposure to the host system-call interface.
• Firecracker runs workloads inside lightweight microVMs with a separate guest-kernel boundary.

The environment should also be ephemeral. A new container, sandbox, or microVM can be created for each task and destroyed when the task ends. This reduces the risk that one run leaves behind modified configuration, malicious packages, persistence mechanisms, cached credentials or poisoned state that influences later tasks.

Execution and containment controls

Execution sandboxing

• Available implementation options: Rootless containers, seccomp, AppArmor, restricted mounts, gVisor, microVMs or dedicated VMs
• When customers should use it: Whenever an agent executes generated or untrusted code
• What it constrains: Access to the host kernel, filesystem, processes, devices and neighboring workloads

Ephemeral environments

• Available implementation options: New disposable container, workspace or VM for every task
• When customers should use it: Coding, security, research and document-processing agents
• What it constrains: Persistence across sessions and contamination of later tasks

File system boundaries

• Available implementation options: Read-only base image, workspace-only writes, protected configuration, restricted device access
• When customers should use it: Any agent that can write files
• What it constrains: Access to host files, credentials, hooks, workflow definitions and security configuration

Resource limits

• Available implementation options: CPU, memory, process, storage and execution-time limits
• When customers should use it: Autonomous code-execution workloads
• What it constrains: Denial of service, runaway computation and resource exhaustion

Development and production separation

• Available implementation options: Separate accounts, networks, databases, credentials and tool definitions
• When customers should use it: Coding, DevOps, cloud and infrastructure agents
• What it constrains: Movement from a test task into production

Network segmentation

• Available implementation options: Separate namespaces, subnets, security groups and service boundaries
• When customers should use it: Agents that can reach enterprise networks
• What it constrains: Lateral movement and unnecessary internal access

Default-deny egress

• Available implementation options: Destination allowlists, authenticated proxies, DNS filtering restricted internal address ranges
• When customers should use it: Agents processing untrusted content or executing code
• What it constrains: Data exfiltration, arbitrary downloads, command-and-control and SSRF

Sandboxing is essential, but it does not solve every form of agent risk. A sandbox may stop an agent from deleting files on the host, but it will not stop the agent from deleting a remote database through a valid API if its credential authorizes that operation. It may prevent direct access to a developer's home directory but not an over-privileged repository token from reading unrelated private repositories. Or it may restrict local process creation without preventing confidential information from being published through an approved collaboration platform.

Sandboxing controls where agent-controlled code can execute. Authorization controls what the agent can do through legitimate enterprise interfaces.

Enterprises need both execution containment and authority containment.

gVisor's security documentation explicitly notes that a sandbox is not a substitute for a secure architecture. An attacker may not need to escape a sandbox if another accessible service or credential already provides a path to the desired target.

Network access is also a capability

Network access should follow the same least-privilege principle as filesystem access:

• An agent that does not require internet access should not receive it.
• An agent that needs one external API should not automatically receive unrestricted outbound connectivity.
• An agent assigned to development should not be able to reach production networks simply because both environments belong to the same organization.

Salesforce provides an application-level example through its Trusted URL allowlisting for Agentforce. Unapproved URLs can be blocked and represented as URL_Redacted, giving organizations control over links agents call, generate or share.

Destination allowlists are valuable, but they are not complete data-loss controls. A compromised agent may still disclose information through an approved service, public issue, legitimate comment or another authorized communication platform.

Network restrictions therefore need to be combined with data authorization, constrained tools and output controls.

Part 1 conclusion: containment is only the beginning

Execution isolation and network restrictions provide essential boundaries around agent-controlled code, but they do not answer the most important question:

What legitimate authority has the enterprise given the agent?

An isolated process can still cause damage if it can obtain an authorized credential, invoke an overly broad API or connect to a privileged tool.

That makes identity, credential handling, tool design, MCP governance and deterministic authorization the next layer of the control plane.

Part 2 examines how to constrain that authority before an agent's proposed action becomes a real enterprise operation — stay tuned.