AI coding agent security means limiting what an agent can read, execute, install, and deploy, and treating everything it reads from outside your control as potentially hostile. The five attack surfaces are untrusted input, tools and MCP servers, repo-defined hooks and config, the execution sandbox, and credentials in CI. This page is the map: it shows where each risk sits, which control closes it, and which deeper guide to open next.
An agent that can read a repository, run shell commands, install packages, and call APIs is useful for exactly the same reasons it is risky. It acts on text it did not write, using permissions a developer granted for convenience. Most incidents are not a model going rogue. They are an ordinary input, tool, or file that the agent trusted more than it should have.
The five attack surfaces at a glance
| Attack surface | What goes wrong | Primary control | Go deeper |
|---|---|---|---|
| Untrusted input | An issue, PR title, README, or log line carries instructions the agent follows | Limit who can trigger the agent and separate untrusted input from secrets and write access | GitHub Actions prompt injection fixes |
| Tools and MCP servers | A tool description or response poisons the agent, or a server holds more authority than the task needs | Scope each tool, verify tokens, and treat tool metadata as untrusted | MCP server security controls |
| Repo-defined hooks and config | A malicious hook or settings file in a cloned repo runs with your user rights | Lock who may define hooks, and make blocking hooks fail closed | Claude Code hooks security |
| Execution sandbox | The agent writes a file that a later tool, IDE extension, or Git hook executes outside the sandbox | Treat the whole workspace as untrusted and validate what runs after the agent exits | AI coding agent sandbox escapes |
| Credentials and CI | Agents inherit long-lived keys, or write secrets into generated code and commits | Scope every credential to one task and scan for secrets before and after runs | One permissions policy for every agent |
1. Untrusted input steers the agent
Every text field an agent reads can carry an instruction. Issue comments, dependency READMEs, web pages, and tool output all reach the model with the same weight as your own prompt. The defense is structural rather than a warning in the prompt: keep the agent away from secrets and write access whenever it is reading content a stranger could have written. In CI, that usually means no privileged token on runs triggered by outside contributors.
2. Tools and MCP servers widen the blast radius
Each connected tool is a new trust boundary. A server can read more data than the task needs, return a response that rewrites the agent's next step, or hold a token that outlives the session. Grant tools per action rather than per server, verify who issued each token, and review what a server can reach before you connect it to a repository that holds production secrets.
3. Hooks and config files come with the repository
Hooks are the strongest guardrail you can put around an agent, and they are also code that runs automatically. A cloned repository can ship its own settings that register a hook, so a hostile project can execute commands on the first session. Keep hook definitions under a user-level or managed policy, and make any hook that enforces a rule fail closed when it errors.
4. A sandbox is a boundary only if you check what leaves it
Running an agent in a container limits the immediate process, but agents often write files that something else executes later: an editor extension, a Git hook, a virtual environment, a local service. Those paths sit outside the agent's process, so the sandbox does not cover them. Close them by treating the workspace as untrusted and checking any file the agent changed before a human or tool runs it.
5. Credentials are the real prize
An agent with a long-lived cloud key, a write-capable GitHub token, or access to a password store has a route to everything those credentials touch. Give each task its own short-lived, narrowly scoped credential. Scan generated code and commits for keys, because agents copy patterns from their context, including tokens they found in local files.
Where to start this week
If you are starting from zero, do the work in this order. Each step reduces risk even if you stop after it.
- Give the agent its own identity. Run it as a non-privileged user, keep SSH keys and cloud master credentials out of its reachable filesystem, and remove shared tokens from its environment.
- Put it in a disposable environment. Use a container or VM for autonomous runs, and restrict outbound network access to the hosts the task actually needs.
- Write one deny-by-default policy. Declare allowed commands and paths once, then enforce them in each tool's native permission config rather than in prompts.
- Add deterministic checks. Hooks and CI gates enforce policy; instructions in AGENTS.md only advise. Roll new rules out in audit mode before you enforce them.
- Require human approval for high-impact actions. Deployments, credential changes, destructive commands, and production writes should wait for a person.
- Keep an audit trail. Record each tool call with its arguments so you can reconstruct what the agent did and why.
The full item-by-item version of this list, with the specific checks for each, is in the AI coding agent security checklist.
What this map does not replace
This page covers where the risks live and how the controls relate. It does not replace a threat model for your specific product. A payments app, an internal tool, and a marketing site carry different data and different blast radii, so the same control can be mandatory in one and optional in another. Start from what the agent can reach in your repository, then pick the controls that cut that reach first.
FAQ
What is the biggest security risk of an AI coding agent?
The biggest risk is the combination of untrusted input and broad credentials. When an agent reads text a stranger wrote and also holds a token that can push code or read secrets, a single injected instruction can use that access. Removing either half of the combination lowers the risk sharply.
Is a sandbox enough to secure an AI coding agent?
No. A sandbox limits the agent process, but files the agent writes can be executed later by tools outside the sandbox. You also need scoped credentials, deny-by-default permissions, and checks on what changed before it runs.
Should AGENTS.md be my security control?
Use AGENTS.md to describe the rules, not to enforce them. An instruction file is advice that the model may ignore. Permissions, hooks, and CI checks are the enforcement layer, and they should match what the file says.
Where should a small team start?
Start with identity and credentials: a non-privileged user and no shared long-lived keys. Those two changes remove the largest category of damage before you tune anything else.
Next step
If you are reviewing how your team runs coding agents and want a second pair of eyes on permissions, credentials, and CI, you can reach me through gramowski.dev.