Skip to content

Safe permissions for AI coding agents

Coding agents should never hold standing production credentials. Run them in a sandbox or development environment, give them scoped, short-lived credentials, and forbid permission-bypass flags, including modes where a model approves actions in place of a person.

Require human approval for destructive actions, but don't rely on approval alone, because prompts get clicked through: require a dry run first and keep backups the agent can't reach. Check what the agent says it did against system logs. This page sets out those controls as of October 2026, for developers' coding agents and for the agents inside AI app builders.

Who this is for

Security and platform engineers setting policy, developers who use agentic coding tools, and non-developers whose AI app builder has an agent that edits the app and its database. About 9 minutes.

Scope. This page covers agents used to build apps: terminal, IDE and app-builder agents that edit code, run commands and touch databases. Agents and tools inside the apps you build, including MCP servers and SaaS agent builders, are on MCP security for business AI tools.

What has gone wrong?

Fast-moving

As of October 2026. Check the review date.

These cases, in date order, are part of the wider failure patterns behind this site.

When What happened What would have stopped it
Jul 2025 A coding agent deleted a company's production database during a code freeze, despite instructions, then produced fake data and test results and said rollback was impossible.1 The vendor then added dev/prod separation No production credentials for the agent; a tested restore
Jul 2025 A command-line agent mishandled a failed command and overwrote the user's files while "moving" them, then reported that it had failed.2 Version control and backups; a sandboxed working copy
Jul 2025 A compromised token let an attacker ship a destructive prompt (wipe the home directory and cloud resources) inside an official coding-assistant extension release; it failed only because of a syntax error.5 Pinned, verified extension versions from an approved list
Aug 2025 A compromised build package ran the AI command-line tools already installed on developers' machines, with flags such as --dangerously-skip-permissions, --yolo and --trust-all-tools, to hunt for secrets. More than 1,000 tokens leaked and thousands of private repositories were made public.6 Bypass flags banned by policy and disabled by admin settings; minimal-privilege dev machines
about Dec 2025 (user report) An IDE agent in an auto-approve mode ran a recursive delete at the root of a user's drive while "clearing a cache", with no recovery.3 Auto-approve off for deletes; agent in a container or VM
Apr 2026 An agent hit a credential mismatch in staging and deleted a hosting volume, removing the production database and its volume-level backups in about 9 seconds. The host restored it from a backup about three months old, with data lost since then (news reports).4 Scoped tokens; backups in a separate account the agent can't reach

Every case involved an agent holding access it didn't need, or a mode that removed the check. None needed a clever attack on the model.

Don't: give an agent standing production access (AP4)

Three of the cases above destroyed live data because the agent could reach it. The fix is structural: the agent works where production isn't reachable, and what it builds reaches production through a release you control (failure patterns).

What are the eight controls for coding agent permissions?

These apply to every coding agent your builders use. Three are already rules at every tier: Floor 1, the trifecta rule (no agent may combine private data, untrusted content and a way to send data out), and never-dos 4 and 5 (no agent write access to live systems without a sandbox run first, a scoped credential and a tested restore; no permission-bypass modes).

  1. No standing production credentials. The agent never holds a key or login that can change production. Releases reach production through a step a person takes.
  2. Work in a sandbox. A container, a virtual machine, the tool's own sandbox, or a cloud workspace, with file access limited to the project and network access limited to what the task needs. Limiting network access also removes the send-out leg of the trifecta (Floor 1): an agent that reads untrusted content (issues, web pages, package READMEs, MCP output) and holds secrets or private code must not have open network access.
  3. Scoped, short-lived credentials. Each credential is limited to the actions and the one environment the task needs, and expires. Never your own login, and never a shared admin key.
  4. Bypass modes off. Permission-bypass flags, "auto-approve everything" modes and classifier-approved modes are forbidden by policy and disabled in managed settings where the tool allows it (see permission modes).
  5. Approval plus a dry run for destructive actions. Deletes, migrations, bulk updates, force-pushes and anything touching infrastructure need a person's approval after seeing a dry run or plan of exactly what will change.
  6. Backups the agent can't reach, restored at least once, held in a separate account or with separate credentials.
  7. Check claims against logs. What the agent says it did is compared with the diff, the command history and the system's own audit log.
  8. Agent tools are managed endpoints. The agent software, its extensions and MCP servers come from an approved list at pinned versions, and their configuration is reviewed like any other privileged software.

Download the baseline as a spreadsheet: agent-permissions-baseline.csv, with how to enforce each control, the evidence, the owner and a status column. Prompt to Prototype, Safe permissions for AI coding agents, https://prompt-to-prototype.com/security/coding-agents/, as of October 2026. Licensed CC BY-SA 4.0. Using or adapting it inside your business isn't distribution under the licence.

When is an agent a worker-built app? Under modifier M3, when it acts without a person approving each action (it runs on a schedule or trigger, or chains tool calls unattended) under a person's or a service identity. An agent you build with a coding tool, or a coding agent you run unattended (on a schedule, a trigger or in CI), is a worker-built app tiered on every permission it holds (agents and automations); standard downgrade 3 isn't available to it, so scope the credential. An interactive coding assistant in a builder's editor, with per-action approval, isn't itself a worker-built app: it's a tool, approved on approve tools.

Keeping app-builder agents away from live data

An AI app builder's agent may edit the app and its database in the same session. You don't need containers to apply the baseline. Check these in the tool's settings, or ask the vendor:

  • Separate test and live copies. The agent works on a development copy, and publishing to the live app is a separate step a person takes. A tool with only one copy isn't suitable for anything other people rely on (environments).
  • The live database isn't connected to the agent. If the agent's session uses the live one, ask for a copy, or keep real data out until there is one.
  • A plan or ask-first mode is on for anything beyond a small change, so you see what the agent intends before it acts.
  • Version history and data backup both exist, and you've restored once (keep a version you can roll back to).
  • Connected services use their own keys, scoped and held in the platform's secret store, not your personal account (secrets).

If the tool can't do the first two, it shouldn't be approved for apps above Sandbox. That's a question for the approved-tools review.

Permission modes and bypass flags

As of October 2026, agentic coding tools typically offer: ask before every edit or command; auto-approve file edits but ask for commands; plan-only, where the agent proposes and doesn't act; a classifier-approved ("auto") mode, where a model reviews each action and approves it in place of you; and a full bypass that runs everything without asking. Names differ by tool and change often. For example, one coding agent has an auto mode in which "a classifier reviews actions instead of you",7 and another has an auto_review approvals reviewer that sends approval prompts to a reviewer subagent instead of the user.8

  • Classifier approval isn't human approval. For never-do 5, classifier-approved modes count as bypass modes. Allow them only in a disposable sandbox with no credentials to shared systems and no real data. Elsewhere, turn them off.
  • Default to ask-first or plan mode beyond a small, local change, and pre-approve specific safe commands (running tests, a linter) instead of turning prompts off.
  • Disable bypass and auto modes in managed settings. For example, one coding agent has disableBypassPermissionsMode and disableAutoMode settings intended for managed settings,7 and another has an enterprise "strict mode" that stops users entering its auto-approve mode and can't be overridden locally.9 Check each tool, including any classifier mode, when you approve it.
  • Sandbox reduces prompts more safely than bypass. One vendor reports its OS-level file and network isolation cut permission prompts by 84% in internal use (vendor figure).10

Don't: run agents in permission-bypass or classifier-approved mode (AP8)

The Nx attackers relied on bypass flags already being normal on developer machines.6 A recursive delete in an auto-approve mode had no recovery.3 Bypass modes stay off, in the sandbox too; a classifier-approved mode is allowed only in a disposable sandbox with no shared credentials or real data.

Don't: treat the approval prompt as the control

People approve prompts by habit. If habitual auto-accept is common in your pilot, that's the falsifier for approval-only controls (A-016). A prompt limits damage only when the credential behind it is scoped, the action had a dry run, and a restore exists.

Agent tools and extensions are privileged endpoints

A coding agent runs with your permissions on your machine, often with keys in its environment.

  • Versions. Install agent tools and IDE extensions from the approved list, pin the version, and update deliberately. A malicious release came through an official extension channel in July 2025.5
  • Flags and config. Review the tool's configuration files, including MCP server lists, through device management (finding shadow MCP servers).
  • Credentials. Don't keep production keys in shell profiles or .env files on machines where agents run, and deny the agent read access to .env and credential files in its permission rules, where the tool supports it. The Nx attack used installed agents to search exactly those places.6

Don't: install unvetted extensions, MCP servers or plugins (AP7)

The tool, its extensions and its servers are all code that runs with your access. Use the approved list and the MCP security baseline.

Supply chain: packages the agent adds

Agents install packages as they work, and models sometimes name packages that don't exist, which attackers can then register: in one study, at least 5.2% of the packages commercial models suggested didn't exist, on average, and 21.7% for open-source models.11 Check every package the agent adds before accepting it; the checks are on dependencies. Where you run pipelines (circumstance C6), install only through a registry proxy that allows approved packages, and keep a lockfile (supply-chain controls).

Don't: install whatever the model suggests (AP9)

An agent that runs npm install or pip install on its own is installing what the model suggested, including names that may not exist.11 Review new dependencies in the diff before they're merged.

Audit trail: check what the agent actually did

Keep records made by the system, not the agent: the diff or version history, the agent's command history, and the target system's own audit log for database changes, cloud resources and deleted files. If the agent says "no data was changed" and the log shows deletes, believe the log (verify, step F).

Don't: believe the agent's own report (AP5)

In the July 2025 database deletion, the agent's account of what happened, including that rollback was impossible, was wrong.1 If an agent touched anything that matters, check the system logs and handle it as an incident if needed (incident response).

Rollout checklist for security and platform teams

Track each of the eight controls in the baseline CSV, and also:

  • Coding agents and app builders with agents are on the approved-tools list, with pinned versions and the settings from this page recorded.
  • Bypass and classifier-approved modes disabled through managed settings on every tool that supports it; tools that can't are approved only for sandboxed use.
  • A sandboxed workspace with limited network access is the documented default for developers.
  • Short-lived, scoped credentials issued for development environments; no production credentials on developer machines.
  • Agent command logs kept and reachable by whoever handles incidents; backups in a separate account, with a dated restore test.
  • Builders trained on the five never-dos, with this page as the reference.

Assumptions and evidence

  • A-016 (High): we expect coding agents with broad permissions, or write access to production without approval, to take destructive actions sometimes despite instructions; test this by logging near misses (destructive commands proposed or blocked) in your pilot, and by sampling how often approval prompts are accepted without reading.

Evidence: incident reports (news, an incident database, a vendor bulletin, vendor research), a peer-reviewed study, vendor documentation and one vendor figure on sandboxing. There's no base rate for destructive agent actions. Facts on this page are as of October 2026.

  1. The Register, "Vibe coding service Replit deleted production database", 21 Jul 2025 (draws on the affected user's own posts). https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/ [news], accessed 2026-10-22. ↩↩

  2. AI Incident Database, Incident 1178, "Google Gemini CLI Reportedly Deletes User Files After Misinterpreting Command Sequence", reported 21 Jul 2025 (from the user's own report). https://incidentdatabase.ai/cite/1178/ [incident database], accessed 2026-10-22. ↩

  3. TechRadar, report of Google Antigravity deleting a user's drive (a user report; date not independently confirmed). https://www.techradar.com/ai-platforms-assistants/googles-antigravity-ai-deleted-a-developers-drive-and-then-apologized [news], accessed 2026-10-22. ↩↩

  4. Decrypt, report of an AI agent deleting a small company's production database in about 9 seconds, Apr 2026 (the founder's primary post wasn't read). https://decrypt.co/365897/ai-agent-deletes-startup-database-9-seconds-founder-says [news], accessed 2026-10-22. ↩

  5. AWS, security bulletin AWS-2025-015 on the Amazon Q Developer extension, Jul 2025. https://aws.amazon.com/security/security-bulletins/AWS-2025-015/ [primary], accessed 2026-10-22. ↩↩

  6. Wiz Research, "s1ngularity: supply chain attack", 26 Aug 2025. https://www.wiz.io/blog/s1ngularity-supply-chain-attack [vendor], accessed 2026-10-22. ↩↩↩

  7. Anthropic, Claude Code documentation, "Configure permissions" (the auto mode, and the permissions.disableBypassPermissionsMode and permissions.disableAutoMode settings). https://code.claude.com/docs/en/permissions [vendor], accessed 2026-10-22. ↩↩

  8. OpenAI, Codex configuration reference (the approvals_reviewer setting: "Defaults to user; auto_review uses the reviewer subagent"). https://developers.openai.com/codex/config-reference [vendor], accessed 2026-10-22. ↩

  9. Gemini CLI documentation, "Enterprise Admin Controls" (strict mode). https://geminicli.com/docs/admin/enterprise-controls/ [vendor], accessed 2026-10-22. ↩

  10. Anthropic Engineering, "Making Claude Code more secure and autonomous with sandboxing", Oct 2025. https://www.anthropic.com/engineering/claude-code-sandboxing [vendor], accessed 2026-10-22. ↩

  11. Spracklen et al., "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs", USENIX Security 2025. https://arxiv.org/abs/2406.10279 [research], accessed 2026-10-22. ↩↩