单租户，无跨客户放大
控制平面在你的机房里只服务你。不存在跨租户凭据泄漏这一类威胁，因为不存在第二个租户。这也让架构显著简化。
Threat model & boundaries
我们能做什么，不能做什么，
以及还没想清楚什么
一份只列优点的安全产品文档，对 CISO 来说是一个负面信号。这一页刻意反过来写：先讲我们自己引入的风险，再讲我们解决的问题，最后列出还没有答案的问题。
Threat #0
AgentPAM 持有通往所有敏感 API 的钥匙
必须最先诚实面对的一条把凭据集中代持，意味着这个控制平面本身成为一个新的高价值目标。这个形状在业界已经演过一次：一个被攻破的中介，等于所有下游被攻破。任何声称「集中托管凭据只有好处」的说法都是不完整的。
私有化部署改变了这条威胁的形状，但没有消除它。 因为控制平面跑在你自己的网络里、且是单租户，「一次攻破波及所有客户」这个 SaaS 特有的放大效应不存在 —— 爆炸半径被限制在你自己的边界内。但在那个边界内，它仍然是你环境中权限最高的组件之一。
根密钥托管在你的 HSM
签名与包裹密钥不以明文离开硬件安全模块。必须支持通过 PKCS#11 使用你自己的 KMS / HSM；纯软件密钥模式会被明确标注为较低保障等级。
broker 自身能否读不到凭据？
能不能做到零知识的凭据设计 —— 让 broker 在注入时也无法读取明文？我们还没有一个满意的答案。
Threat classes
威胁类别与我们的立场
下面每一行都标注了当前状态：已设计 / 待专项 / 明确做不到.
| 类别 | 关键问题 | 我们的立场 | 状态 |
|---|---|---|---|
| 控制平面被攻破 | broker 被攻破 = 它代持的全部凭据泄漏 | 单租户私有化部署把爆炸半径限制在你自己的边界内（无跨客户放大）；根密钥托管在你的 KMS / HSM；凭据零知识设计尚无满意方案。 | 待专项 |
| 气隙下的证明降级 | 无法在线校验 Apple 公证，证明强度是否下降？ | 是，会下降。 离线只能做本地静态验签 + 装订票据。我们会在产品里标注当前证明处于哪一档，不会把两档说成一样。 | 已设计 |
| 时钟漂移击穿短 TTL | 无外部 NTP 时，60–300s 的 Tup 可能刚签发就过期 | 启动时检测集群时钟偏差并告警；定义明确容忍窗；偏差超阈值 fail-closed 并明确报错，绝不静默放行。 | 已设计 |
| Local Attestor 被绕过 | 攻击者伪造证明信号的成本是多少？ | 我们必须能量化并诚实公布这个成本。见下方证明章节。 | 待专项 |
| 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 检查 + 持续重证明的原因。但请注意：这缩短的是暴露窗口，不是把窗口关到零。
Local process attestation
笔记本上没有可用的信任根
这是整个产品最硬的技术骨头。我们把它标注为启发式（heuristic）、纵深防御，绝不宣称等同于硬件远程证明.
| 现成方案 | 为什么在 macOS CLI 进程上不成立 |
|---|---|
| SPIFFE 工作负载证明 | 在这里塌缩成 UID + 二进制路径，用户可以轻易伪造。它给你一个名字，不给你一个保证。 |
| Apple App Attest | 是 iOS / iPadOS / tvOS 的 API，不支持任意 macOS CLI 进程。 |
| TPM 2.0 | macOS 上基本不存在。 |
| WebAuthn / FIDO2 | 绑定的是「人到设备」，不是一个后台进程。 |
| TEE 远程证明 | 是服务端技术，不适用于开发者笔记本。 |
Local process attestation气隙环境还要再降一档。 Apple 的公证在线校验在无出站访问时不可用，离线路径只剩本地静态验签（Team ID、签名链、hardened runtime flag）加装订票据（stapled ticket）验证。产品会标注当前证明处于哪一档 —— 我们不会把联网档与气隙档说成同一件事。
attestation_score = f( code signature + notarization // Team ID, hardened runtime. // Verified by a local privileged helper -- // a process cannot attest itself. , Secure Enclave device key // non-exportable; binds device posture at enrollment , MDM enrollment state // when available, the strongest claim about this machine , parent process chain // was this MCP server launched by Claude Code, or something else? , continuous re-attestation // re-verified mid-session, not once at issuance ) This is a composite heuristic. It raises the cost of impersonation. It is NOT a hardware root of trust, and we will not describe it as one. Air-gapped tier: no online notarization check. Falls back to local static signature verification + stapled ticket. Explicitly a WEAKER tier -- labelled as such in the product, never presented as equivalent.
持续重证明
一次性签发的工作负载身份，在有效期内会一直被信任，无论工作负载之后做了什么。提示注入的威胁模型要求会话中途重新校验 —— 这是我们和一次性证明方案的实质区别。
自己证明自己，逻辑上无效
要用 Secure Enclave 存不可导出的密钥，需要自己的代码签名身份；要证明调用方进程是谁，SDK 跑在被证明者进程内就没有意义；要在 agent 进程之外持有凭据 —— 这是「凭据永不落地」的物理前提。因此 Local Attestor 必须是一个独立的、代码签名的守护进程。
部署约束 · C-09V1 的所有客户侧组件必须纯用户态：单二进制可跑，不依赖内核扩展、MDM 推送或平台方的特殊授权。需要这些东西的执法层被推迟到 V2 企业版 —— 因为开发者不会自装一个需要安全团队审批的内核扩展，而第一批用户正是开发者。
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
还没有答案的问题
我们把这份清单放在公开网站上，因为它是我们和「演示驱动」的产品之间最大的区别。
- macOS 本地进程证明的绕过成本
- 复合启发式究竟能把伪造成本抬高多少？我们需要一个可量化、可公布的数字，而不是一句「很难伪造」。 优先级：CRITICAL。
- 网关兼容性矩阵的实测
- 目前只有一条路径是端到端验证过的，其余全部标注为待实测。 优先级：CRITICAL。
- 完整威胁模型
- 本页是一份大纲，不是一份完成的威胁模型。控制平面被攻破、break-glass、零知识凭据设计都还是开放的。 优先级：CRITICAL。
- 气隙档与联网档的证明强度差多少
- 两档都要给出可量化的伪造成本，而不是笼统说「气隙下弱一些」。这与上面那条绑定，同属 CRITICAL。 优先级：CRITICAL。
- 逐工具授权会不会破坏开发者体验
- 目标是 P99 < 200ms。如果做不到，开发者会想办法绕过我们，那么再正确的架构也没有意义。
- 未注册 agent 的处理策略
- 拒绝阻碍采用，放行留下漏洞。目前没有定论。
- 理想客户画像尚未与真实买家验证
- 目前的假设是「有 EU 暴露的金融/金融科技，1,000–10,000 员工」，来自案头研究，没有经过足够的真实买家访谈验证。
关于本站的事实性本站的论证建立在结构性事实上：公开的协议规范（RFC、MCP 授权规范、OIDF 草案）、公开披露的安全事件，以及可复核的合规条款。我们刻意没有在站上引用竞品的融资额、并购价格或 GA 日期 —— 那类信息的时效性和准确性我们无法在这里担保。第三方调查数据均已标注来源，引用前请自行复核。