Agents in Vibe Coding: Sandboxing and Permissions

Agent mode is what made vibe coding a distinct practice, and it is also where the real risks appear. The difference from completion is not convenience but that an agent takes actions.

How an agent differs from completion

Completion proposes text. You decide whether to accept it. Nothing happens without your keystroke.

An agent performs actions. It opens files, edits them, runs commands, reads output and continues. Every action is real.

Everything else follows: an agent has consequences. It can delete a file, install a package, make a network request, run a command with side effects. Not out of malice but because it judged that a step toward the goal.

The gain is genuine: an agent that sees test output fixes its own mistakes without you. That changes outcome quality more than switching models does.

What must not be handed over

A short list, and not about code quality:

Production. No live database access, no infrastructure keys, no deploy capability. The agent does not distinguish reversible from irreversible.

Secrets. Anything that entered context has gone to the model provider. A key file at the project root gets read during the agent’s first file search, with no intent involved.

Work nobody will check. If a change has no verification, it should not be an agent change.

Client code under NDA, where the contract forbids third parties. The model provider is a third party.

Levels of isolation

Weakest to strongest:

Permissions in configuration. A list of what needs no confirmation: tests, build, reads. Everything else asks. Enough for ordinary work on your own machine.

Directory and network restrictions. The agent sees only the project and cannot send data outward at will. A sensible level for a sensitive project.

Full isolation. A container, a virtual machine or a separate computer where there is nothing to lose. The only mode where allowing everything is reasonable: the worst outcome is a spoiled copy you can recreate.

The practical rule: allow-everything mode outside an isolated environment is not a time saving but a deferred risk. How this works in practice is on the blog: sandbox your coding agent.

How permission modes look in a specific tool: CLI commands and modes.

Reviewing agent code

It differs in two ways.

The author did not read the code the way they read their own. Reviewers normally lean on the assumption that the author thought about every line. That support is missing.

The errors are of a different kind. Agents rarely err syntactically and often plausibly: the wrong case handled, a function duplicated under a new name, a symptom fixed instead of a cause, an unnecessary dependency added. All of it survives a skim.

What helps:

• A reasonable change size. A thousand-line diff is not reviewed, it is scrolled.
• Tests written in a separate pass. Written in the same pass, they encode the same wrong assumption.
• Checking new dependencies. A package that appeared in the diff is worth looking up.
• The diff, not the report. The report describes intent, the diff shows fact.

How this is handled in team settings: Claude Code for teams.

The practical minimum

If you do only four things:

1. Work in git, on a clean tree.
2. Do not grant access to secrets or production.
3. Read the diff before accepting.
4. Full access only inside an isolated environment.

Why the agent errs confidently: how it works. Delegating work inside an agent: subagents. The overview is in the vibe coding guide.