The Agentic Threat Model
- Identify the five attack surface categories unique to agentic coding environments
- Understand the five defense-in-depth layers Claude Code uses and what each protects against
- Apply the principle of least privilege when deciding which permissions to grant for a given task
What Makes Agentic Coding Different
When you ask Claude a question in a chat interface, the worst outcome of a wrong answer is confusion. When Claude Code runs a shell command, writes a file, or pushes a commit, the wrong action can delete data, expose credentials, or corrupt a repository in ways that take hours to undo. That difference — from generating text to executing actions — is what defines the agentic threat model.
Claude Code is not a chatbot that happens to suggest code. It reads your filesystem, executes shell commands, makes network requests, and commits changes. Each of those capabilities is useful. Each is also a potential attack surface if not properly constrained. Understanding the threat model is the prerequisite for configuring any safety control intelligently.
The Five Attack Categories
Threats in agentic coding fall into five distinct categories, each requiring a different defense:
- Prompt injection: An attacker embeds instructions inside content Claude reads — a file in your repository, a web page it fetches, a GitHub issue title, or an npm package README — trying to hijack Claude's behavior mid-task. The attacker never interacts with Claude directly; they rely on Claude processing their content as part of a legitimate task.
- Runaway automation: Claude misinterprets scope and takes actions far broader than you intended — deleting files that match a pattern too loosely, pushing changes to a branch you didn't specify, or sending API requests to production instead of staging. This is usually not malicious; it's a precision problem amplified by autonomous execution.
- Credential exposure: Bash commands run by Claude inherit the parent process environment, including AWS keys, GitHub tokens, database passwords, and other secrets stored as environment variables. Without explicit protection, a prompt-injected subprocess or a misguided shell command can read and exfiltrate them.
- Unintended file writes: Shell configuration files (.bashrc, .zshrc, .gitconfig), CI configuration, and Claude's own settings files (.claude/settings.json) are ordinary files from a filesystem perspective. An overly permissive session could modify them — changing how your shell behaves, altering hooks, or adjusting Claude's own permission rules.
- Supply-chain manipulation: A malicious npm package README, a poisoned documentation page, or a compromised build script could contain instructions that Claude follows during an install, build, or dependency update task. The attack surface exists wherever Claude reads content it did not generate.
The Five Defense Layers
Claude Code addresses these threats with five composable layers. No single layer covers every category — that's intentional. Each catches what the others miss.
Allow, deny, and ask rules that control which tools Claude Code can invoke and which file paths or domains each tool can access. Evaluated before any tool runs. Covers all tools including Bash, file operations, WebFetch, and MCP.
A hardcoded set of directories and files (shell rc files, .git, .claude, .vscode, .husky, and more) that are never auto-approved in any mode except bypassPermissions. Runs before allow rules, so an allow rule cannot pre-approve a protected-path write.
OS-level enforcement (macOS Seatbelt, Linux bubblewrap) that restricts what Bash commands and their child processes can read, write, and connect to. Applies even after a command is approved — a bypassed permission decision still hits the OS boundary.
A separate model that reviews tool calls in auto mode before they execute. Operates on user messages and tool calls only — tool results are stripped so hostile file content cannot manipulate it. Blocks based on behavioral patterns across the full transcript.
Organization-wide settings deployed via MDM, Ansible, or server-managed configuration. Cannot be overridden by users or projects. Enforces floor-level controls (require sandbox, disable bypass mode, restrict permission rules to managed definitions) across every developer.
Why Each Layer Is Necessary
Consider what happens when only one layer is in place. Permission rules can be manipulated at the model layer — a well-crafted prompt injection could convince Claude to approve an action it shouldn't. The sandbox catches that because it enforces boundaries at the OS level regardless of what Claude decided at the permission layer. The auto-mode classifier catches behavioral patterns that no specific deny rule anticipated. Managed policy enforces organizational standards even when a developer's own settings are permissive.
The combination is stronger than any individual mechanism. A prompt injection that convinces Claude to run a malicious command still hits the sandbox filesystem boundary. A carefully crafted deny rule with a missing edge case still gets caught by the classifier's behavioral analysis. Layers that fail independently succeed collectively.
The Principle of Least Privilege
The most effective safety practice in agentic coding is also the simplest: grant Claude only the permissions it needs for the current task, then revoke them when the task is done. If you're exploring a codebase before proposing changes, use plan mode. If you're editing files but not running tests, use acceptEdits. Don't start in auto mode with broad allow rules and narrow them down after something goes wrong.
This matters especially for sensitive repositories. A project handling payment data, user credentials, or production infrastructure deserves a tighter permission profile than a personal side project. Project-specific .claude/settings.json files can set a conservative defaultMode and a tight deny list that applies to every session in that directory, regardless of the user's personal settings.
The same principle applies to MCP servers. Add only the servers your actual workflow requires. A blanket allow rule for every tool from every MCP server is the agent equivalent of running everything as root.
Thinking in Layers from the Start
The mental model to carry through this track: safety in Claude Code is not a single setting you toggle on. It is a stack of independent controls, and using them well means understanding what each covers, where each falls short, and how they compose when multiple controls apply to the same action.
The rest of the track walks through each layer in depth — starting with permission modes, which set the baseline for everything else.
- Agentic coding changes the risk profile — Claude executes shell commands and writes files, so a mistake is not a wrong answer but an unrecoverable action.
- Five independent layers compose to create defense in depth: permission rules, protected paths, sandbox, auto-mode classifier, and managed policy — each catches what the others miss.
- Default-deny is the correct baseline — Claude Code requires explicit approval for writes and shell commands before you configure anything, so the out-of-the-box posture is conservative.
- Least privilege applies to AI agents — scope permissions to the task in progress, not the full session, and apply stricter defaults in sensitive repositories through project settings files.
- Prompt injection is a real threat in agentic coding — attackers embed instructions in files, web pages, and package metadata that Claude reads, so the attack surface extends to every piece of content Claude processes.