Recent headlines about AI agents escaping their test sandboxes, along with warnings about how fast AI capability is advancing, have added to a broader conversation about how to deploy AI agents safely. The key takeaway: Agents currently cannot reliably govern their own behavior, so enforcement has to sit outside of them via a combination of deterministic and probabilistic controls at different levels.

The good news is that there are things you can do about it. This post goes over five patterns that make agentic systems meaningfully safer, shown in the graphic below. Some are AI-specific, like guardrails and scoped tools, while others are traditional controls that kept systems safe before LLMs and are now more important than ever. Together, these measures form the defense-in-depth foundation:

1. Choose a Deployment Type That Fits the Agent’s Use Case

One of the most consequential decisions is where the agent is deployed and which model it uses. That choice informs how users will interact with the agent, what it can connect to and which controls come built in versus which you’ll need to add yourself. A few questions help narrow it down:

• What data will the agent handle, and where is it allowed to go? This drives the choice of model and who hosts it.
• What systems does it need to reach? Databases, internal APIs and file shares help determine where the harness should run.
• Who will use the agent? A public-facing chatbot and an internal tool for a small team require very different protection at the edge.
• What platforms do you already run? Existing cloud or data platforms (AWS, Azure, Snowflake, Databricks) often narrow the options fastest.

There’s no one right answer. The deployment type and model should be tailored to these factors. Here’s how the most common options compare:

2. Guard What Goes In and Out of the System (Web App Security and AI Guardrails)

A lot of agents are used behind a web interface of some kind (think public-facing chatbots or internal portals). AI agents are not like traditional applications, but they often are exposed in the context of a web app. As a result, the same “old” web security measures can be used on the front line to validate input, enforce rate limits, authenticate users at the edge and filter traffic. This is a crucial first line of defense that can stop malformed input before it is sent to the backend.

Traditional web application protections, however, were not created for agentic applications, so they are not suitable to protect against AI-specific threats like prompt injections, jailbreaks or discussion of forbidden topics. This is where AI guardrails come in.

The risk of prompt injection arises because of how LLMs process input, namely as a single stream of text. The model cannot reliably distinguish trusted instructions on how the agent should behave from untrusted content, such as user input or retrieved documents, that may contain malicious instructions. Guardrails inspect the text going into and out of the LLM and, when something looks wrong, block it, redact sensitive parts or flag it for review. Guardrails can be employed in different places in the agent’s architecture and can filter:

• The user’s input: to guard against malicious input.
• Retrieved documents and tool responses: these can carry injected instructions.
• The agent’s output: to catch sensitive data leaks or exfiltration.

Some guardrails draw from databases with known injection patterns, while others use a smaller classifier model to judge intent. Options here include open-source frameworks like NVIDIA’s NeMo Guardrails, classifier models like Llama Guard and managed services like Amazon Bedrock Guardrails.

Guardrails reduce risk, but they are probabilistic. No filter catches every injection, which is why the deterministic controls in the next sections matter. Next, we’ll discuss what happens once the prompt does make it through and the agent decides what to do next.

3. Restrict What the Agent Can Do (Scoped Tools and IAM for Agents)

Agents get their immense utility from tools, which allow the agent to actually do things like access external data, modify files or run code. Because tools are so powerful, it is important to scope them appropriately and to run a set of checks on every tool call:

• Who is asking? (Identity) Workload identity lets the agent prove who it is in a verifiable and governed way without long-lived stored secrets. Instead, credentials should be short-lived and pulled from a vault or injected by a proxy.
• Is the call allowed? (Authorization) Every call gets checked against policy, which either denies it, allows it or asks a human. This check can take place in the agent harness as hooks and permission rules, or it can be implemented in a gateway in front of the tools with a policy engine such as OPA or Cedar.
• Human sign-off needed? High-impact actions like deleting records should require human approval. If any check fails or can’t be reached, the call stops: the design should fail closed, not open.

For the tools themselves: Give the agent the narrowest tool that still does the job. MCP servers and skills should be approved centrally at the org level, allowlisted per agent and pinned to a version, with third-party ones treated as untrusted code. More generally, there should be a cap on the number of loops an agent can execute to prevent runaway behavior and cost.

4. Contain the Agent (Sandboxes and Network Controls)

Guardrails and tool restrictions are not a catch-all, and if the agent does get manipulated, the next question is what resources and services it can reach. This is the job of sandboxes and network controls, which are critical to any agent setup. First off, the sandbox is meant to isolate the agent in an environment that is largely closed off from other systems. Here too, there are options that provide different levels of containment:

As a general practice, sandboxes should be ephemeral, so nothing survives the session, while memory and session state live in a separate store and are treated as untrusted when loaded back in.

Even inside a sandbox, a manipulated agent can still make network calls. If it escapes the sandbox, any rules set inside it no longer apply. That is why network controls should be enforced outside the sandbox, at the host, the network or a proxy. These deterministic rules act as the hard boundary that prevents an agent from reaching unauthorized hosts (data can still leave through the hosts you do allow, which is why the other layers matter).

Employing a default-deny on egress traffic is a good place to start, where only the specific hosts the agent needs are allowlisted. An agent shouldn’t have open internet access unless its job requires it. One way to implement controls for outbound traffic is via an egress proxy. Here, all outbound traffic goes through one choke point that inspects TLS traffic, checks the allowlist and injects credentials when needed:

The agent should also not be able to query DNS directly, as data can be exfiltrated via DNS lookups. Instead, the proxy or a controlled resolver can handle name resolution.

Inside your own network, network segmentation plays an important role in isolating the agent from other systems and controlling east-west traffic.

The same concept applies between agents. When agents run as separate services, allow only the agent-to-agent connections that are actually required. When sub-agents run inside the same harness, the boundary is a bit different and relies on permissions instead. Either way, treat messages from other agents as untrusted, so one compromised agent can’t take over the rest.

5. Log Every Action the Agent Takes (AI Observability)

Every control addressed so far produces some type of decision: A guardrail flags a problematic prompt, a policy denies a tool call, the egress proxy blocks a request. Logging these decisions lets you investigate incidents and see how the implemented controls actually behave. A trace links everything an agent did in one run, so you can follow a single request from prompt to final answer with any tool call that occurred in between. Because logs can contain sensitive info, apply redaction and retention rules, and ensure the agent cannot reach them.

Many agent frameworks already emit traces via OpenTelemetry that can be sent to a SIEM or data platform. If your data lives on Databricks or Snowflake, their native tracing (MLflow Tracing in Databricks and Snowflake’s AI Observability) lets you query traces alongside business data and govern them like any other table.

Putting It Together

Agents can’t keep themselves in check yet, so the system around the agent has to, with defenses across different layers. Applied well, the patterns above make agents safer without giving up what makes them useful. The new AI-specific measures and the security fundamentals you already know work best together, each catching what the other misses. These patterns are a good starting point, but the right configuration depends on what your agents need to do.

If you’re thinking of building agents or are already running them, we’d be happy to help you figure out where you stand. Just reach out.