Sandboxed by default. How we built agent permission boundaries

Most AI tools today treat permissions the same way. Everything is locked down. The agent stops and asks before every file write, every command, every network call. You spend more time approving actions than getting work done.

This breaks the entire point of autonomous agents. Mode Agent is built for continuous operation. Agents that keep working when you close your laptop. Cloud execution that runs for hours unattended. That doesn't work if agents need you to click "approve" every ten seconds.

Full autonomy by default

Mode Agent's agents run with full permissions out of the box. They can read files, write files, run commands, and make network calls. No interruptions. No approval prompts. You describe what you want built and agents get to work.

This is a deliberate design choice. If you're asking an AI to build a feature, it needs to read your codebase, write new files, run tests, install dependencies, and iterate on failures. Requiring explicit approval for each of those steps defeats the purpose.

The question isn't "should agents have permissions." It's "how do you give users control without destroying the workflow."

Granular controls when you want them

Some users will want full autonomy and never touch the permission system. That's fine. But others, especially teams, enterprises, or anyone working with sensitive codebases, will want to set boundaries.

Mode Agent's permission system is designed for those users. It's opt-in, not opt-out.

Permissions are structured around four dimensions.

• Scope defines which files or directories the agent can access
• Operations cover read, write, execute, or network
• Agents specifies which agent types are affected by the restriction
• Duration can be session-scoped, task-scoped, or permanent

A typical permission config looks like this.

# .mode/permissions.yaml
restrict:
  - scope: .env, secrets/**
    operations: [read, write]
    agents: [all]
    action: block

  - scope: production/**
    operations: [write, execute]
    agents: [coder, tester]
    action: block

  - scope: src/**
    operations: [write]
    agents: [doc-writer]
    action: block

This config lets agents do anything except touch secrets, write to production directories, or let the doc-writer modify source code. Everything else runs without interruption.

The sandbox is the safety layer

The key insight is that the sandbox enforces boundaries at the runtime level, not the LLM level. It doesn't matter what the model thinks it should do. If a restriction is in place, the runtime blocks the action. The model can be prompted, confused, or manipulated. The sandbox doesn't care.

This matters for prompt injection defense. If malicious content in a file tries to convince an agent to read secrets or delete files, the runtime blocks it regardless of what the model decides. The boundary exists outside the model's reasoning.

The audit log

Every action is logged to a structured audit trail at .mode/audit.jsonl, whether it was allowed or blocked. Each entry records the agent, the operation, the target path, the timestamp, and the result.

{"ts":"2026-02-05T14:22:31Z","agent":"coder","op":"write","path":"src/api/users.ts","allowed":true}
{"ts":"2026-02-05T14:22:35Z","agent":"coder","op":"write","path":".env","allowed":false,"reason":"restricted"}
{"ts":"2026-02-05T14:22:36Z","agent":"coder","op":"read","path":"secrets/api_keys.yaml","allowed":false,"reason":"restricted"}

Blocked actions are surfaced in the Mode Agent UI. If an agent consistently hits a boundary while doing legitimate work, that's a signal to adjust the restriction. If it hits boundaries doing unexpected things, that's a signal something is wrong.

The audit log is especially valuable for cloud execution and continuous operation. When agents run for hours unattended, the log is how you verify what happened while you were away.

Why this matters for cloud execution

Mode Agent's cloud execution and continuous autonomous operation depend on this model. Agents need to run without interruption for long periods. They need to iterate on test failures, install dependencies, refactor code, and push changes without waiting for human input.

A permission system that interrupts this workflow is worse than no permission system at all. It creates a false sense of security while making the product unusable for its core purpose.

The right approach is full autonomy with optional, granular restrictions. Run free by default. Lock down what matters. Log everything.

What's coming

We're working on extending the permission system with more granular controls.

• Git-level controls with separate restrictions for staging, committing, and pushing, so you can let agents commit without pushing to remote
• Cost boundaries to cap spend per agent or per task, so long-running autonomous work doesn't surprise you
• Secret detection to automatically identify files that likely contain secrets and flag them for restriction

Security is an ongoing investment. But it should never come at the cost of the autonomous workflow that makes Mode Agent useful in the first place.