Security for AI Agents
in Production

Why AI agents are a new security surface

Traditional software executes deterministic code written by your engineers, reviewed in a PR, tested in CI, and deployed through a controlled pipeline. You know exactly what it will do because a human wrote every line.

AI agents are different. They execute LLM-generated code — code that didn't exist until the model produced it at runtime. They make autonomous decisions about what commands to run, what APIs to call, and what data to process. They interact with external systems (websites, portals, APIs) that can contain adversarial inputs designed to manipulate the agent's behavior (prompt injection).

This isn't hypothetical. In 2025, researchers demonstrated prompt injection attacks that caused AI agents to exfiltrate environment variables, execute unauthorized commands, and bypass safety filters — all through carefully crafted content on webpages the agent visited. The OWASP Top 10 for LLM Applications lists prompt injection as the #1 risk.

The response isn't to avoid deploying AI agents. It's to deploy them with the right security architecture. The same way you don't avoid deploying web applications — you deploy them with firewalls, WAFs, input validation, and least-privilege access.

The five questions your security team will ask

1. "What's the blast radius if an agent is compromised?"

Answer: a single disposable sandbox. Every agent runs in its own isolated environment — its own VM (EC2) or its own container (cloud). It cannot see other agents' filesystems, processes, or network traffic. If compromised, the worst case is destruction of that one sandbox. The agent cannot laterally move to other sandboxes, to the platform infrastructure, or to your production systems (unless you explicitly gave it network access to those systems, which is controlled by egress rules).

Compare to running Claude Code on an engineer's laptop: the blast radius is the engineer's entire machine, credentials, and network access.

2. "Where do credentials live?"

Answer: they don't live. They visit. Credentials are injected at runtime and expire after the task. SSH access uses short-lived certificates (1–4 hour TTL). API keys are fetched from a secrets manager when the sandbox boots and are scoped to the minimum permissions the task requires. Vendor portal passwords are injected as environment variables, used, and destroyed when the container is released.

Nothing is stored on disk permanently. The ephemeral containers don't have a ~/.ssh/id_rsa sitting around. The persistent sandboxes use certificates that expire before anyone could exploit a leaked key.

3. "Can the agent send data to external systems?"

Answer: only if you allow it. Egress control is configurable per sandbox via security groups. For agents handling sensitive data, restrict outbound traffic to an explicit allowlist: the model API (api.anthropic.com), your internal endpoints, and nothing else. A compromised agent that tries to curl data to an external server gets a connection refused.

For agents that need internet access (web research, competitive intelligence), the tradeoff is explicit. You're choosing broader network access in exchange for the agent's ability to browse. The other controls (isolation, ephemeral credentials, audit logging) still apply.

4. "Is there an audit trail?"

Answer: every action, every timestamp, every user. The platform logs sandbox creation, command execution, file uploads/downloads, container lifecycle events, and API calls. Each entry includes: who triggered the action, when, what resource was affected, and the full details (command text, response code, file name). The log is immutable and exportable to your SIEM.

For desktop and browser containers, session recordings provide visual audit: a video of what the agent saw and did, stored alongside the task output. SOC2 auditors can replay exactly what happened.

5. "What happens when an agent goes rogue?"

Answer: the architecture contains it. Walk through the scenario: a prompt injection on a scraped webpage tricks the agent into attempting data exfiltration.

1. Egress control blocks the request (destination not in allowlist). Data stays in the sandbox.
2. Audit log records the attempted command, including the target URL.
3. Alert fires on the blocked egress attempt. Security team is notified.
4. Credentials expire within hours regardless.
5. Sandbox is destroyed after the task, eliminating any persistence.

Worst case: the agent wasted 5 minutes of compute on a failed attempt. No data left the sandbox. No credentials were compromised. The incident is logged and alerted.

The six security layers

Defense in depth. No single control is sufficient. All six work together.

Compliance mapping

The security case for the platform (vs no platform)

The alternative to running AI agents on a managed platform isn't "no AI agents." It's "AI agents running on engineer laptops with zero controls." That's the actual threat model your security team should worry about.

The managed platform is strictly more secure than the unmanaged alternative. Every security property improves. The conversation with your security team should be: "We're already using AI agents. The question is whether they run on laptops with no controls, or on a platform with six layers of defense."

The security review checklist

Give this to your security team before the review meeting:

1. Compute isolation: each agent runs in its own EC2 instance or cloud container. No shared compute. Verified by VPC and security group configuration.
2. Credential management: short-lived SSH certificates (1–4 hr TTL), scoped API keys fetched at runtime, no static secrets on disk.
3. Network control: egress rules configurable per sandbox. Sensitive workloads restricted to allowlisted endpoints.
4. Audit logging: immutable log of every action. Exportable to SIEM. Includes user identity, timestamp, action, resource, and details.
5. Session recording: video capture for desktop/browser containers. Screenshot archive for every step.
6. Ephemeral default: sandboxes and containers destroyed after task completion. No persistent state beyond the task window.
7. Spending caps: per-user limits prevent a compromised account from provisioning unlimited resources.
8. Emergency termination: any sandbox can be killed via API in seconds.
9. Compliance: SOC2 (CC6, CC7, CC8), GDPR (Art. 5, 17, 25, 30, 32), HIPAA (164.312) patterns documented.

What's next