Your developers are deploying agents in your production environment right now. You have no governance for it.
Somewhere in your organization, a developer has Claude Code or Cursor or GitHub Copilot running on their machine, with read access to your codebase, write access to your repos, and tokens that get them into your CI/CD pipeline. They use it every day. They didn’t ask permission, or they asked permission once for “AI coding assistance” and what they got approved for has since grown a configuration surface nobody at your company has reviewed.
You have a policy for this, and that policy says “approved tools only,” but it gets ignored, because the unapproved tools work better. Or the policy outright bans certain tools to be used, and that also gets ignored, because the banned tools work better. Anarchy is always more appealing isn’t it? Either way, the point is that the actual state of your dev environment isn’t what your policy says it is.
This used to be a manageable problem when the tools were autocomplete with a chat window, or a full blown IDE, but that’s not what these tools are any more.
What happened in April
On April 3, 2026, security researcher Aonan Guan, working with Johns Hopkins collaborator Zhengyu Liu, disclosed a class of attack called “Comment and Control.” The way it works is that someone from the outside, a random contributor with no special access to a given code repository can make a pull request, and in the title of said pull request they write instructions for coding agents to execute. Anthropic’s Claude Code Security Review, Google’s Gemini CLI Action, and GitHub’s Copilot Coding Agent each executed those instructions resulting in each of these agents to exfiltrate the repository’s secrets — API keys, GitHub tokens, cloud credentials back through GitHub itself. No callback URL, no anomalous outbound network traffic.
Total cluster.
That same month, Microsoft disclosed CVE-2026-25592 and CVE-2026-26030 in Semantic Kernel which identifies prompt injection paths that produce remote code execution in agents built on the framework. Cursor’s MCP configuration file handling produced CVE-2025-54135, allowing remote code execution without user approval. GitGuardian’s 2026 State of Secrets Sprawl report found over 24,000 unique secrets sitting in MCP configuration files on public GitHub, with more than 2,100 confirmed valid credentials.
You get the point.
This isn’t a future risk. This is the current state of the tools your developers are running today.
Why your governance program can’t see this
The standard model risk framework was built for systems that get deployed once, reviewed once, and changed under or within a change control framework. An AI coding agent doesn’t behave that way.
The model itself is governed by the vendor. But more importantly, the agent’s behavior is governed by its configuration, the skills it has installed, the MCP servers it connects to, the hooks that run before and after its actions, the system prompts that shape its instructions, and the plugins your developer added last Tuesday because they read about them on X.
Here’s the rub: every one of those configuration elements changes what the agent can do, what data it can see, and what actions it can take in your environment.
Most of them sit on the developer’s machine.
None of them are inventoried.
None of them are reviewed before installation.
None of them show up on the model risk file your AI governance committee approved last quarter.
To state this plainly, when it comes to AI, the configuration surface is the governance surface, and almost no one is looking at it.
Three moves for dev environments specifically
First, get visibility before you write policy.
Ask your engineering leadership some direct questions: which AI coding agents are in use, with what configurations, on which projects, and with what level of access. The answer will be incomplete, which is itself an answer worth knowing.
And yes, this is the same quote from last week, and it will likely be a quote from the future but,“You can’t govern what you can’t see, and the configuration of these tools is what you most need to see right now.”
Shew. Sorry about that. Let’s continue.
Second, treat agent configurations as discrete components to be change-controlled.
The MCP servers, the installed skills, the plugins, etc. are not productivity features, they’re privilege grants.
A developer adding a new MCP server to their Claude Code or Cursor setup is functionally giving an external code path access to whatever the agent can touch. That needs to live inside your existing change management process, not outside it. The tooling to enforce this is immature. The principle isn’t.
Third, narrow the blast radius before you negotiate with the vendor.
The vendors will get to enterprise controls eventually. Anthropic, Google, GitHub, and the rest are working on it, and the pace is improving; but “eventually” is not a control. In the meantime, scoped credentials, ephemeral tokens, network egress controls, and read-only access to high-sensitivity repos are all things you can and should do today. This can be done with tools you already own. The principle is the same one you apply to any over-permissioned account: shrink what it can reach until the agent’s compromise is survivable.
The key takeaway for all this is that the agent in your dev environment is not the chatbot it was eighteen months ago! It’s a configurable piece of automation with credentials, network access, and execution authority. Govern it like one — or accept that you have already made the choice not to.