What is the biggest security risk for AI agents?

Prompt injection combined with excessive permissions. If an agent reads untrusted content that contains hidden instructions, and it has broad access to data and tools, it can be manipulated into leaking data or taking harmful actions. Least privilege, isolation, and approvals limit the damage.

Should AI agents have access to secrets?

Agents should use capabilities that require secrets without seeing the secrets themselves. Keep keys on the runtime side and inject them into tool execution. Use short-lived, narrowly scoped credentials per session, and never place secrets in prompts, files the agent reads, or logs.

How do you sandbox an AI agent?

Run each session in an isolated container, microVM, or VM with its own file system, no access to the host, restricted outbound network, resource limits, and short-lived credentials. Destroy or reset the sandbox after the task, and log everything that happens inside it.

Agent Runtime Security: How to Contain AI Agents

Agent runtime security means containing what an AI agent can do even when it is wrong or manipulated. Run agents in isolated sandboxes, give them narrowly scoped and short-lived credentials, restrict network and file access, require human approval for sensitive actions, set resource and spending limits, treat all retrieved content as untrusted, and log every action for audit.

Why agents need runtime security

Agents read untrusted content, generate code, call tools, and act with real credentials. A model can misunderstand instructions, hallucinate a command, or follow instructions hidden in a web page or document. Prompt-level rules help, but they can be bypassed. Runtime controls provide limits that do not depend on the model behaving.

Isolate execution

Run each agent session in its own sandbox: a container, microVM, or isolated VM with its own file system. Prevent access to the host and to other sessions. Reset or destroy the environment after each task where possible, so state from one task cannot leak into another.

Scope credentials tightly

Give agents the minimum permissions they need, for the shortest time. Use separate service accounts, read-only access by default, and short-lived tokens issued per session. Keep secrets out of the model's context: inject them into tool execution on the runtime side, so the model can use a capability without ever seeing the key.

Control network access

Default-deny outbound network traffic and allow only the domains a task needs. Egress control limits data exfiltration if an agent is manipulated into sending data somewhere. Separate internal services from the agent network unless explicitly required.

Defend against prompt injection

Any content an agent reads, including web pages, emails, documents, issue comments, and tool outputs, can contain instructions aimed at the model. Treat it as data, not commands. Limit which tools can be used after reading untrusted content, require confirmation for actions triggered by external content, and avoid giving a single agent both broad read access to sensitive data and unrestricted ability to send data out.

Require approval for sensitive actions

Define which actions are irreversible or high-impact: deleting data, deploying, sending messages externally, spending money, changing permissions. Require explicit human approval for these, shown with enough context to decide. Agents can propose; people release.

Set resource and spending limits

Limit CPU, memory, run time, number of steps, tool calls, and token spend per session. Cap payment actions with per-transaction and daily limits. Limits contain runaway loops and reduce the damage of mistakes.

Log and monitor everything

Record every model call, tool call, input, output, and approval, attributed to the agent identity and the user who started it. Store logs append-only. Alert on unusual patterns, such as sudden spikes in tool calls, new domains contacted, or repeated permission failures.

Protect data the agent retrieves

Retrieval systems should enforce access controls at query time, so an agent only receives chunks the requesting user may see. Encrypt private data at rest. RDK stores private vault content as encrypted private chunks and separates them from the public network, so private retrieval stays private.

Test the controls

Run red-team exercises with malicious documents and pages, attempt to exfiltrate secrets, and try to trigger unapproved actions. Verify that sandbox, credential, network, and approval controls hold even when the agent is fully compromised.

Identity and attribution

Give each agent its own identity rather than letting it act as a human user. Record which user started each session and which agent performed each action. Clear identity makes permissions easier to scope and incidents easier to investigate, and it lets you revoke one agent's access without affecting people.

Supply chain risks

Agents install packages, run scripts, and connect to tool servers. Pin dependencies, use trusted registries, review MCP servers and plugins before installing them, and scan generated code before it reaches production. A compromised dependency inside an agent's sandbox can still exfiltrate data if network controls are loose.

Incident response

Plan for the day an agent does something wrong. Be able to stop all sessions quickly, revoke credentials, and reconstruct what happened from logs. Review incidents to adjust permissions, approvals, and limits, rather than only changing prompts.

Data minimisation

Give agents only the data a task requires. Retrieval with access checks at query time, rather than loading whole databases or folders into context, reduces what can leak if an agent is manipulated, and lowers token cost at the same time.

Payments and financial actions

Agents that can spend money need the strictest controls: per-transaction caps, daily limits, allow-listed recipients, and human approval above a threshold. Avoid giving agents permanent payment credentials; issue scoped, revocable authority per task instead, and log every payment together with the session and user that requested it.

Frequently asked questions

What is the biggest security risk for AI agents?: Prompt injection combined with excessive permissions. If an agent reads untrusted content that contains hidden instructions, and it has broad access to data and tools, it can be manipulated into leaking data or taking harmful actions. Least privilege, isolation, and approvals limit the damage.
Should AI agents have access to secrets?: Agents should use capabilities that require secrets without seeing the secrets themselves. Keep keys on the runtime side and inject them into tool execution. Use short-lived, narrowly scoped credentials per session, and never place secrets in prompts, files the agent reads, or logs.
How do you sandbox an AI agent?: Run each session in an isolated container, microVM, or VM with its own file system, no access to the host, restricted outbound network, resource limits, and short-lived credentials. Destroy or reset the sandbox after the task, and log everything that happens inside it.