An AI agent with tool access is powerful. It can search the web, read files, send emails, execute code, and call paid APIs. That power comes with risk. A misconfigured agent can leak credentials, send unauthorized messages, exfiltrate data, or run up unexpected bills.

Security for AI agents is different from traditional application security because the agent makes autonomous decisions about which tools to call and what data to send. You can’t review every action in advance. Instead, you need guardrails, monitoring, and a clear threat model.

The Threat Model

AI agents face several categories of risk:

Credential exposure. The agent needs API keys, tokens, or credentials to access tools. If these are embedded in prompts, logged in plaintext, or stored insecurely, they can be extracted.

Prompt injection. Malicious input (from users or from data the agent reads) can manipulate the agent’s behavior. An attacker who controls content the agent processes can potentially instruct it to take unintended actions.

Data exfiltration. An agent with access to sensitive data and outbound communication tools (email, web requests) could be manipulated into sending that data to an attacker.

Unauthorized actions. The agent might take actions the user didn’t intend, either through misunderstanding the task or through manipulation.

Cost attacks. An attacker could trigger the agent to make expensive tool calls, draining credits or running up bills.

Principle of Least Privilege

Give the agent access only to the tools it needs for its current task. Nothing more.

If the agent’s job is to research a topic and write a summary, it needs search tools and maybe a data API. It does not need email access, file system access, or code execution. Don’t connect tools “just in case.”

This applies at multiple levels:

  • Tool selection. Only register the tools the agent actually needs.
  • Scope within tools. If a tool supports read and write operations, grant read-only access when that’s all the agent needs.
  • Data access. Limit which databases, files, or accounts the agent can reach.

The blast radius of a compromised or misbehaving agent is directly proportional to the permissions it has. Fewer permissions means less damage.

API Key Management

Never put API keys in prompts. This is the most common security mistake with AI agents, and it’s easy to make.

When a key is in the prompt, it’s part of the LLM context. It can appear in logs, be included in error messages, or be extracted by prompt injection attacks. Some early agent frameworks suggested putting API keys directly in system prompts. Don’t do this.

Instead:

  • Store keys in environment variables or a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler).
  • The agent runtime reads keys from the environment and includes them in HTTP headers. The LLM never sees the key value.
  • Rotate keys regularly. Set up automated rotation if your secrets manager supports it.
  • Use separate keys for development and production. Never test with production credentials.
  • If a key is compromised, revoke it immediately and rotate.

Sandboxing

If your agent can execute code (Python, shell commands, JavaScript), that code must run in a sandbox.

An unsandboxed code execution tool gives the agent (and anyone who can manipulate the agent) full access to the host system. This includes reading files, making network requests to internal services, and modifying system configuration.

Sandboxing options:

  • Container-based. Run code in a Docker container with no network access and limited file system access. Destroy the container after execution.
  • VM-based. Run code in a lightweight VM (Firecracker, gVisor). Stronger isolation than containers.
  • WASM-based. Run code in a WebAssembly sandbox. Limited language support, but strong isolation guarantees.

The sandbox should have no access to the host network, no access to environment variables containing secrets, and limited CPU and memory. Kill the sandbox after a timeout (30 seconds is usually enough).

The OpenClaw CVE-2026-25253 Vulnerability

In early 2026, a vulnerability (CVE-2026-25253) was disclosed in OpenClaw, an open-source AI agent framework. The issue was a prompt injection vector in MCP tool responses.

When OpenClaw called an MCP tool, the tool’s response was inserted directly into the agent’s context without sanitization. A malicious MCP server could return a response containing instructions that the LLM would interpret as part of its system prompt. In the proof of concept, the malicious response instructed the agent to read local files and send their contents to an external URL via a web request tool.

The fix involved treating all tool responses as untrusted data, displaying them to the LLM as clearly delimited user content rather than system instructions.

This vulnerability illustrates a broader principle: treat all external data as untrusted. Tool responses, web page content, file contents, and user input can all contain adversarial instructions. Your agent’s architecture should assume that any data it reads might be trying to manipulate it.

Tool Approval Workflows

For sensitive actions, require human approval before execution.

Which actions need approval:

  • Sending emails or messages to external recipients.
  • Making purchases or spending above a threshold.
  • Modifying production data or configurations.
  • Accessing sensitive personal information.
  • Executing code that could have side effects.

How to implement approval:

The simplest approach is a confirmation step. Before executing a sensitive tool call, the agent presents the planned action to the user and waits for approval. Most agent frameworks support this pattern.

For automated agents (those running without a human in the loop), use allowlists. Define which tool calls are pre-approved (read-only operations, searches) and which require out-of-band approval (email, file writes). Queue the unapproved actions and notify a human.

Monitoring and Logging

You can’t secure what you can’t see.

Log every tool call. Record the tool name, input parameters (with sensitive values redacted), response status, timestamp, and cost. This is your audit trail.

Alert on anomalies. Set up alerts for unusual patterns:

  • High-frequency tool calls (possible runaway loop).
  • Tool calls to unexpected endpoints.
  • Large data transfers through communication tools.
  • Authentication failures.
  • Spending spikes.

Retain logs. Keep audit logs for at least 90 days. Security incidents often aren’t detected immediately, and you’ll need historical data to investigate.

Platforms like AgentPatch log every tool invocation with full metadata, giving operators visibility into what their agents are doing. If you’re building your own tool infrastructure, replicate this pattern.

Practical Checklist

  • API keys stored in environment variables or secrets manager, never in prompts
  • Agent has access only to the tools it needs (least privilege)
  • Code execution runs in a sandboxed environment
  • All tool responses treated as untrusted data
  • Sensitive actions require human approval
  • Every tool call is logged with redacted parameters
  • Alerts configured for anomalous behavior
  • Keys rotated on a regular schedule
  • Separate credentials for development and production
  • Spending limits set per task and per day

AI agent security is a young field, and the threat model is still evolving. But the fundamentals, least privilege, secure credential storage, sandboxing, monitoring, and treating external data as untrusted, apply regardless of which framework or model you’re using. Get these right, and you’ll avoid the most common and damaging failure modes.

← Back to blog