AI Agent Security Checklist: Permissions and Sandboxes

Agent security is about controlling actions. A chatbot can return a wrong answer. An agent can use real credentials, call a tool, and change production data.

The default rule is simple: do not give an agent capabilities it does not need. Start with narrow tools, policy checks before each tool call, isolated sandboxes, limited credentials, human approval gates, and audit traces. Add guardrails and output filters too, but do not treat them as the main security boundary.

Threat model and review date: 2026-08-10. These priorities assume a tool-using agent can process attacker-controlled input and can read data or cause external side effects. Lower-capability assistants need fewer controls; higher-impact actions need stricter isolation and approval.

Pattern ranking

PatternPriorityProtects againstImplementation note
Least-privilege toolsP0Excessive agencyFollow the OWASP MCP guidance: do not expose tools the agent should never use.
Pre-tool policy checksP0Dangerous actionsCheck the concrete action right before execution.
SandboxesP0File, shell, browser, and network damageIsolate code and untrusted content; deny network egress by default.
Human approvalsP0Irreversible or regulated actionsGate writes, deployments, payments, external sends, and privileged changes.
Scoped credentialsP0Credential overreach and confused deputy failuresUse per-server, per-tool, narrow scopes.
MCP server isolationP1Tool poisoning, tool shadowing, cross-server attacksDo not mix untrusted servers and powerful tools in one context without review.
Audit tracesP1Unknown incident historyPersist user request, tool call, args, result, policy decision, and approver.
GuardrailsP1Unsafe input and output textUseful, but not enough for tool authority.
Red-team evalsP1Known attack pathsTest prompt injection, tool poisoning, data exfiltration, and permission bypasses.

What to implement first

Remove capabilities first. If the agent does not need to write to GitHub, do not give it a write token. If it only needs calendar availability, do not grant full mailbox access. A narrow permission is safer than a stern prompt.

Next, check policy before every tool call. Inspect the tool name, arguments, target resource, user, environment, and side effect. A harmless-looking request can still produce a dangerous shell command.

Add sandboxes for code execution, browser automation, file access, and untrusted document processing. A sandbox does not make the action correct, but it reduces the damage from a compromised tool result or confused model.

Control data flow as well as execution. Restrict outbound network destinations, redact secrets from tool results, separate untrusted content from credentials, and log attempted egress. A filesystem sandbox that still permits arbitrary network access leaves a direct exfiltration path.

Use human approval for irreversible actions. Do not approve every step. Approve boundaries: production deploys, data deletion, email sends, money movement, permission changes, and regulated decisions.

MCP-specific risks

MCP is useful because it standardizes tool access. It is risky because tool descriptions, schemas, server identities, OAuth scopes, and tool outputs all become part of the model’s decision context.

For MCP, I would keep these rules in code review:

  • review tool descriptions and schemas before approval
  • prefer narrow per-server credentials
  • isolate untrusted MCP servers from sensitive tools
  • watch for tool definition changes after installation
  • treat tool output as untrusted input
  • log every server, tool, argument, and result

Guardrails are not enough

Guardrails can validate input and output. They do not solve least privilege, credential scope, sandboxing, tool poisoning, or approval policy. Keep them, but put them after capability design and before user-visible output.

Deeper reading

References