思想领袖
One Policy，千Agents：为什么企业AI治理在规模上中断
在 Google 上的首选来源中添加 Unite.AI
围绕自主AI agents的通过，大部分对话都以治理为中心，将其作为一个决定性的挑战，这是理所当然的。 盖特纳最近预测，40%的企业到2027年将降级或取消其自主的AI agents — — 这并不是因为技术失败，而是因为他们的治理。 Gartner高级局长分析师Shiva Varma认为，罪犯是“二进制治理”
现在，许多组织强烈要求要么全面禁止人工智能工具，要么部署没有足够护栏的agents。 两者均没有很好的尺度。 即使IT在AI工具之外禁止，Shadow AI仍然会发生。 开发者自然想要构建和解决问题；如果治理感到过度官僚主义，他们会绕过控制并使用未经测试的工具来保持事物的移动。 相反，看守设施不足使各组织面临安全、合规和业务风险，这些风险随时间推移而增加。
挑战在于AI agents不能采用静态的一刀切方法统一管理。 一刀切治理的时代即将结束，因为这些系统在基本软件、能力、接入水平和自主程度方面各不相同，因此它们的风险状况并不相同。 将静态，工业时代的控制应用于机器速度软件是行不通的。 有效的治理将取决于各组织了解每个agent背后的软件供应链，并使控制与其推出的风险相一致。
管理代理软件开发环境
真正的控制意味着有效管理所有进入agent的软件元素。 许多团队错误地认为这些agents“可靠和可信”，忽略了影响其功能和安全的标准要素。
每个自主的AI agent都是通过一个可识别的堆栈构建的：一个基础模型，MCP服务器(Model Context Protocol)将其连接到公司数据和外部系统，扩展其能力的插件，以及指示其行为方式的技能文件。 信息技术领导人需要铭记：
- AI agents是软件生态系统：他们依赖于包括Models,MCPs，工具，插件，技能，以及开源软件的标准设置。
- MCP服务器可能很危险：它们将agents连接到公司数据，可以像其他软件一样下载。 他们可能会让黑客进入你的系统。 例如，最近的JFrog安全研究凸显了mcp-run-python内部的这些精确的软件供应链风险，包括服务器-Side请求伪造(SSRF)缺陷(CVE-2026-25904)和缺乏孤立脆弱性(CVE-2026-25905)，这会导致MCP完全接管。
- 插件可以添加更多的风险：不同的agents需要不同的插件(例如，OpenAI插件不会在Microsoft Copilot中工作)，意思是公司经常在单个不良插件可以偷取敏感信息的地方对多个变体进行比对。
-技能定义agent行为：这些指令文件告诉agent如何工作。 因为开发者从社区源头拉出它们，一种腐烂的技巧可以悄悄地改变agent的运作方式。
- 开源软件风险：通过代理编码构建的解决方案的所有功能都以开源二进制的杠杆来提供功能。 编码agents同样可以轻松地利用恶意包而不是安全包而不意识到风险。
许多团队并不知道这些问题的存在，各组织仍在管理基于信任的软件依赖性，而不是彻底检查。
记录制度在有效AI治理中的作用
以昨天的心态，在每个工作流程中强制实施单体的，重手的手动审批链会扼杀创新，而让agents无人监控则会造成不必要的风险。
为了安全地扩大AI的规模，各组织必须采取分层的方法来管理和保障软件组件，包括软件包、二进制、MCPs、技能和依赖性。 通过建立记录系统，企业可以管理所有使用的部件，在使用前扫描所有部件，在开发生命周期的适当时间执行政策，并保持立即退缩的能力。 因此，当下一次脆弱性被披露时，“我们是否暴露？”的答案将在几分钟内而不是几天内提出。
然而，AI agents引入了更宽，更快速移动的攻击表面。 因为高自主agents每分钟可以做出数百个决定，连锁工具调用，访问数据，执行代码比传统摄入控制能够保持速度更快。 虽然前期审查和批准程序仍然发挥重要作用，但它们无法保证自动以机器速度运行的系统的安全。
这些agents在运行时需要动态执行，能够发现异常行为发生的时刻，并在损害扩散前进行干预。 把它当作一个断路器：取消对一个受损技能的访问，断开一个不可信的数据上下文，或者屏蔽一个特定的工具，在某事出错时叫。
超越“一体行动”
严格统一治理是保证失败的途径。 随着agent部署的加速，领先的窗口正在关闭，治理债务复合体也随之加速。 因此，这里有四个步骤，安全和工程领导人现在可以帮助巩固他们的企业系统：
- 清点已经发生的事情。 大多数企业无法在组织中充分说明AI agents，更不用说MCP服务器、插件和为它们提供动力的技能文件了。 在评估你的风险或治理任何事情之前，你需要知道什么是存在的。
- 将AI组件视为软件文物。 MCP服务器，技能文件和插件并不是配置——它们是代码，与任何开源依赖性都具有相同的供应链风险。 使用同样的审查、扫描和出处追踪
- 按自主级别对agents进行分类，并相应校准控制。 界定“高度自治”对贵组织的意义，并围绕它建立一个分级政策框架。 高自主agents需要运行时间强制，而不仅仅是接收检查。 从你最敏感的系统开始向外工作
让治理速度足够快，影子AI是一个摩擦问题。 如果批准一个新的MCP服务器需要两周时间，开发者会找到另一种方法。 具有明确政策执行的自动扫描是按AI开发实际移动速度进行测算的唯一模式。
如果治理反映每个agent带来的实际风险，而不是对所有这些风险一视同仁，那么治理就更加有效。 将前进的企业将是那些符合每个agent现实的治理，辅以一个记录系统，在每个边界执行政策，为每个组成部分提供能见度，并使团队能够在出错时作出反应。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Thought Leaders
One Policy, Thousands of Agents: Why Enterprise AI Governance Breaks at Scale
Add Unite.AI to your preferred sources on Google
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.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.