被跳过的那个间隙
企业里关于智能体的安全讨论，长期集中在两个位置。一个是网络与流量层：用网关看住出站请求，判断这次调用是不是越界。另一个是模型与输出层：看住生成内容，判断这句话是不是有害。
但智能体真正的风险不在两端，而在中间那段很短的间隙——从「想好了」到「动手了」。在网关看来，这个动作只是一次格式合规的 API 调用；在输出审查看来，它甚至没有产生任何文本。真正决定后果的，是这次调用本身有没有被授权：谁发起、以什么身份发起、被委托了什么权限、动作落在哪个资源上。
Ory 在 9 月 10 日宣布 Ory Agent Security 正式可用，产品的切入点正是这个间隙。它不是再做一个网关，而是把身份与授权判断放进 Agent 的执行框架内部：在工具动作被执行之前完成评估，放行或拦截，记录决策，并把动作绑定到一个可追责的负责人与委托身份上。
Ory 的底子：一套拆开的身份栈
理解这个产品的定位，需要先看它来自哪里。Ory 是一套用 Go 编写的云原生、API 优先的身份基础设施，按功能拆成若干独立组件：Hydra 负责 OAuth 2.1 与 OpenID Connect 令牌流程，Kratos 负责用户认证与身份管理，Keto 提供 Zanzibar 风格的权限服务，Oathkeeper 是身份感知的反向代理。各组件可独立部署、独立扩容，也可以只用其中一部分。
按官方公开数据，Ory 的身份基础设施支撑超过 32.5 亿个身份、每天 44 亿次事务、超过 3.4 万个生产部署，OpenAI、SAP、ASICS 等公司在生产环境使用。这些数字说明它处理的是「身份」这一层的基础问题，而不是围绕某个模型做插件。
把身份能力延伸到智能体，逻辑上顺理成章：当 Agent 开始以非人类身份访问企业系统，长期有效的 API 密钥就不再合适。Ory 的做法是给每个 Agent 一个自己的身份，权限按其实际需要收窄，并可随时撤销。
四层能力：从决策到留痕
按公开材料，Ory Agent Security 的能力可以拆成四层。
身份与授权层负责判断。它采用 Zanzibar 风格的权限模型（通过 Ory Keto 实现），并遵循 OAuth 2.1 与 OIDC 标准，同时管理人类用户身份与受托的 Agent 身份。这一层的技术含义是：Agent 不再是「某个用户的密钥的延伸」，而是一个可以被单独授权、单独审计、单独撤销的主体。
运行期拦截层负责执行。它评估的工具调用范围包括 shell 命令、文件写入、网页抓取，以及 MCP 交互——也就是模型上下文协议下的工具调用。评估发生在执行之前，结果是放行或拒绝。这一点与事后日志分析有本质区别：前者是控制，后者只是观测。
集成层决定了它能用在哪。按公开说明，它支持 11 个 Agent harness 与 14 个 SDK 框架，其中明确提到 Claude Code、LangChain 与 LangGraph、OpenAI Agents SDK、Vercel AI SDK，也覆盖自建 Agent。支持面的宽度决定了这套控制是否能在企业里统一执行——如果每个团队换一个框架就要换一套权限方案，治理就无从谈起。
审计层负责留痕。所有授权决策与委托链都通过 OpenTelemetry 记录并导出，用于对接企业既有的 SIEM 与安全运营流程，形成不可篡改的审计轨迹。这里的「委托链」是关键词：它记录的是从「拥有这个 Agent 的人」到 Agent、再到子 Agent、再到它们调用的工具，这条链是否完整。
那句被反复引用的问题
Ory 首席执行官 Jeff Kukowski 在发布说明里提了一个问题，大致意思是：智能体在执行时用的是人的凭证，留下的记录却回答不了那个最关键的问题——如果明天你的环境里有个 Agent 做了一次破坏性操作，你的审计日志会说什么？你能指出是哪个人把它跑起来的吗？
这句话把产品的价值主张说得比较清楚。传统应用系统里，「谁做了什么」由登录身份决定，链条是清晰的。智能体把这条链拉长了：人委托了 Agent，Agent 又可能调用子 Agent，子 Agent 再调用工具。中间任何一跳没有记录身份，责任就断在那里。
对开发者而言，Ory 还提供了一条更轻的入口。它把命令行工具与 REST API 暴露为 MCP 工具，Agent 可以自己创建身份、注册 OAuth 客户端、管理关系元组，而不需要人工复制命令。本地可以用一条命令把 Kratos、Hydra、Keto 起起来，无需云账号。这带来的一个实际好处是：权限配置从「写文档告诉别人怎么配」变成「Agent 自己按接口配置」，减少手工环节带来的偏差。
部署形态：先开灯，再关门
产品提供两种部署方式：Ory Network 托管服务，或完全自托管，适用于云、本地机房以及物理隔离环境。对金融、政务这类不能把 Agent 活动交给外部黑盒服务的企业，自托管与物理隔离是必要选项。
推进路径被设计成两个阶段。开始是观察模式：只记录，不阻断，让团队先看清环境里有哪些人、哪些 Agent、哪些子 Agent、哪些工具在活动。之后按自己的节奏进入强制模式，从宽泛的护栏逐步收紧到细粒度权限。官方强调策略可以即时撤销。
这个「先开灯」的设计值得肯定。企业往往不知道自己有多少个 Agent 在跑，也不知道它们各自能碰什么。在缺少清单的情况下直接开启拦截，结果通常是把正常业务也一起挡掉，随后团队会整体关掉策略。先观察再收紧，是比较务实的顺序。
与相邻路线的分工
把 Ory 放进当前 Agent 安全的产品谱系里，位置会比较清楚。
网关路线把控制点放在流量上，优势是集中、易审计，局限是它看不到 Agent 内部的决策过程，只能看到调用本身。可观测性路线把重点放在轨迹上，优势是能还原过程，局限是事后。凭证管理路线解决「用谁的钥匙」，但不解决「这次动作该不该做」。
Ory 选择的是把判断移到动作发生处，并让决策与身份绑定。它与其他路线的关系更像互补而非替代：网关负责网络边界，控制面负责动作授权，可观测性负责复盘，三者拼起来才是一条完整链路。
另一个值得并置的事实是，行业内近期对「框架层静态拦截」的讨论并不乐观。此前多款 Agent 框架出现过严重漏洞，其中一些的成因正是把安全检查写在框架自身的执行逻辑里，攻击者只要绕过检查路径就能得手。内嵌式执行的效率更高，但它同样把信任押在了「框架会老老实实调用检查」这个前提上。这一点在后文的中立思辨里还会展开。
中立思辨
需要辩证看待几件事。其一，策略仍然要靠人写。产品能保证「按策略执行」，不能保证「策略写得对」。如果一条策略允许 Agent 在特定目录内写文件，而那个目录恰好放着凭据，产品不会替你发现这个矛盾。控制面解决的是执行一致性，不解决策略质量。
其二，支持 11 个 harness 与 14 个 SDK 是覆盖面优势，也意味着每引入一个新框架，都要重新验证拦截是否真的生效。拦截点的位置在不同框架里并不一致，验证成本会随技术栈扩张而增长。企业在选型时应把「验证新框架拦截有效性」写进常规流程。
其三，内嵌式执行的信任前提值得推敲。判断逻辑跑在 harness 内部，效率更高、上下文更全，但它与「框架自身逻辑」共处一个执行环境。如果 Agent 的代码执行能力被滥用，控制面自身是否在被保护范围内，是一个需要明确回答的问题。公开材料未展开这一点。
其四，观察模式会带来可观的数据量。记录所有工具调用、身份决策与委托链，并导出到 SIEM，在大型环境里是持续的存储与处理开销。真正上线前需要估算保留周期与成本，否则「先开灯」会变成一笔不小的账单。
其五，厂商立场需要留意。Ory 的主业是身份基础设施，把 Agent 视为「需要一等公民身份的主体」，与它的产品线高度一致；官方同时提供限期的免费体验。这套判断在技术上是合理的，但读者也应意识到它同时是一次市场定位动作。
其六，具体策略语言、执行时的性能开销、定价与商业条款，公开材料未展开说明。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
给团队的一份落地清单
即便不采用这套产品，它指出的顺序也可以直接借用。
先盘点非人类身份：企业现在有多少个服务账号、多少把长期密钥在支撑自动化，其中多少实际上被 Agent 在用。这份清单通常是治理的起点，也常常是最让人意外的一份材料。
把长期凭证换成短期委托：让 Agent 使用与任务绑定的短时效凭证，任务结束即失效。这一步的收益不依赖任何新产品，只需要改造接入方式。
给写操作单独设卡：读操作的风险是泄露，写操作的风险是破坏。两者不应共用一套策略。对外支付、批量删除、配置变更这类动作，值得强制走独立审批。
把委托链写进日志：日志里要能回答「这个动作背后是哪个人的委托」。只记录 Agent 标识是不够的，因为 Agent 会被创建、复制与替换。
先在观察模式跑一段时间：在强制拦截之前，用真实数据检验策略的误报率。这条经验在权限治理领域已经反复被验证——策略上线时的最大成本，从来不是技术实现，而是误拦带来的信任损失。