单租户，无跨客户放大
控制平面在你的机房里只服务你。不存在跨租户凭据泄漏这一类威胁，因为不存在第二个租户。这也让架构显著简化。
Threat model & boundaries
我们能做什么，不能做什么，
以及还没想清楚什么
一份只列优点的安全产品文档，对 CISO 来说是一个负面信号。这一页刻意反过来写：先讲我们自己引入的风险，再讲我们解决的问题，最后列出还没有答案的问题。
Threat #0
AgentPAM 持有通往所有敏感 API 的钥匙
必须最先诚实面对的一条把凭据集中代持，意味着这个控制平面本身成为一个新的高价值目标。这个形状在业界已经演过一次：一个被攻破的中介，等于所有下游被攻破。任何声称「集中托管凭据只有好处」的说法都是不完整的。
私有化部署改变了这条威胁的形状，但没有消除它。 因为控制平面跑在你自己的网络里、且是单租户，「一次攻破波及所有客户」这个 SaaS 特有的放大效应不存在 —— 爆炸半径被限制在你自己的边界内。但在那个边界内，它仍然是你环境中权限最高的组件之一。
根密钥托管在你的 HSM
签名与包裹密钥不以明文离开硬件安全模块。必须支持通过 PKCS#11 使用你自己的 KMS / HSM；纯软件密钥模式会被明确标注为较低保障等级。
broker 自身能否读不到凭据？
能不能做到零知识的凭据设计 —— 让 broker 在注入时也无法读取明文？我们还没有一个满意的答案。
Threat classes
威胁类别与我们的立场
下面每一行都标注了当前状态：已设计 / 待专项 / 明确做不到.
| 类别 | 关键问题 | 我们的立场 | 状态 |
|---|---|---|---|
| 控制平面被攻破 | broker 被攻破 = 它代持的全部凭据泄漏 | 单租户私有化部署把爆炸半径限制在你自己的边界内（无跨客户放大）；根密钥托管在你的 KMS / HSM；凭据零知识设计尚无满意方案。 | 待专项 |
| 时钟漂移击穿短 TTL | 无外部 NTP 时，60–300s 的 Tup 可能刚签发就过期 | 启动时检测集群时钟偏差并告警；定义明确容忍窗；偏差超阈值 fail-closed 并明确报错，绝不静默放行。 | 已设计 |
| Agent 自我篡改 | agent 重写自己的 gate 脚本（已有公开记录） | 任何 agent 能编辑的控制都不是控制。 只有 root 拥有的托管策略、或进程外的 broker 能存活。这正是我们把凭据放在 agent 进程之外的原因之一。 | 已设计 |
| 提示注入 → 被授权的调用 | agent 被劫持后发起一次它有权发起的调用 | 我们不能阻止它。我们把伤害降级、留痕、可撤销。见下节。 | 明确做不到 |
| Rug pull（工具描述变更） | 安装时批准 + 事后无重校验是行业常态，这个缺口已被公开利用（CVE-2025-54136） | 工具描述固定（TOFU）+ 变更时强制重新授权 | 已设计 |
| 可用性即安全 | 我们挂了，客户的 agent 全停 | fail-open 违反默认拒绝原则，fail-close 则我们成为单点故障。break-glass 机制必须设计，而不是回避。 | 待专项 |
| 未注册 agent | 一个没在注册表里的 agent 发起调用，怎么办？ | 拒绝会阻碍采用，放行会留下漏洞。这是一个我们还没有定论的策略问题。 | 待专项 |
Prompt injection
我们不防提示注入。我们改变它的后果。
这句话值得说得非常精确，因为市场上有大量相反的过度承诺。提示注入是一个混淆代理（confused deputy）问题：agent 读到的任何内容都可能是攻击者写的指令，而 agent 拥有真实的权限。当被劫持的 agent 发起一次它本来就有权发起的调用时，任何坐在凭据之上的控制 —— 弹窗、工具描述校验、意图分类器 —— 在原理上都无法判定这次调用不该发生。
降级
凭据的范围被收窄到这一次具体操作，寿命是秒级。原本「外泄整个私有仓库」的后果，降级为「做一次被授权的调用」。
留痕
这次调用可归属到具名的人 + agent 实例 + 任务，并写入不可篡改的审计记录。事后可以问出「到底发生了什么」。
可撤销
消费你 IdP 的 CAEP / Shared Signals 事件，在一个 token TTL 内杀掉在途的 agent 会话；或用 token-claims-change 收窄一个运行中 agent 的权限，而不只是杀掉它。
还有一个诚实的限制一旦 SVID 或凭据签发完成，很多方案在其有效期内就一直信任那个工作负载 —— 一个在第 3 分钟被提示注入的 agent，仍然持有第 0 分钟签发的有效凭据。 这正是我们坚持短 TTL + 逐调用 PDP 检查的原因。但请注意：这缩短的是暴露窗口，不是把窗口关到零。
Compliance
合规映射
下面这些规范有一条共同要求：每个特权动作必须可归属到具名的、唯一的、非共享的身份，且记录必须防篡改并留存。一个静态 API key 在结构上无法满足这条 —— 这个缺口今天就成立，不需要等任何新法规。
| 规范 | 条款 | 我们提供的证据 |
|---|---|---|
| SOC 2 | CC6.1 / CC6.3 / CC6.5 / CC6.6 / CC7.2 | 每个特权动作可归属到具名的、唯一的、非共享的身份；逻辑访问按最小权限授予与撤销。这是我们的核心论证。 |
| DORA | Chapter II — ICT 风险管理 | 金融实体对 ICT 资产的访问控制与可追溯性。金融业是目前唯一有活的义务的细分市场。 |
| PCI DSS 4.0 | Req.7 / Req.8 / Req.10 | 唯一 ID、禁止共享账号、日志留存 12 个月。 |
| ISO 27001:2022 | A.8.2 / A.8.15 | 特权访问权的管理；日志记录。 |
| NIS2 | Art.21(2) | 访问控制作为基本网络安全风险管理措施之一。 |
我们不会说的一句话「EU AI Act 强制要求记录 AI agent 的特权操作。」 这是对法规的曲解，我们在任何对外材料中都不会这样说。Article 12 约束的是高风险 AI 系统的提供者，而高风险义务的适用时间已经推迟。用一条被误读的法规去推动采购，成熟的 GRC 买家会当场识破 —— 那会毁掉这一页其余所有内容的可信度。上表里的每一条今天就已经生效，我们不需要借新法规。
Open questions
还没有答案的问题
我们把这份清单放在公开网站上，因为它是我们和「演示驱动」的产品之间最大的区别。
- 网关兼容性矩阵的实测
- 目前只有一条路径是端到端验证过的，其余全部标注为待实测。 优先级：CRITICAL。
- 完整威胁模型
- 本页是一份大纲，不是一份完成的威胁模型。控制平面被攻破、break-glass、零知识凭据设计都还是开放的。 优先级：CRITICAL。
- 逐工具授权会不会破坏开发者体验
- 目标是 P99 < 200ms。如果做不到，开发者会想办法绕过我们，那么再正确的架构也没有意义。
- 未注册 agent 的处理策略
- 拒绝阻碍采用，放行留下漏洞。目前没有定论。
- 理想客户画像尚未与真实买家验证
- 目前的假设是「有 EU 暴露的金融/金融科技，1,000–10,000 员工」，来自案头研究，没有经过足够的真实买家访谈验证。
关于本站的事实性本站的论证建立在结构性事实上：公开的协议规范（RFC、MCP 授权规范、OIDF 草案）、公开披露的安全事件，以及可复核的合规条款。我们刻意没有在站上引用竞品的融资额、并购价格或 GA 日期 —— 那类信息的时效性和准确性我们无法在这里担保。第三方调查数据均已标注来源，引用前请自行复核。