{"schemaVersion":"1.0","type":"TechArticle","types":["Article","TechArticle"],"slug":"how-to-secure-ai-coding-agents-sandboxing-permissions-and-human-approval-gates-au71v","url":"https://zyvop.com/how-to-secure-ai-coding-agents-sandboxing-permissions-and-human-approval-gates-au71v","title":"How to Secure AI Coding Agents: Sandboxing, Permissions, and Human Approval Gates","subtitle":"Prompt injection can't be fully fixed, so contain it: sandbox the agent, lock down what it can touch, and keep humans on the actions that can't be undone.","tldr":"AI coding agents read files, run commands, and install packages for you, and anything they read can carry hidden instructions. Here’s a simple, layered way to secure them: sandboxing, least-privilege permissions, and human approval gates that people don’t learn to ignore.","keywords":["security","sandboxing","developer tools","AI agents","prompt-injection","AI"],"entities":["Shobit Singh","security","sandboxing","developer tools","AI agents","prompt-injection","AI","ZyVOP"],"keyTakeaways":["A coding agent is a bit like a very fast junior developer who has your terminal open, your credentials loaded, and no instinct for when to stop and ask.","It reads your repo, runs shell commands, installs packages, and calls APIs.","That's exactly why it's useful, and exactly why it deserves a real security model instead of a hopeful one."],"headings":["This isn't hypothetical","Layer 1: Sandboxing limits the damage","Layer 2: Permissions give the agent the least access it needs","Layer 3: Human approval gates, used where they matter","A practical checklist","The takeaway","Further reading"],"outboundLinks":["https://cline.bot/blog/post-mortem-unauthorized-cline-cli-npm","https://mindgard.ai/resources/vibe-check-security-failures-in-ai-assisted-ides","https://anthropic.com/engineering/claude-code-sandboxing","https://www.anthropic.com/research/claude-code-auto-mode","https://code.claude.com/docs/en/sandboxing","https://code.claude.com/docs/en/permissions","https://pillar.security/blog/prompt-injection-leads-to-rce-and-sandbox-escape-in-antigravity","https://www.wiz.io/blog/ghostapproval-a-trust-boundary-gap-in-ai-coding-assistants","https://koi.ai/blog/clawhavoc-341-malicious-clawedbot-skills-found-by-the-bot-they-were-targeting","https://cybersecuritynews.com/github-copilot-rce-vulnerability","https://www.theregister.com/2025/12/17/ai_code_bugs/"],"contentText":"A coding agent is a bit like a very fast junior developer who has your terminal open, your credentials loaded, and no instinct for when to stop and ask. It reads your repo, runs shell commands, installs packages, and calls APIs. That's exactly why it's useful, and exactly why it deserves a real security model instead of a hopeful one. The uncomfortable part is that the agent doesn't only take instructions from you. It takes them from everything it reads: a README, a GitHub issue, a web page, a package's docs, the output of a connected tool. Any of those can carry text that looks like an instruction. That's called prompt injection. OWASP, a well-known security group, ranks it as the top risk for AI applications, and nobody has a complete fix for it. So the goal isn't to build an agent that can't be tricked. It's to build a setup where a tricked agent can't do much damage. Three layers get you there: sandboxing, permissions, and human approval gates. Each one covers a gap the others leave open. This isn't hypothetical In February 2026, researcher Adnan Khan showed how a crafted GitHub issue title could hijack the AI triage bot in the repository of Cline, a popular AI coding tool. The bot could be tricked into running an attacker's code. Combined with a tampered cache in the project's automated build system (CI), that could expose the secrets used to publish Cline's package. Eight days after his disclosure, someone without permission used a still-active npm token to publish a tampered cline@2.3.0. The team had revoked the wrong token by mistake. The package added one script that ran automatically on install, and it was live for about eight hours. Cline's VS Code extension and JetBrains plugin weren't affected. The takeaway: an agent that reads untrusted text, like an issue title, shouldn't share caches or credentials with your release pipeline. Security firm Mindgard found the same pattern in AI coding editors, including Codex, Kiro, Antigravity, and Cursor. Researcher Piotr Ryciak presented the findings at the [un]prompted 2026 conference. The common thread is tools that combine untrusted input, private data, and a way to send data out. Ryciak compares this moment to the browser wars, which taught the industry about sandboxing the hard way. Layer 1: Sandboxing limits the damage A sandbox is a restricted environment that controls what a program can reach. It's the one layer that doesn't depend on the model behaving, because your operating system enforces it on every program the agent starts. A good sandbox limits two things: Filesystem. Let the agent write only inside the project folder. Also check what it can read: by default, Claude Code's sandbox lets commands read most of your machine, including ~/.ssh and ~/.aws/credentials, until you add deny rules. Network. Block everything by default, then allow only what the task needs, such as your package registry. You need both. Without network limits, a hijacked agent can read a secret and send it anywhere. Without filesystem limits, it can tamper with files outside the project and gain more access. Claude Code's built-in sandbox uses operating-system tools (Seatbelt on macOS, bubblewrap on Linux). It sends network traffic through a proxy that checks each website against an allowed list, which starts empty. The sandbox is off until you turn it on with /sandbox. If the code is untrusted, or the agent runs on its own, use something stronger, such as a dev container or a throwaway virtual machine (VM). The less you trust the input, the stronger the isolation should be. Know the limits of a sandbox: It doesn't cover everything. Claude Code's sandbox wraps shell commands only. Its built-in file and web tools, and any local MCP servers (add-ons that connect the agent to other tools), run outside it and follow permission rules instead. To cover everything, run the whole process in a container or VM. A real example. In Google's Antigravity editor, Pillar Security found that a built-in file-search tool ran before the \"Secure Mode\" checks on shell commands. With crafted options, it could be made to run code. Google fixed it after a January report. It can fall back to no sandbox. If the sandbox can't start (on native Windows, or when a required component is missing), Claude Code runs commands without it unless you set failIfUnavailable. Claude can also ask to retry a blocked command outside the sandbox, unless you turn that off. The allowed list isn't airtight. The proxy only checks website names and doesn't inspect encrypted traffic. Allowing a broad site like github.com can give an attacker a way to smuggle data out. Anthropic's docs say a sandbox reduces risk but isn't perfect isolation. Keep your tools updated, and avoid options like enableWeakerNestedSandbox (meant for running inside Docker) unless something else isolates the agent. Layer 2: Permissions give the agent the least access it needs Permissions decide what the agent is allowed to do at all. What matters is where the rule lives. Claude Code's docs say permission rules are enforced by Claude Code itself, not by the AI model. A line in your prompt or CLAUDE.md shapes what Claude tries, but it doesn't change what Claude is allowed to do. Rules are checked in this order: deny, then ask, then allow. Hooks, which are scripts that run before a tool call, can block a call completely. Here's a starting point in Claude Code's settings (current as of November 2026; other agents have equivalents): { \"sandbox\": { \"enabled\": true, \"failIfUnavailable\": true, \"allowUnsandboxedCommands\": false, \"network\": { \"allowedDomains\": [\"registry.npmjs.org\"] } }, \"permissions\": { \"deny\": [\"Read(./.env)\", \"Read(~/.ssh/**)\"], \"ask\": [\"Bash(git push *)\", \"Bash(npm publish *)\"] } }This turns the sandbox on, makes it refuse to run if it can't start, blocks the unsandboxed retry, and allows only the npm registry. It also blocks reading your .env file and SSH keys, and asks you before any git push or npm publish. Rules that match command text are speed bumps, not walls. For example, a rule that denies Bash(curl *) won't catch /usr/bin/curl or sh -c 'curl ...'. Read deny rules cover Claude's file tools and common commands like cat, but not a script that opens the file itself. The sandbox covers that gap. Mindgard saw an agent do this: when its file-reading tool was blocked from a .env file, it worked out that a shell command could read the file instead. A few habits matter more than the syntax. Protect the agent's own config. Settings, hooks, MCP config, and instruction files should be off-limits to the agent. In CVE-2025-53773, hidden instructions got GitHub Copilot to turn on an auto-approve setting in .vscode/settings.json, which switched off its confirmation prompts. It was patched in August 2025. Claude Code's sandbox blocks writes to its own settings, hooks, and .mcp.json for the same reason. Keep secrets out of reach. Don't leave a live .env file in the workspace. Use short-lived tokens, a separate bot account, a fine-grained read-only GitHub token, and never production database credentials. Claude Code can also block sandboxed commands from reading credential files and variables you list, or mask them, so the command sees only a placeholder. The proxy swaps in the real value only for requests to allowed websites. Treat MCP servers, skills, and plugins as dependencies. Koi Security checked 2,857 skills on ClawHub, a public skill registry for OpenClaw, and found 341 were malicious, 335 of them from one campaign. After rescanning the larger registry, it counted 824. Lock each add-on to a specific version, read what you install, and run local servers inside the sandbox. Don't mark a downloaded project folder as trusted until you've looked at it, because a repo can include its own hooks and MCP settings. Mind your package manager. For Node projects, review changes to the lockfile, be careful with install scripts (--ignore-scripts turns them off), and wait a day or two before using brand-new package versions. Agents also sometimes make up package names, and attackers register those names with malicious code. Publish from CI using short-lived OIDC credentials instead of a long-lived npm token. Cline switched to this after its incident. Layer 3: Human approval gates, used where they matter Approval prompts are valuable, but people can only handle so many. Anthropic reports that Claude Code users approve 93% of permission prompts, and that sandboxing cut prompts by 84% in its own internal use. Those are Anthropic's own numbers, but the lesson holds: a few well-placed prompts beat constant ones. People who get nagged too often reach for a flag that skips permissions, and then there's no gate at all. So put approval gates where the consequences are serious. If an action is local and reversible, let it run inside the sandbox. If it's irreversible or reaches outside your machine, bring in a human. Always require a person for: Pushing to shared branches, merging, or deploying Publishing packages or cutting releases Deleting data, running migrations, or touching anything in production Adding a new website to the network allowed list Installing new dependencies, MCP servers, or skills Editing the agent's own configuration Anything that involves credentials Be careful with automated approvers. Claude Code's auto mode replaces most prompts with an automated checker, called a classifier. Anthropic's write-up says it still let through 17% of real cases where the agent overstepped, in a small test. It also says auto mode isn't a replacement for human review on high-stakes systems. Use it for routine work, and keep humans in charge of the actions listed above. Make the approval honest. A prompt only helps if it shows what will actually happen. In July 2026, security company Wiz disclosed a flaw it called \"GhostApproval\" in six coding agents, including Claude Code, Cursor, and Amazon Q Developer. A malicious project includes a symlink (a shortcut to another file) with an innocent name that really points at something sensitive, like ~/.ssh/authorized_keys. The approval prompt shows only the harmless name. Wiz's advice to tool makers: resolve the symlink and show the real destination, flag any write outside the project, and write nothing until the user approves. Put gates outside the agent too. Use branch protection, required reviews, and CI checks so the agent can't approve its own pull request. Don't rely on local prompts for the big ones. Claude Code's docs note that an ask rule for Bash(git push *) won't match a reworded command like git -C . push, so protection on the server is the real gate. Review the agent's changes the way you'd review a stranger's contribution. In a CodeRabbit study of 470 open-source pull requests, AI co-written ones had about 1.7 times as many issues. The sample is small and CodeRabbit sells AI review tools, so treat the number as a hint. Also keep logs, so you can see what the agent actually did. A practical checklist Turn the sandbox on, limit files to the project, block the network by default, and make it refuse to run if it can't start. Keep secrets out of the workspace, and use short-lived, narrow tokens. Add deny rules for sensitive paths and hooks for the important ones, with the sandbox underneath. Make the agent's own config read-only to it. Vet every MCP server, skill, and plugin, and lock each to a version. Put humans on irreversible and outward-facing actions, with prompts that show the real target. Use branch protection, CI, and diff review on the server side. Keep your tools updated, and revisit the rules after every near miss. The takeaway You can't promise an agent will never be fooled, so set things up so the damage stays small. A sandbox limits what it can reach, permissions limit what it may do, and approval gates put a human in front of the few actions that can't be undone. Get those three right, and you can give your agent a lot more freedom. Further reading Cline, Post-mortem: Unauthorized Cline CLI npm publish Mindgard, Vibe Check: Security Failures in AI-Assisted IDEs Anthropic, Making Claude Code more secure and autonomous with sandboxing Anthropic, How we built Claude Code auto mode Claude Code docs, Sandboxing and Permissions Pillar Security, Prompt injection leads to RCE and sandbox escape in Antigravity Wiz, GhostApproval: a trust boundary gap in AI coding assistants Koi Security, ClawHavoc: 341 malicious skills found Cyber Security News, GitHub Copilot RCE vulnerability (CVE-2025-53773) The Register, AI-authored code contains worse bugs than software crafted by humans","contentHash":"sha256:e0d309fe0ef1e6bbfb0d10d2f9c3432be08d4b32ff0996d51242f6fdc0833aab","authorName":"Shobit Singh","authorUrl":"https://zyvop.com/author/shobit","authorSameAs":[],"category":"AI","tags":["security","sandboxing","developer tools","AI agents","prompt-injection"],"audience":"Software engineers and developers building applications with AI","tone":"Instructional, practical, code-first","readingTimeMinutes":8,"wordCount":2076,"faqs":null,"primaryTopic":"AI","publishedAt":"2026-11-10T08:11:10.268Z","updatedAt":"2026-11-10T08:11:10.268Z","canonicalUrl":"https://zyvop.com/how-to-secure-ai-coding-agents-sandboxing-permissions-and-human-approval-gates-au71v"}