一套政策、數以千計的智能體:為何企業 AI 管治在規模擴大時失效
One Policy, Thousands of Agents: Why Enterprise AI Governance Breaks at Scale
企業 AI 管治在規模擴大時會因一刀切政策而失效,因為智能體的軟件組成、自主程度和風險各不相同。Gartner 預測,到 2027 年,40% 企業會降級或停用自主 AI 智能體,原因是管治失效而非技術失敗。企業應盤點並檢查模型、MCP、插件、技能檔案等組件,並在執行期間動態偵測異常、即時介入。
Much of the conversation around the adoption of autonomous AI agents has centered on governance as a defining challenge, and rightfully so. Gartner recently predicted 40% of enterprises will demote or decommission their autonomous AI agents by 2027 – not because the technology failed, but because their governance did. The culprit, according to Gartner Senior Director Analyst Shiva Varma, is “binary governance”: treating agents as either completely locked down or fully trusted, with nothing in between.
Right now, many organizations gravitate towards either imposing total bans on AI tools or deploy agents with inadequate guardrails. Neither approach scales well. Even when IT bans outside AI tools, Shadow AI still happens. Developers naturally want to build and solve problems; if governance feels overly bureaucratic, they’ll bypass controls and use untested tools to keep things moving. On the contrary, insufficient guardrails expose organizations to security, compliance, and operational risks that multiply over time.
The challenge is that AI agents cannot be governed uniformly using a static one-size-fits-all approach. The era of one-size-fits-all governance is ending because these systems don’t share the same risk profile, as they differ in their underlying software, capabilities, access levels, and degrees of autonomy. Applying static, industrial-era controls to machine-speed software is not going to work. Effective governance will depend on organizations understanding the software supply chain behind each agent and aligning controls to the risks it introduces.
Governing Agentic Software Development Environments
Real control means effectively managing all the software elements that go into the agent. Many teams mistakenly view these agents as “reliable and trusted,” overlooking the standard elements that influence their functionality and security.
Every autonomous AI agent is built from a recognizable stack: a foundation model, MCP servers (Model Context Protocol) that connect it to company data and external systems, plugins that extend its capabilities, and skill files that instruct how it behaves. IT leaders need to keep in mind:
- AI agents are software ecosystems: They rely on a standard setup that includes Models, MCPs, tools, plugins, skills, and open-source software.
- MCP servers can be risky: They connect agents to company data and can be downloaded like any other software. If they’re not vetted, they could let hackers into your system. For example, recent JFrog Security Research highlights these exact software supply chain risks within mcp-run-python, including a Server-Side Request Forgery (SSRF) flaw (CVE-2026-25904) and a lack of isolation vulnerability (CVE-2026-25905) that can lead to a complete MCP takeover.
- Plugins can add more risk: Different agents need different plugins (e.g., an OpenAI plugin won’t work in Microsoft Copilot), meaning companies often juggle multiple variations where a single bad plugin could steal sensitive information.
- Skills define agent behavior: These instruction files tell the agent how to work. Because developers pull them from community sources, a corrupted skill can quietly change how an agent operates.
- Open source software risks: Underlying all the functionality from the solutions built using agentic coding is the leverage of open source binaries to deliver the functionality. Coding agents can just as easily leverage malicious packages instead of safe ones without realizing the risk.
- Visibility is key: Many teams don’t know these issues exist, leaving their agents highly vulnerable. Organizations are still managing software dependencies based on trust instead of thorough checks.
The Role of a System of Record in Effective AI Governance
The race to deploy enterprise AI agents cannot be won with a yesterday’s mindset. Imposing monolithic, heavy-handed manual approval chains across every workflow stifles innovation, while leaving agents unmonitored creates unnecessary risk.
To safely scale AI, organizations must adopt a layered approach to governing and securing software components, including packages, binaries, MCPs, skills, and dependencies. By establishing a system of record, enterprises can curate all of the components used, scan everything prior to use, enforce policies at the right time in the development lifecycle, and maintain the ability to roll back instantly. So when the next vulnerability is disclosed, the answer to “are we exposed?” is delivered in minutes, not days.
However, AI agents introduce a wider and significantly faster-moving attack surface. Because high-autonomy agents can make hundreds of decisions a minute, chaining tool calls, accessing data, and executing code faster than traditional intake control can keep pace. While upfront reviews and approval processes still play an important role, they cannot secure systems operating at machine speed on their own.
These agents require dynamic enforcement at runtime, with the ability to detect anomalous behavior the moment it occurs and intervene before the damage spreads. Think of it as a circuit breaker: revoking access to a compromised skill, disconnecting an untrusted data context, or blocking a specific tool call the moment something goes wrong.
Moving Beyond “One-Size-Fits-All”
Rigid uniform governance is a guaranteed path to failure. The window for getting ahead of this is closing, and governance debt compounds as agent deployment accelerates. Thus, here are four steps security and engineering leaders can take now to help shore up their enterprise systems:
- Take inventory of what’s already running. Most enterprises can’t fully account for the AI agents in their organization, let alone the MCP servers, plugins, and skill files powering them. Before you can assess your risk or govern anything, you need to know what exists.
- 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. Apply 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 organization and build a tiered policy framework around it. High-autonomy agents need runtime enforcement, not just intake checks. Start with your most sensitive systems and work outward.
- Make governance fast enough that developers (human or agentic) won’t route around it. Shadow AI is a friction problem. If approving a new MCP server takes two weeks, developers will find another way. Automated scanning with clear policy enforcement is the only model that scales at the pace AI development actually moves.
Governance becomes far more effective when it reflects the actual risks presented by each agent rather than treating them all the same. The enterprises that will pull ahead will be those that match governance to the realities of each agent, supported by a system of record that enforces policy at every boundary, provides visibility into every component, and enables teams to respond the moment something goes wrong.

Paul is an experienced IT Security Executive who, as Field CISO at JFrog, works to help CISOs, IT execs and security teams, enhance protection of their software supply chain. Additionally, he advises IT security startups, mentors security leaders, and provides guidance on various IT security trends. Paul also spends his time exploring the latest technologies, DJing, reading, and boating.
來源:Unite.AI · unite.ai