前置治理与实时拦截如何互补?

我自己踩过一次坑才想明白这个道理：智能体上线后才急着加拦截，基本等于在漏水的船上装警报器——响得挺欢，水还是往里灌。

前阵子看到 Sentra 拿到 1.5 亿美元 C 轮融资，Capital One Ventures 领投，老股东跟投，累计融了超过 2.5 亿美元。新闻本身不稀奇，真正让我停下来琢磨的是它押的那句话：智能体的风险不在它会不会说错话，而在它能碰到哪些数据。这个判断我特别认同。

因为我以前就默认，在每次调用时做实时检查就够了。哪次越界拦哪次，多直接。后来发现不是这么回事：实时检查得先看得见完整上下文，可智能体执行的是跨系统、多步骤的任务链，检查点很容易只看懂一半；更麻烦的是底层权限如果本来就宽，那拦截就变成了在出口处一遍遍扑火，正常的业务请求也跟着被误伤，同事天天来问你为什么这个也被挡了。

Sentra 的思路是反过来，先治理再放行。智能体上线之前，先把散在云、SaaS、本地环境里的敏感数据找出来分好类，把人类身份和 AI 身份的权限都收到合理范围，把数据的流向和血缘摸清楚。这时候实时检查才站在一条干净的权限基线上，而不是被一堆过度授权拖着跑。

我后来把它理解成两个问题：前置治理回答"谁本来就不该拿到"，实时检查回答"这一次调用是不是异常"。它们不是二选一，是先后和分工。前者管的是存量，后者管的是当下。

顺带说个采购上的体会。融资新闻只能当背景，真正要问的是能力落到什么细节——能不能覆盖非结构化数据，人类身份和 AI 身份能不能分开管，发现过度授权之后怎么联动修复，一次多步骤任务的数据接触链能不能还原，处置动作能不能回滚。还有一句我觉得最关键：增长率、防护效果这些都属于厂商口径，得自己搭个真实数据环境跑概念验证，别只看演示。

当然前置治理也有前提。你要是自己都不知道敏感数据存在哪，工具再强也使不上劲。所以我现在更愿意把这事往前挪，在智能体立项那会就把数据访问清单、权限基线、审计要求写进方案里。等它跑起来再补，真的会很被动。