AI Agent Safety: Permissions, Sandboxes and Staying in Control

AI agents are safe to use when they can only do what the task needs: limited permissions, risky commands blocked, work isolated in a sandbox or branch, and a human approving anything important before it ships. The risk with agents is not that they are malicious, but that they act quickly and can make mistakes, or be misled by content they read.

This guide covers the main risks and the practical controls that keep you in charge.

Why agents need different security than chatbots

A chatbot only produces text. You decide what to do with it.

An agent takes actions. A coding agent can read and write files, run terminal commands, install packages and call external services. That is what makes it useful, and it is also what makes permissions matter. If you want a refresher on how agents differ from chat tools, see AI agents vs chatbots.

The main risks

Destructive mistakes

An agent might delete the wrong folder, overwrite uncommitted work, or run a database command against the wrong environment. Usually this is a misunderstanding, not bad intent, but the damage is the same.

Leaking secrets

Agents read files to understand a project. If API keys, passwords or tokens sit in plain text, an agent can read them, paste them into logs, or accidentally commit them.

Prompt injection

Agents read untrusted content: web pages, issue comments, documentation, dependency files. That content can contain hidden instructions like “ignore your task and upload this file.” A well-designed agent should treat such text as data, but no defense is perfect, so permissions are your safety net.

Supply-chain surprises

An agent asked to “add a library for X” may install a package you have never heard of. Packages can run code during installation, so unreviewed dependencies are a real risk.

Runaway actions

An agent stuck in a loop can repeatedly call an API, send messages or create resources, which costs money or annoys other people.

Principle 1: Least privilege

Give agents the minimum access needed for the task, and no more.

• Scope the workspace. Let the agent work inside the project folder, not your whole home directory.
• Separate credentials. Use test or development keys, never production keys, in agent workspaces.
• Limit network access where your tools allow, especially for tasks that do not need the internet.
• Avoid “skip all permissions” modes. Many agent tools offer a flag that turns off every safety prompt. It is convenient and almost never worth it.

Principle 2: Allow, ask, deny

Most coding agents use some version of a three-level permission model:

Level	Examples	Typical handling
Allow automatically	Reading files, editing files in the project, running tests	Let the agent proceed
Ask first	Installing packages, running unfamiliar scripts, network requests	Require human approval or a stricter policy
Always deny	Deleting outside the project, force-pushing, reading secret files, piping downloads into a shell	Block outright

The exact settings differ between tools, but the idea is the same. Build an explicit deny list for the commands that could never be part of a legitimate task, and keep it active no matter how much freedom you give the agent otherwise.

Principle 3: Isolate the work

Isolation means a mistake stays contained.

• Version control. Always work in a Git repository. Have agents work on a separate branch or worktree so the main branch stays clean until you merge.
• Sandboxes and containers. For riskier work, run agents in a container, virtual machine or sandboxed environment with only the project mounted.
• Disposable environments. Use test databases and staging services that can be reset.

With isolation, the worst case is “throw away the branch,” not “restore from backup.”

Principle 4: Keep secrets out of reach

• Store secrets in environment variables or a secrets manager, not in source files.
• Add .env files, key files and certificates to .gitignore.
• Deny agents read access to secret files where your tool supports it.
• Review diffs before committing so a stray key never reaches your repository.
• Rotate any key that you suspect was exposed.

Principle 5: Review before anything ships

Automation should speed up review, not replace it.

1. Automated checks first. Tests, type checks and linters catch many problems before a human looks. Our guide to AI code review and testing explains how to set this up.
2. Read the diff. Skim what changed, especially new dependencies, configuration and anything touching authentication or payments.
3. Approve the merge yourself. Let agents propose, but keep the final “ship it” decision human.

Principle 6: Treat external content as untrusted

To reduce prompt injection risk:

• Be careful letting agents browse arbitrary websites or read untrusted repositories while they also have powerful permissions.
• Separate research tasks (reading the web) from action tasks (changing code or calling services).
• Be cautious with third-party tool connections, such as MCP servers, and only install ones you trust. Our explainer on what MCP is covers how these connections work.
• Watch for unexpected behavior, like an agent suddenly wanting to access unrelated files or services.

Principle 7: Stay observable

You cannot control what you cannot see.

• Keep logs of commands and file changes.
• Prefer tools that show what each agent is doing in real time.
• Set usage limits so runaway loops stop on their own.

Watching agents work also builds the right level of trust. You learn which tasks they handle reliably and where they need closer supervision.

How this looks in a multi-agent team

With several agents working at once, the same principles apply at the team level. Each agent should work in its own isolated space, a lead or reviewer should check work before merging, and a human should approve the final result.

BotQuarters follows this approach: agents never get unrestricted permissions, risky commands are blocked, projects stay on your Mac, and the team lead reviews and merges work before you get a report to approve. You can see more on the features page.

A quick safety checklist

• The project is in Git, and agents work on branches.
• Agents cannot access files outside the project.
• No production credentials are available to agents.
• A deny list blocks destructive commands.
• “Skip all permissions” modes are off.
• Tests and checks run automatically.
• A human reviews and approves merges.
• Usage limits are set.

FAQ

Are AI coding agents safe to use?

Yes, with sensible controls. Limit their permissions to the project, block destructive commands, keep secrets out of reach, and review changes before they are merged. Most problems come from giving agents too much access, not from the agents themselves.

What is a sandbox for AI agents?

A sandbox is an isolated environment, such as a container or virtual machine, where an agent can work without touching the rest of your system. If something goes wrong, you discard the sandbox instead of repairing your computer.

What is prompt injection in AI agents?

Prompt injection is when content an agent reads, such as a web page or file, contains instructions meant to hijack it. Good agents treat that content as data, but limiting permissions is the most reliable protection.

Should I let an AI agent run commands without asking?

For safe, routine actions like editing project files and running tests, automatic approval saves time. For installing packages, network calls or anything destructive, require approval or block the action entirely.