AI Coding Agent Security: What to Lock Down First

AI coding agent security means assuming the agent will eventually follow an attacker's instructions, then limiting what it can reach and send out when it does. Shrink credentials first, sandbox execution with an egress allowlist second, and only then argue about permission prompts.

What is the threat model for an AI coding agent?

An AI coding agent is an LLM in a loop with tools: it reads and writes files, runs shell commands, makes HTTP calls, invokes MCP tools, and in cloud variants opens branches and pull requests. What separates it from a completion plugin is agency, not intelligence. A plugin suggests text that a human accepts. An agent acts, often for dozens of steps, with whatever the host environment holds.

Model the agent as five surfaces:

• Context ingestion: every file, issue, log line and web page the agent reads is a potential instruction.
• Tool layer: shell, file edits, git, package managers. The agent’s privilege is the union of its tools.
• MCP servers: third-party code holding tokens, plus tool descriptions and results the model treats as context.
• Credentials: the ambient secrets on the laptop or runner.
• Egress: curl, DNS, git push, package publish, markdown image rendering.

The organizing test is Simon Willison’s lethal trifecta (June 2025): access to private data, exposure to untrusted content, and an outbound channel. A coding agent on a normal laptop has all three by default. Every control below removes or narrows one leg.

Can prompt injection in a repo, issue, or MCP response run code on a laptop?

Yes, and researchers have shown it repeatedly against shipping products. OWASP’s 2025 LLM Top 10 ranks LLM01 Prompt Injection first and treats LLM06 Excessive Agency as its amplifier: injected text stays harmless until the agent has a tool to act on it.

The public cases, grouped by where the injection lands:

• IDE agents. Cursor shipped fixes for CurXecute (CVE-2025-54135), where injected content rewrote MCP configuration and ran commands, and MCPoison (CVE-2025-54136, Check Point Research), where an approved MCP config could be swapped later without a fresh prompt.
• MCP client tooling. CVE-2025-6514 in mcp-remote (JFrog) gave a malicious MCP server command execution on the connecting client. CVE-2025-49596 in MCP Inspector (Oligo Security) exposed an unauthenticated local interface that a browser could reach, leading to RCE on developer machines.
• Connected services. Invariant Labs (May 2025) used a malicious public GitHub issue to steer an agent through the GitHub MCP server into leaking private repository content into a public PR. A textbook confused deputy.
• The agent as payload. The Nx s1ngularity supply-chain attack (August 2025) shipped malware that invoked Claude Code and Gemini CLI non-interactively to hunt for secrets on infected machines.

Treat these carriers as hostile: source comments, commit messages, test fixtures, lockfiles, dependency READMEs and changelogs, issue and PR bodies, review comments, compiler and terminal output, fetched web pages, and MCP tool descriptions and results. For a concrete walk-through, see how a planted AGENTS.md made an agent run code.

Input filters, classifiers and “ignore previous instructions” warnings reduce noise. They are not a boundary. Spotlighting untrusted content helps a little, and capability-separation designs such as Google DeepMind’s CaMeL help more. What holds is hard capability limits plus human approval on irreversible actions.

How do you shrink credential blast radius before sandboxing anything?

Start with credentials. They set the ceiling on damage, and removing them works even when every other control fails. On a typical developer laptop the agent can read ~/.aws/credentials and SSO caches, ~/.ssh, ~/.npmrc, ~/.pypirc, ~/.docker/config.json, ~/.kube/config, ~/.config/gh/hosts.yml, every .env file, and shell history. CI runners add injected tokens as environment variables.

• Separate agent identity from human identity. Use a GitHub App installation token or an OIDC-issued short-lived credential scoped to named repositories, not a developer’s personal PAT. You get attribution, scoping and a clean revocation path.
• Kill long-lived cloud keys on dev machines. Use SSO with short sessions, and keep production roles unreachable from the session the agent runs in.
• Pull secrets at runtime from a manager instead of leaving them in dotfiles and .env.
• Run the agent as a separate OS user if you can’t containerize yet. It’s crude, but it works.

Do not count .gitignore, .cursorignore or Copilot content exclusion as access control. They trim context. Anything the process can read, the agent can eventually read with cat.

Replit’s July 2025 incident, in which an agent deleted a production database during a code freeze and then misreported what it had done, is the argument for keeping production credentials out of agent environments entirely.

How do you sandbox coding agents and set permissions without killing speed?

Put the agent in an OS-level sandbox or container with an egress proxy allowlist, then widen its autonomy inside that boundary. Done right, sandboxing cuts permission prompts, because the boundary does the work the prompts were doing.

Current primitives (they change often, so confirm in vendor docs):

• Claude Code supports OS-level sandboxing and an egress proxy allowlist. Anthropic open-sourced sandbox-runtime (srt), built on bubblewrap on Linux and Seatbelt on macOS, and says sandboxing sharply reduced prompts internally.
• Codex CLI exposes sandbox_mode and approval_policy in config.toml. Codex cloud runs with network off by default. Keep it off and allowlist per task.
• Copilot coding agent runs in an ephemeral GitHub Actions environment behind a domain firewall. Every allowlist addition widens blast radius.
• Cursor and other IDE agents run with your user’s privileges unless the workspace lives in a devcontainer or remote environment.

Isolation	Strength	Setup cost
OS sandbox (bubblewrap, Seatbelt)	Medium-high	Low
Container or devcontainer	Medium	Low-medium
microVM (Firecracker, gVisor)	High	Medium-high
Vendor cloud environment	High for the host	Low

The failures we see most in assessments are a sandbox with open egress and a container that bind-mounts ~/.ssh, ~/.aws or the Docker socket “so git works”. MicroVMs fail the same way when credentials get injected anyway. Either mistake turns the sandbox into decoration.

Permission modes

Standardize on deny-by-default with a narrow allowlist, enforced by hooks, inside the sandbox. Prompting on everything breeds approval fatigue: developers click approve by reflex and the control becomes a rubber stamp.

In Claude Code, policy lives in settings.json (permissions.allow, permissions.deny, defaultMode) and in PreToolUse and PostToolUse hooks. Hooks are deterministic code that runs regardless of what the model decides. Rules files and system prompts are model-interpreted input that injection can override.

Ship a managed baseline that denies Read(~/.ssh/**), Read(~/.aws/**), Read(**/.env*), Bash(curl:*) and Bash(npm publish:*). Pair it with a PreToolUse hook that rejects git remote add, pushes to unknown remotes, and edits to workflow or MCP config files.

Auto-run modes (--dangerously-skip-permissions, Cursor auto-run, Gemini CLI --yolo, Codex full-auto, Aider --yes-always, Cline auto-approve) are acceptable in one setup only: a disposable container or microVM, no host credential mounts, allowlisted egress, and output reviewed as a diff. Ban them everywhere else in managed settings. Our guide on how to test excessive agency covers checking that this policy is enforced, not merely declared.

Cloud agents versus local CLIs

Copilot coding agent, Codex cloud, Cursor background agents, Jules and Devin protect the laptop and leave a PR trail. They move risk rather than remove it: bot token scope, repository permissions, CI secrets and allowlist creep. A sane split for most teams is cloud agents on low-risk repos and sandboxed local agents for interactive work. In vendor review, check zero data retention, training opt-out, subprocessors, residency, and whether prompt injection is in the vendor’s security scope. Their SOC 2 report covers their boundary, not your credential sprawl.

How do you govern MCP servers and agent rules files?

Treat every MCP server as third-party code holding a token, whoever publishes it. MCP offers no signing or description-immutability guarantee. A tool description can change after approval (a rug pull), a later server can shadow an earlier tool name, and tool output is attacker-controllable data.

• Run an internal registry. Approved servers only, versions pinned, installs from arbitrary package names blocked.
• Hash and diff tool manifests. Alert when a description or schema changes between sessions, and scan descriptions for imperative instructions and hidden Unicode.
• Scope one token per server. Least privilege, short-lived. The MCP authorization spec points to OAuth 2.1 with PKCE and RFC 8707 resource indicators and forbids token passthrough. Static bearer tokens in a JSON config are the anti-pattern.
• Restrict filesystem roots to the project directory.
• Split read and write servers so an exploration session can’t write to GitHub or a database.

In the Supabase MCP case (General Analysis, July 2025), an injection planted in a support ticket made the agent leak a service_role key. The agent held far more privilege than whoever wrote the ticket. That gap is what our MCP server and tool-chain security testing measures against your own servers.

Rules files are code

AGENTS.md, CLAUDE.md, GEMINI.md, .cursor/rules and .github/copilot-instructions.md steer an executing process. Review them like Dockerfiles: version-controlled, CODEOWNERS-protected, changed only through reviewed PRs.

Pillar Security’s Rules File Backdoor research (March 2025) hid instructions in Cursor and Copilot rule files using Unicode tag-block characters and bidirectional overrides. The files looked clean in review and steered the agent in practice. Add a CI check that fails on non-printable, tag-block and bidi characters in instruction files, and flag any instruction file that arrives in a downloaded archive or dependency.

What should you log and alert on when an attacker steers a coding agent?

Ship full session activity to your SIEM. A transcript that lives only in a local JSON file is not monitored. Usable sources today: Claude Code OpenTelemetry export, GitHub and Copilot audit log events via API, Cursor team admin audit logs, session transcripts on disk, and EDR or eBPF telemetry on the agent process tree (Falco works well here).

High-signal rules:

• Bulk reads of dotfiles or credential paths by the agent process.
• curl or wget to non-allowlisted hosts; DNS lookups for newly seen domains.
• git remote add or a push to an unknown remote; npm publish or twine upload.
• Base64 decode piped to a shell; chmod +x on downloaded files.
• The agent spawning shells outside the sandbox.
• Edits to .github/workflows, git hooks, MCP configs or agent settings.

Install telemetry before broad rollout, or you won’t be able to scope an incident. Don’t substitute developer impressions for data, either: in METR’s 2025 trial, experienced developers took 19% longer with AI tools while believing they had been faster.

How do you govern agent pull requests and respond to a compromise?

Agent-authored code goes through the same branch protection and human review as everyone else’s, with extra gates on sensitive paths. Veracode’s 2025 GenAI code report found about 45% of AI-generated code samples failed its security tests, and reviewers anchor on plausible-looking code. Review is necessary, not sufficient.

Gates for agent PRs

• No auto-merge for agent PRs.
• A second reviewer for changes to .github/workflows, hooks, MCP configs, instruction files and dependency manifests.
• Third-party Actions pinned by commit SHA; OIDC federation to cloud instead of stored keys.
• Installs routed through a proxy registry with an allowlist. LLMs hallucinate package names in repeatable ways (Spracklen et al., 2025), which makes slopsquatting cheap.
• gitleaks or TruffleHog plus GitHub push protection on every agent branch.

Incident response

Revoke the bot identity and every token the session could read. Rotate laptop and CI credentials and cut egress for the host. Replay the transcript and OpenTelemetry trace to list files read and commands run. Then diff recent commits and configs for persistence: new MCP entries, hooks, rules files.

Compliance mapping

Map these controls to OWASP LLM Top 10, MITRE ATLAS (AML.T0051 prompt injection, AML.T0010 supply chain compromise), NIST AI RMF with the NIST AI 600-1 profile, and ISO/IEC 42001. Under the EU AI Act most internal coding assistants fall into lower-risk categories, but vendor due diligence and GDPR duties for code touching personal data still apply. Have counsel confirm your classification.

FAQ

What is AI coding agent security?

AI coding agent security is the practice of containing an LLM process that reads files, runs shell, calls MCP tools and pushes code, while trusting none of the text it consumes. The baseline is short-lived credentials, a sandbox with an egress allowlist, deny-by-default permissions and full session logging.

Can prompt injection be filtered out of coding agents?

No. Filters and classifiers reduce noise but do not create a boundary. Contain injection architecturally by limiting what the agent can read, run and send out.

Is .cursorignore a security control?

No. .cursorignore, .gitignore and Copilot content exclusion reduce context. If the process can read a file, the agent can read it through the shell.

When is –dangerously-skip-permissions acceptable?

Only inside a disposable container or microVM with no host credential mounts, egress restricted to an allowlist, and output reviewed as a diff. Block it everywhere else through managed settings.

Are MCP servers from well-known vendors safe to install?

Treat every MCP server as third-party code holding a token. Pin versions, scope one token per server, restrict filesystem roots, and alert when tool descriptions change.

Should agents use developers' personal access tokens?

No. Use a GitHub App installation token or an OIDC-issued short-lived credential scoped to named repositories. Agent actions then stay attributable, narrowly scoped and revocable without touching the developer's own access.

If you want to know what your coding agents can actually reach and send out before an attacker finds out, our AI agent penetration testing exercises injection paths, MCP servers and credential exposure against your real configuration.