As enterprises shift from static LLM chatbots to autonomous AI agents, traditional compliance and governance frameworks are breaking down. Gartner predicts that by 2027, 40% of enterprises will demote or decommission their autonomous AI agents. The reason won’t be technical failure; it will be a governance failure. Gartner Senior Director Analyst Shiva Varma attributes this to “binary governance”: the tendency to treat agents as either fully locked down or fully trusted, with nothing in between. That framing is the core of the problem.
AI agents cannot be governed uniformly. Most organisations today swing between two flawed extremes of total corporate bans on one hand and a Wild West on the other. Neither works. Even when IT enforces a full ban, Shadow AI persists and developers want to build and solve problems. So when governance feels overly bureaucratic, they route around it and reach for untested tools to keep moving. A total ban doesn’t eliminate risk. It buries it.
The deeper issue is that industrial-era controls were never designed for software that operates at machine speed.
Governing agentic software development environments
Real control starts with recognising what an agent actually is. Many teams treat agents as something close to magic and overlook the ordinary software components that determine how they behave.
Every autonomous AI agent is built from a familiar stack. A foundation model, MCP servers (Model Context Protocol) that connect the agent to company data and external systems, plugins that extend its capabilities, and skill files that instruct it how to behave. Each of these is, at its core, a software artifact, and each carries its own software supply chain risk. That has a few practical implications for IT leaders.
- MCP servers can open a door into your environment. They can be downloaded like any other software package, and if they aren’t vetted, the risk lands directly inside your systems. Recent JFrog Security Research surfaced exactly this kind of risk in mcp-run-python, including a Server-Side Request Forgery flaw (CVE-2026-25904) and a lack-of-isolation vulnerability (CVE-2026-25905) that together could lead to a complete MCP takeover.
- Plugins compound the problem. Different agents need different plugins (an OpenAI plugin won’t work inside Microsoft Copilot, for example), so companies end up juggling multiple variations of the same capability. One bad plugin in that mix is enough to exfiltrate sensitive data.
- Skills quietly shape agent behaviour. Developers pull skill files from community sources, and a corrupted skill can change how an agent operates without setting off obvious alarms.
A layered approach to governing and securing software components
The race to deploy enterprise AI agents cannot be won with a binary mindset. Heavy-handed approval chains applied to every workflow will stifle innovation, and unmonitored agents at scale invite systemic disaster.
To scale AI safely, organisations need a layered approach to governing and securing every software component that goes into an agent: packages, binaries, MCP servers, skills, and dependencies. A proper system of record lets teams curate incoming components, scan them before use, enforce policies at the boundary, and roll back instantly when something goes wrong.
Agents, though, introduce a problem that traditional controls weren’t built for: a wider attack surface that moves at machine speed. A high-autonomy agent can chain tool calls, access data, and execute code hundreds of times a minute. Static intake policies and manual approval gates cannot keep up. Those methods still make sense for low-autonomy tasks, but agents need dynamic policy enforcement at runtime, not just at intake.
High-autonomy agents are a different problem. When an agent can make hundreds of decisions per minute – chaining tool calls, accessing data, executing code – static intake policies cannot scale. These agents require dynamic enforcement at runtime: the ability to detect anomalous behaviour the moment it occurs and intervene before the damage spreads.
Think of it as a circuit breaker. When behaviour turns anomalous, the system should be able to revoke access to a compromised skill, disconnect an untrusted data context, or block a specific tool call the moment it happens. Waiting on a manual review process all but guarantees the agent has already moved on.
Moving beyond ‘one-size-fits-all’
Rigid, uniform governance is a guaranteed path to failure. Four steps will help security and engineering leaders shore up their systems now:
- Take inventory of what’s already running. Most enterprises can’t fully account for the AI agents in their organisation, let alone the MCP servers, plugins, and skill files powering them. You can’t govern what you can’t see.
- Treat AI components as software artifacts. MCP servers, skill files, and plugins aren’t configuration. They’re code, with the same supply chain risks as any open-source dependency. They deserve the same vetting, scanning, and provenance tracking you’d apply to any third-party library.
- Classify agents by autonomy level and calibrate controls accordingly. Define what “high-autonomy” means for your organisation and build a tiered policy framework around it. Runtime enforcement matters most for high-autonomy agents. Start with your most sensitive systems and expand from there.
- Make governance fast enough that developers won’t route around it. Shadow AI is a friction problem more than a defiance problem. If approving a new MCP server takes two weeks, developers will find another way. Automated scanning paired with clear policy enforcement is the only approach that keeps pace with how AI development actually moves.
The enterprises that scale AI safely will be the ones that calibrate governance to the actual risk of each agent, maintain a system of record that enforces policy at every boundary, keep full visibility into every component, and can act the moment something goes wrong. Strictness and permissiveness are the wrong axes to optimise on.
This article was submitted by JFrog.