Obsidian Security推出运行时策略引擎，管控AI智能体的操作

Obsidian Security推出了运行时策略决策引擎，旨在让企业能够在AI智能体执行操作前，管控它们在业务应用中的行为。此次发布扩展了该公司的智能体安全平台，新增MCP安全代理、策略决策API，以及对编码工具和嵌入第三方软件的智能体的支持。

此次发布旨在解决普通访问控制无法彻底应对的问题：智能体可能持有有效凭证，并使用获准访问的应用，却仍试图执行不当操作。例如，有权读取客户记录，并不意味着也有权将这些记录导出到外部目的地。

Obsidian的做法是依据集中管理的策略评估拟议操作，同时考虑智能体背后的人员、其雇佣关系和权限、涉及的应用，以及客户提供的数据分类。随后，连接的执行控制点会允许或阻止该操作；在支持此功能的情况下，也可以要求审批。

从发现智能体到管控其操作

智能体发现可以回答系统中有哪些工具，以及这些工具能够访问什么。治理措施可以减少不必要的权限，或识别存在风险的配置。运行时策略则要解决剩下的问题：一个已获授权的智能体此刻应该被允许执行什么操作？

Obsidian的公告涵盖员工操作的智能体，以及随企业已在使用的软件一同提供的智能体。其扩展后的发现和治理功能涵盖Salesforce Agentforce、Databricks、GitHub、Microsoft 365、Snowflake、ServiceNow和Workday。

这些属于不同的控制面。在SaaS应用中发现智能体，并不代表该应用中的每项操作都会因此被拦截。运行时执行控制取决于受支持的集成，以及操作经过的控制点。

该公司还新增了对OpenAI Codex的运行时策略支持，并保留了原有的编码智能体控制功能。公告指出的风险包括破坏性命令、凭证暴露，以及读取超出项目预定范围的数据——这些操作可能在原本合法的开发会话中发生。

Knowledge Graph提供缺失的上下文

网关可以检查请求，但仅凭请求本身，可能无法了解其背后的权限依据。要作出有效的安全决策，可能需要确认调用账户属于员工还是承包商、雇佣关系是否已经终止，以及该账户在目标应用中实际持有哪些权限。

Obsidian的Knowledge Graph架构将人员、账户、应用、令牌、授权及其关系联系起来。该公司介绍称，它会将来自管理API、活动流和集成的信息统一整理到一个通用模型中，并为实体及关系设置版本，以记录它们随时间发生的变化。

这种结构有助于追踪跨多个系统的访问情况，而不是孤立地检查每个账户。智能体表面上的角色可能范围有限，但令牌或继承的授权可能使其在其他地方拥有更广泛的访问权限。将这些关系关联起来，可以让策略引擎更有依据地判断特定操作是否符合组织规则。

客户可以添加自己的上下文信息，包括分类标签。因此，策略可以区分普通文件与企业标记为高度敏感的文件，而不必仅依赖安全供应商对机密数据的一般定义。

决策如何转化为执行控制

该架构将决策与执行分开。在Obsidian的运行时引擎说明中，执行控制点会暂停拟议操作，提交操作详情供评估，并根据返回的决策及理由采取相应措施。

新的策略决策API将这一模式扩展到由客户运营的网关、智能体运行框架和工作流。企业可以保留现有基础设施，同时向Obsidian请求结合上下文作出的判定。随后，客户的执行控制组件必须在操作继续之前落实该判定。

Obsidian还介绍了一种标记模式，可在阻止操作之前，针对真实流量测试策略匹配情况。决策记录会保存智能体、调用人员、工具、参数、结果和匹配的策略，让安全团队能够调查某项操作获准或被阻止的原因。

审批支持的适用范围小于整体的允许或阻止架构：该公司目前的文档称，只有在操作执行前运行的Claude Code策略支持要求审批。因此，在为混合使用多种智能体的环境设计控制措施时，集成层面的功能尤为重要。

MCP代理让AI客户端无需持有应用令牌

MCP 安全代理负责管理 AI 客户端与受支持的业务应用之间的连接。模型上下文协议（Model Context Protocol，简称 MCP）为智能体提供了一种标准方式，使其能够调用外部服务器提供的工具。Obsidian 在客户端与应用的 MCP 服务器之间设置了一道策略检查。

其产品文档介绍了如何将供应商的 MCP 直接 URL 替换为由 Obsidian 管理的端点。用户通过应用供应商的授权流程授予访问权限；AI 客户端接收由代理签发的令牌，而不是自行存储应用的访问令牌。

代理会将会话与用户、其应用账户以及相关租户关联起来，例如某个特定的 Salesforce 组织或工作区。它会在转发工具调用之前进行检查，并记录调用是获准还是被拦截。Obsidian 表示，这一机制在用户现有的应用权限范围内运行，不会通过共享服务账户增加权限。

公告还提到与 Cloudflare 及其 MCP Server Portal 合作。双方旨在将网关在流量路径中的位置，与 Obsidian 提供的身份、应用和数据上下文结合起来。

为什么操作级控制至关重要

对于部署智能体的企业而言，实际挑战在于既要允许智能体完成有用的工作，又要遏制后果严重的错误。一刀切的禁令可能会彻底阻断工作流；范围明确的决策则可以允许常规读取操作继续进行，同时阻止未经授权的数据导出，或要求对破坏性更改进行审核。

Obsidian 正在将这些决策纳入一个共享策略层，覆盖受支持的工具和执行控制点。其价值取决于底层访问上下文的质量，以及受控路径的完整程度。随着智能体承担更多运营职责，能够在执行前说明并落实决策，将日益成为企业安全的重要组成部分。