At a Fortune 100 bank, I watched a coding agent open a routine session on a payments service. Before the developer typed a word, the agent had read the repository, including the .env file. Production database credentials had entered the agent’s working context, potentially exposing them to a model provider the bank had never assessed. Whether the credentials left the environment depended on controls nobody had verified. Nothing malicious happened. The agent did what it was built to do. That is the problem.
My argument is simple. AI coding-agent vendors and their downstream dependencies form a supplier ecosystem, not just another developer tool. They need the same four control disciplines applied to other privileged suppliers. Govern vendor terms and downstream dependencies. Limit the secrets they hold. Approve the servers they connect to. Restrict where they can send data. Much of this builds on existing controls, though an enterprise may need a governed gateway or platform service. It requires procurement, security and engineering to recognize a supplier when they see one.
In May, I wrote about how agentic AI is rewiring the SDLC. This is the security half of that argument.
Adoption has outrun control
On Aug. 28, OpenAI told SpaceX, Cursor’s new owner, that it intends to stop supplying models to Cursor, with Nov. 12 proposed as the cutoff. Cursor CEO Michael Truell said OpenAI models carry about 5 percent of its traffic, DevOps.com reported, so the operational risk is small. The governance lesson is not. Enterprises that standardized on Cursor learned they depended on a downstream model supplier whose terms they did not directly control and a change of ownership they had not planned for.
That gap is now the norm. Coding agents are developers’ most common AI use, and investment is accelerating. Governance is not keeping pace, and emerging evidence of credential exposure underscores the gap.
Figure 1. Rapid AI coding-agent adoption exposes gaps in enterprise governance and credential security. Sources: Stack Overflow, McKinsey State of AI, BCG, McKinsey AI Trust, GitGuardian, Trend Micro.
Vipin Jain
The agent was bought as a seat and installed as a supplier
What I see most often is a category error. The coding agent was bought as a seat and installed as a privileged integration. Within its assigned permissions, it can read repository content, encounter credentials, invoke tools, access networks and connect to Model Context Protocol (MCP) servers. A contractor with that access would go through vendor risk review. The agent went through a one-line install.
Drawn as a supply chain, the developer stack looks different. The agent sits between your code and direct and downstream dependencies you may not have assessed: model providers, plugin marketplaces, MCP registries, package managers and the open internet. Each can be acquired, compromised or switched off. Verizon’s 2026 DBIR finds third parties involved in 48 percent of breaches, and source code is the data most often sent to external generative AI.
Figure 2. Every external connection creates a dependency requiring governance.
Vipin Jain
Four controls were never applied
Across the programs I advise, the exposure lands in the same four places.
- Contract. At a healthcare payer, the agent vendor switched model providers mid-contract. No clause covered it, because the seats had been bought on a corporate card below the procurement threshold. No one had asked where code would be processed or what happens on a change of control.
- Secrets. At the bank, credentials reached the agent’s context because the required access restrictions were not configured; that alone does not establish external transmission. Claude Code’s managed settings, for example, can deny reads of .env files in a way developers cannot override. Nobody had configured them because nobody owned them. Gartner predicts that by 2028, a quarter of enterprise security breaches will trace back to AI agent abuse rooted in unmanaged machine privileges and legacy credential practices.
- Servers. At a specialty retailer, developers installed 23 MCP servers in one quarter. Security had approved none. Two could write to the CRM. My rule is simple: the team accountable for the underlying data approves its MCP access, while platform security verifies server provenance and enforces permissions before any agent connects. The retailer had it backward: each server belonged to whoever installed it. Astrix found late last year that 53 percent of open-source MCP servers rely on long-lived static keys or tokens. In June, CSO Online described Mitiga research showing how one malicious npm package can rewrite an agent’s MCP configuration and harvest its tokens. Anthropic deemed it out of scope because it requires code the user chose to run. That is a fair vendor position. It also means the control is yours. Few of the MCP servers in use at most enterprises were built by the team that owns the underlying system; most come from vendors, partners or public registries. Allow only security-assessed, approved servers; verify provenance, enforce least privilege and monitor supported interactions through a centrally governed MCP gateway.
- Egress. On a state Medicaid program, the build environment where agents ran could reach any public endpoint. This July, an autonomous agent in OpenAI’s own evaluation sandbox exploited a zero-day in one of its permitted egress paths, a package-registry cache proxy, and reached Hugging Face’s internal systems. If a frontier lab’s allowed path became the way out, an unrestricted build network is an open door. In late October, CIO.com reported two more containment lapses at OpenAI and Anthropic. The fix is unglamorous: restrict shell execution, isolate agent runtimes, govern MCP connections through an approved gateway and enforce default-deny network egress. Every AI-initiated change should pass through verified CI/CD gates, with rate limits, spending controls and an emergency stop.
The failure sits between functions, and attackers have found it
None of these is a model failure. Procurement saw a low-cost seat. Security reviewed the vendor, if anyone did, but not the plugins, servers and model providers behind it. Engineering saw a productivity tool. Each function did its job, and the agent fell between all three.
The exposure is measurable. In IBM’s 2026 Cost of a Data Breach report, unapproved AI tools figured in 43 percent of incidents in its studied breach population, more than double the previous year. Among organizations reporting breaches involving AI models or applications, 92 percent lacked what the study classified as proper AI access controls. The average breach now costs $4.99 million, a record.
Attackers now target the same seams. On Sept. 18, CSO Online reported Plugin4Shell, a zero-click remote code execution flaw in the plugin systems of Codex, Claude Code, Gemini CLI and Copilot. Anthropic and OpenAI have patched. GitHub’s mitigation was reported as incomplete at disclosure, and Google deprecated Gemini CLI rather than patch it. In April, Vercel disclosed a breach that entered through Context.ai, a third-party AI tool an employee had connected. In August, the self-spreading npm worm GitGuardian tracks as ChainDrop planted a Claude Code SessionStart hook and a VS Code task in infected projects, so the malware ran the moment a developer opened the repository or started an agent session. The attack surface is the update channel, the plugin, the connected tool and the network path. That is supply chain risk, and CIOs already have a playbook for it.
Regulators already treat this as third-party risk
Few rules name coding agents. Few need to. Existing third-party and software supply-chain obligations can apply, depending on the regulated entity, service and deployment context.
| Regime | What it already requires | What it means for coding agents |
| U.S. banking: interagency third-party guidance (2023); a September 2026 proposal would loosen it, but the 2023 text applies until the proposal is final | Due diligence, contract terms, monitoring and exit planning, even when negotiating power is limited | An agent bought outside procurement skipped every stage |
| NYDFS Part 500 | Third-party provider policy and contract protections; asset inventory since November 2025 | Agents and MCP servers belong in the inventory and the vendor file |
| EU DORA, Articles 28 and 30 | ICT-contract register, processing-location notice and termination rights; additional audit and exit provisions for critical or important functions | Assess model or subcontractor changes against contractual notice, materiality and exit requirements |
| SEC Regulation S-K Item 106 | Disclosure of cybersecurity risk-management and governance processes, including material third-party risk | Material third-party cyber dependencies should be understood; Item 106 does not require a line-item agent inventory |
| Federal agencies: OMB M-25-22 and M-26-05 | Applicable federal AI acquisition, data-use and software-inventory requirements under separate OMB policies | Apply relevant provisions to covered agency acquisitions and deployment contexts |
| EU Cyber Resilience Act, Article 14 | Manufacturers of covered digital products give 24-hour early warnings for actively exploited vulnerabilities and severe product-security incidents (from Sept. 11, 2026) | An agent-enabled pipeline incident may affect covered products; CRA reporting is not automatic for every internal compromise |
The common thread is inventory, contract terms and exit rights. An agent bought outside procurement can bypass all three.
Standards and vendors have moved; procurement has not
Over 15 months, incidents and controls arrived side by side. The OWASP Top 10 for Agentic Applications lists agentic supply chain vulnerabilities as ASI04. The Coalition for Secure AI recommends signature verification and a central inventory for MCP servers. CISA, the NSA and four allied agencies, in Careful Adoption of Agentic AI Services, warn against third-party components with excessive permissions. Vendors are shipping matching controls, from Salesforce’s MCP Risk Scores to Okta’s newly announced Shadow AI Agent Discovery for Endpoints.
The analyst market reached the same conclusion from the buyer’s side. Gartner’s first Magic Quadrant for Enterprise AI Coding Agents, published in May, named Anthropic, Cursor, GitHub and OpenAI as Leaders. In the announcement, analyst Philip Walsh listed governance, pricing, support, commercial maturity and market durability alongside model quality as tests for long-term commitments. Market durability is a procurement test, not a developer one. Three months later, one of those Leaders was losing a model supplier.
In October, the firm went further, and it changed one piece of my advice. At its IT Symposium in Orlando, Gartner named the AI coding agent harness one of its top strategic technology trends for 2027 and said CIOs should give ownership of it to a dedicated platform team. In every program above, the controls existed somewhere. What was missing was one owner. A category with a Magic Quadrant is enterprise software. Buy it that way, and give it an owner.
Here is what that platform team builds. Next year the most demanding customer of your internal platform will be coding agents, not developers. An enterprise-governed harness is the versioned policy and configuration that adapts the vendor-provided agent runtime to your environment: rules files, skills, enforcement hooks, verification gates, tool permissions and sandboxes. The platform team supplies approved tools, MCP allowlists, sandboxes and scoped credentials, and developers declare the harness they need as versioned configuration. That design answers the Cursor problem directly. A declared harness makes an agent or model change more manageable, provided compatibility and regression tests pass; a well-tailored harness may also improve results on a midtier model. An organization that owns its harness can change suppliers. One that rents it cannot.
The harness must also govern what the agent produces. AI-generated changes should follow the same trusted delivery path as human-written code: automated security testing, dependency verification, code review, build provenance and controlled production deployment.
5 moves for the next 90 days
The fix begins with supplier-risk review and configuration work, not necessarily a new platform purchase. Give all five moves to one accountable owner, the platform team that runs your coding agent harness, while procurement, security and infrastructure retain clear decision rights and operational accountability. Sequence matters: inventory first, because every other move depends on knowing what is installed.
- Inventory, owned by the CIO and procurement. List every coding agent, plugin and MCP server and who installed each. Done when every approved tool has an owner, a supplier or risk-acceptance record, and its models and downstream dependencies documented.
- Contract, owned by procurement and legal. Add model-provider disclosure, change notice, change-of-control and exit terms. Done when each enterprise-approved agent has documented contractual terms or an approved open-source/self-hosted exception, downstream visibility and a tested exit plan.
- Secrets, owned by the CISO. Deny agent reads of .env and credential files through managed settings and move secrets to a vault. Done when agents hold only short-lived, scoped credentials.
- Servers, owned by platform engineering and security. Maintain an internal MCP registry and mediated access to security-assessed, approved servers. Done when every approved server has verified provenance, a named owner, scoped permissions and activity logs, and write access to systems of record goes through change control.
- Egress, owned by infrastructure. Default-deny outbound traffic across agent shells, tools and build runners; run agents in isolated sandboxes and govern release promotion through CI/CD. Done when only explicitly approved destinations are reachable, exceptions are monitored and isolation is tested.
Two details make the difference. Reconcile the inventory against expense reports, not just license records; card statements usually tell the truer story. And write the contract assuming change: the Cursor notice proposed 76 days, and the next one may run shorter.
The takeaway
The most common mistake I see this year does not look like one. Teams are adopting coding agents fast, and they are right to. But they are buying a supplier ecosystem as if it were a developer tool, and governing it like one. Governed properly, a coding agent can earn greater autonomy with scoped identities, approved dependencies, controlled execution and a trusted route to production.
Put three questions to your team this week.
| Ask your team | A good answer sounds like |
| Which AI coding tools hold repository, secret or network access today, and does procurement know? | A complete list matched to contracts and named owners |
| Which MCP servers and plugins are installed in engineering, and who approved each? | An approved registry with provenance, named owners, scoped access, monitoring and change control for writes |
| If our coding agent’s model provider changed tomorrow, what is our contractual and technical fallback? | A notice clause, a named alternative provider and an exit path someone has tested |
You would never give a contractor unrestricted production access on day one. Coding agents should meet the same standard.
This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.