How to Audit Your Agent's Security

Most people set up their first AI agent in an afternoon. They give it access to files, hand it some API keys, maybe connect it to the internet. It works. They move on. And they never stop to think about what they just created: an autonomous process with broad system access that executes code based on probabilistic text generation.

That should concern you. Not because agents are dangerous by default, but because the same shortcuts that make them easy to set up also make them easy to exploit or misconfigure. A security audit does not need to be complicated. It just needs to happen.

Why Agent Security Actually Matters

A traditional script runs the same code every time. An agent interprets instructions at runtime, which means its behavior is variable by design. When that variable behavior intersects with real system privileges, the risk surface expands in ways that are not always obvious.

Consider what a typical agent has access to:

• File system access to read and write project files, config files, and potentially anything on the host machine
• API keys and credentials stored in environment variables or config files that grant access to third-party services
• Network access to make HTTP requests, query databases, and interact with external services
• Shell execution to run arbitrary commands on the host system

An agent with all four of these capabilities and no guardrails is, from a security perspective, equivalent to giving a remote user full access to your machine.

The Agent Security Audit Checklist

Run through each of these areas every time you deploy a new agent or modify an existing one.

1. File Permissions

Check what your agent can actually read and write. Most setups grant far more file access than necessary. Your agent that summarizes PDFs does not need write access to your home directory.

Audit steps:

• List every directory the agent can access
• Identify which files it actually needs for its task
• Restrict access to only those paths
• Use read-only mounts where the agent only needs to consume data

2. API Key Storage

This is where most setups fail. Check how your credentials are stored and accessed:

# Bad: keys in plain text config files
OPENAI_API_KEY=sk-abc123...
STRIPE_KEY=sk_live_...

# Better: use a secrets manager or encrypted env
# Load from system keychain or vault at runtime
export OPENAI_API_KEY=$(security find-generic-password -s "openai" -w)

Never store API keys in files that the agent can read and potentially exfiltrate. Use environment variables loaded from a secure source, and scope keys to the minimum required permissions.

3. Network Exposure

If your agent runs a local server or webhook listener, check what ports are open and whether they are accessible beyond localhost. An agent API running on 0.0.0.0:8080 without authentication is an open door.

• Bind to 127.0.0.1 instead of 0.0.0.0 unless external access is required
• Use authentication on any exposed endpoints
• Review firewall rules to ensure agent services are not publicly reachable

4. Output Sanitization

Agents generate output that often feeds into other systems. If an agent writes to a database, generates HTML, or constructs shell commands, unsanitized output can lead to injection attacks.

Validate and sanitize any agent output before it touches a downstream system. Treat agent output with the same suspicion you would treat user input in a web application.

The Five Most Common Mistakes

After reviewing dozens of agent configurations, the same issues appear repeatedly:

1. API keys in plain text files committed to version control or stored in readable config files. Fix: use .gitignore, environment variables, and secret managers.
2. Unrestricted file system access where the agent can read or modify any file the user can. Fix: run agents in containers or use filesystem sandboxing.
3. No sandboxing at all. The agent runs with the same privileges as your user account. Fix: use Docker containers, dedicated user accounts, or OS-level sandboxing.
4. Overly permissive API keys. Using an admin-level key when a read-only key would suffice. Fix: create scoped API keys for each agent.
5. No logging or monitoring. You have no idea what your agent actually did during its last run. Fix: log all agent actions, API calls, and file operations.

Applying Least Privilege to Agents

The principle of least privilege is straightforward: give every process only the permissions it needs to do its job, and nothing more. For agents, this means:

• Create dedicated API keys with scoped permissions for each agent
• Run agents in isolated environments (containers, VMs, or sandboxed processes)
• Limit file access to specific directories using bind mounts or chroot
• Restrict network access to only the domains the agent needs to reach
• Set time limits and resource caps to prevent runaway processes

A simple Docker setup can enforce most of these constraints:

docker run --rm \
  --read-only \
  --network=agent-net \
  -v ./data:/app/data:ro \
  -v ./output:/app/output \
  -e OPENAI_API_KEY \
  --memory=512m \
  --cpus=1 \
  my-agent:latest

This gives the agent read-only access to its data, a single writable output directory, a restricted network, and hard resource limits.

Monitoring Agent Behavior

You cannot secure what you cannot observe. At minimum, log the following for every agent run:

• Every file read or written, with timestamps
• Every API call made, including the endpoint and response code
• Every shell command executed
• Total tokens consumed and cost incurred
• Any errors or unexpected behaviors

Tools like auditd on Linux or fswatch on macOS can monitor file system activity. For API calls, a simple logging proxy or middleware layer captures everything without modifying the agent itself.

Review these logs regularly. Set up alerts for anomalies: unexpected file access, unusually high API usage, or network connections to unfamiliar domains. The goal is not to prevent every possible issue, but to detect problems quickly and limit their impact.

Security is not a feature you add once. It is an ongoing practice. Run this audit every time your agent setup changes, and you will avoid the mistakes that most people only discover after something goes wrong.