Skip to content
← All guides

Evaluation & Operations

MDX

Permissions and Sandboxing for AI Agents

Apply least privilege, scoped credentials, isolation, and approval boundaries to agent actions.

4 min readAgentic Systems Editorial Team

Editorial review: clarity, operational relevance, safety boundaries, and source quality.

Scope access to the task

Give an agent only the records, tools, environments, and time window required for its current job. Avoid broad shared credentials that silently expand every task's authority.

Authorization should be derived from the authenticated user, current task, resource, action, and time—not from the model's request. Issue short-lived capability tokens where possible and resolve broad user intent into narrow runtime permissions. Denials should be explicit observations, never invitations for the agent to search for a bypass.

Separate read from write

Read-only exploration is lower risk than mutation. Make writes explicit, log them, and introduce stronger checks as actions become less reversible.

Separate read, propose, approve, and execute permissions. Exploration can happen with redacted read access, while a write requires a validated proposal and fresh authorization. This separation also improves UX: users can inspect the exact change before granting authority rather than approving an open-ended session.

Run risky work in isolation

Code execution, file processing, and browser automation should operate in constrained environments with resource limits. Promote artifacts out only after validation.

Sandboxes constrain code, browsers, and file processing through filesystem, network, process, and resource limits. Start from no access, mount only needed inputs, and export only validated artifacts. Isolation reduces impact but does not make outputs trustworthy; scan, test, and review artifacts before they cross the boundary.

Practical example

Sandboxing a code-fixing agent

The agent receives a temporary copy of one repository, can reach an approved package registry, and has no production credentials. It edits and runs tests under CPU and time limits, then returns a patch and test report. A separate trusted process validates the diff before merge. The sandbox limits compromise and accidental damage while preserving a reviewable artifact.

Field checklist

Apply it in practice

  • Authorize every tool call against user, task, action, and resource.
  • Use short-lived, least-privilege credentials.
  • Separate proposing a change from executing it.
  • Validate artifacts before promoting them out of isolation.

Decision framework

Questions to answer before you build

Permissions determine what an agent may request; sandboxes limit what execution can affect. Both should begin with no access and expand only for the current task.

Can authorization be task-scoped?

Derive access from authenticated user, task, resource, action, environment, and time. Prefer short-lived capabilities over shared credentials.

Can proposal and execution be separated?

Let the agent prepare an exact change without write authority, then require fresh approval or a trusted service to execute it.

What crosses the sandbox boundary?

Mount only required inputs, limit network and resources, and validate patches, files, or other artifacts before promotion.

Common failure signals

Watch for these warning signs

  • Using one broad credential for every user and task.
  • Assuming a sandbox makes generated artifacts safe or correct.
  • Returning permission denials that encourage the agent to search for another route.

Selected primary references

Continue with the source material

These sources inform the wider editorial perspective for this topic. They are not presented as line-by-line citations for every statement.

↑ Back to top