Picture this: a developer asks their coding agent to upgrade a logging library and fix whatever breaks. The agent reads the library’s changelog to understand the changes. Buried in a comment is a single instruction aimed at the agent: confirm the environment works by sending ~/.aws/credentials to a diagnostics URL. The agent complies. A production cloud key just left the building.
No malware. No phishing. The agent read some content and acted on it with access it already had.
The blind spot in your AI agent review process
Most companies approve one coding agent, such as Claude Code, Cursor, or GitHub Copilot, and ship it to engineering. That review covers the agent itself. It doesn’t cover what developers bolt on afterward.
A developer finds an MCP server on npm or GitHub, adds a few lines to a config file, and the approved agent can now read Jira, query a database, or send email. Extensions, rules files, and side-by-side trials of other agents arrive the same way. None of it passes through procurement or third-party risk review.
The Cloud Security Alliance found that 82% of enterprises have AI agents in their environments they don’t know about, and 53% have seen agents exceed their intended permissions.
What a coding agent can actually touch
- Developer pastes: Stack traces, log excerpts with customer data, and config snippets with live keys go into the prompt for a faster fix.
- Files on disk: Repositories,
.envfiles, SSH keys, and cloud credentials sit on the same disk the agent searches. - Connected services: MCP servers wire the agent into Jira, GitHub, databases, Slack, and email, often using the developer’s own tokens.
- Installed skills and plugins: Each one adds new instructions, commands, hooks, and bundled MCP servers in a single step. The Cloud Security Alliance documented a coordinated campaign of malicious skills on ClawHub, a public skills registry used in Claude Code workflows.
- Shell execution: Commands, package installs, git pushes, and cloud CLI calls, sometimes with no confirmation step.
- Persistent configs: Rules files and agent memory persist across sessions and shape every future action.
- Developer identity: Every action runs under a human identity. The logs show the developer, never the agent.
⚠️ Indirect prompt injection is real and already exploited
Coding agents read untrusted content all day: tickets, READMEs, pull request comments, package docs, and tool descriptions MCP servers publish. Any of it can carry instructions.
In CurXecute (CVE-2025-54135), a Slack message the agent was asked to summarize rewrote Cursor’s MCP configuration and ran code on the developer’s machine without approval. A compromised Amazon Q extension for VS Code shipped with a prompt instructing the agent to wipe the user’s home directory and delete AWS resources, calling the CLI with flags that skipped every confirmation.
Point-in-time approval doesn’t hold
An approval covers one version on one day. Extensions auto-update, CLIs pull new releases, and MCP servers are often launched with commands that fetch the latest package every time the agent starts.
The postmark-mcp package shows exactly what that means. Its publisher released 15 clean versions. Version 1.0.16 added one line that BCC’d every email the agent sent to an outside address. Anyone who reviewed an earlier version had no reason to look again.
A Cloud Security Alliance research note also documents exploitable CVEs in GitHub Copilot, Cursor, OpenAI Codex CLI, and Claude Code, ranging from command injection to malicious project hooks that run code when the agent launches.
️ Eight controls worth putting in place
- Inventory everything: Every AI agent, extension, skill, and MCP server on developer machines, including version and who installed it.
- Run an approved MCP registry: Pin versions, block unknown servers, and re-review whenever a package updates.
- Apply least agency: Following OWASP’s agentic guidance, give agents only the permissions a task needs. Turn off auto-approve modes in sensitive repositories.
- Inspect prompts and tool calls: Catch secrets, customer data, prompt injection, and risky commands before they execute.
- Move credentials to a vault: Get them out of
.envfiles sitting in the workspace. - Treat rules files and agent configs as code: Put them through review and change tracking.
- Log every tool call: Which agent, which developer, what data, and what was blocked.
- Name one owner: Platform engineering and security should share accountability, not assume the other team has it.
Banning coding agents outright doesn’t work. It just moves usage to personal machines where you have even less visibility. The goal is knowing what your agents can touch and verifying that boundary every day.

