AI Coding Agent Security: Risks Your Approvals Miss

Your security team approved Claude Code, Codex, or Cursor. Good. But approval answers a narrow question: is this vendor trustworthy? It does not answer the one that matters: what can this agent do with my credentials, my repos, and whatever text it reads next?

That gap is where AI coding agent security is now being tested. In October 2026 alone, vendors shipped multiple sandbox and permission fixes in a single week, researchers showed a malicious instruction file could hijack an agent, and standards bodies started publishing assessment handbooks for coding assistants. This article explains the real attack surface and gives you a practical control ladder you can act on this week.

Why AI coding agent security is different from app security

A coding agent is not a sandboxed web app. It runs as you. It inherits your shell, your SSH keys, your cloud credentials, and your access to every repo you can clone. When it decides to act, it does so with your full rights.

That changes the threat model. The main risk is not that the model is malicious. It is that the agent is persuadable: it takes instructions from whatever it reads. A README, a dependency changelog, a code comment, or a configuration file can all become a command.

Agents run with your identity and keys

Every approved action inherits the developer's permissions. If the agent can read a cloud credentials file, a single bad instruction can exfiltrate it. No malware, no phishing, and no failed approval step is required.

Untrusted input is the primary vector

The dominant risk is untrusted content entering the agent's context window. Treat anything an agent reads as potentially hostile input, the same way you would treat user-submitted data in a web application.

Instruction files are now an execution path

Coding agents automatically load instruction files from their working directory. Files such as AGENTS.md or CLAUDE.md are plain text and not executable, which is why they look harmless in code review. They are not harmless. Prompt injection does not require a bug in the model; it only requires text the agent trusts.

How AGENTS.md hijacking works

Researchers found a malicious AGENTS.md in a Downloads folder that doubled as an agent's working directory. The file instructed the agent to install a rogue npm package. The team reproduced the technique against OpenAI Codex and demonstrated a related approach against Claude Code that could leak OAuth tokens.

The lesson: an instruction file can change agent behavior without touching the agent itself. Review it like code, and never run an agent inside a folder you have not vetted.

Changelog and comment injection

A prompt injected into a library changelog can direct an agent to read credentials and send them to an external URL. Every approval can be in place and the attack still succeeds, because the agent used access it already held.

Sandbox bypasses and what they teach us

Sandboxes are the strongest control available, but they are only as good as their edges. In one recent Claude Code release cycle, more than ten fixes addressed routes around the sandbox and permission checks. Documented bypass classes included:

• Shell startup files that ran outside the sandbox before sandboxed commands executed.
• Symlinks that caused path-based deny rules to fail at the real file location.
• MCP configuration files that sandboxed commands could reach.

Codex similarly hardened its sandbox checks and added credential masking in remote shell sessions.

Why vendors are patching in weekly cycles

Frequent security releases are a sign of a maturing attack surface, not a sign that a product is failing. Plan for regular updates. Pin versions in managed environments, and track vendor release notes as a security input.

The MCP shadow-IT gap

Model Context Protocol (MCP) servers extend an agent with new tools. The governance problem is simple: a team approves one agent, then a developer adds an MCP server from npm or GitHub with a few lines of config. The approved agent now reaches whatever that server reaches, and the security review never saw it.

Third-party AI risk review usually covers the agent. It rarely covers what developers attach to it afterward.

Auditing what your agents can reach

Build a simple inventory:

1. List every agent in use, including personal installs.
2. List every MCP server and tool each agent loads.
3. For each, record the credentials and network destinations it can access.
4. Remove servers that nobody owns or can justify.

Make this review recurring. It should cover new additions, not only the initial approval.

A risk-tiered control ladder

Not every policy needs the same enforcement. Assign each rule the lightest mechanism that actually enforces it:

1. Instructions (such as CLAUDE.md or AGENTS.md): use for coding conventions. Treat them as guidance, not security.
2. Hooks: use for checks that must run every time, such as blocking commits that include secrets.
3. Admin settings, sandbox scope, and network scope: use wherever a wrong action would actually matter, such as credential directories and production network access.

The rule of thumb: if a failure would be expensive or invisible, do not rely on a text instruction. An agent told "don't read credentials" is not a control. A sandbox that denies the read is.

Runtime enforcement with zero-trust sandboxes

The emerging vendor response is to run every agent in a zero-trust environment by default. The premise: an interactive agent with a developer's full rights can reach credentials and unrelated projects, and can write code that makes requests beyond what its visible tool calls show. Permission prompts alone cannot cover that.

Deterministic controls over agent self-restraint

Enforce boundaries outside the model. Use OS-level or runtime sandboxes, network allowlists, and identity-aware policy. Do not ask the agent to behave.

Observability and safety events

Log safety-relevant actions and export them to your existing telemetry pipeline. Newer releases expose safety events for exactly this purpose. If you cannot see what the agent attempted, you cannot respond to an incident.

Common pitfalls to avoid

• Treating approval as ongoing safety. Approval is a point-in-time decision. Reassess when agents, models, or MCP servers change.
• Trusting text rules for hard limits. Instruction files guide behavior; they do not enforce it.
• Ignoring developer-added tooling. Personal MCP servers and agent installs are the most common unreviewed exposure.
• Skipping updates. Sandbox fixes ship often. A pinned, outdated agent can carry known bypasses.

Frequently asked questions

Can an AI coding agent steal my credentials? Yes, if it can read them and an attacker can influence its instructions. Injected text in files, changelogs, or configuration can direct the agent to send credentials externally, even with approvals in place. Limit credential access with sandbox and deny rules.

Are AGENTS.md and CLAUDE.md files a security risk? They can be. These files load automatically and shape agent behavior. Review them like executable code, and do not run agents in folders containing untrusted instruction files.

What is MCP and why does it matter for security? Model Context Protocol servers give agents new tools and data access. Each server expands what the agent can reach. Inventory and approve every server, including ones developers add themselves.

Is a sandbox enough to secure a coding agent? A sandbox is the strongest control, but it must be kept current. Sandbox bypasses have been patched repeatedly. Combine sandboxing with least-privilege credentials, network controls, and regular updates.

How should a team start governing AI coding agents? Inventory agents and MCP servers, enforce hard limits at the admin and sandbox layer, use hooks for must-run checks, and treat instruction files as code under review.