下一个动作由推理决定
CI job 和微服务的行为可以预先枚举并白名单化。AI agent 的下一个动作由 LLM 在运行时决定。策略不能只写「允许调用 X」，必须能对运行时的意图做判断。
Token Ladder · RFC 8693
四步令牌阶梯，逐跳收窄
-
[1]
Tu 人 → 你的 IdP（Okta / Entra / Google）OIDC id_token · scope = 该人在你策略下的完整会话1h 00mTTL
-
[2]
Ts agent → AgentPAM，RFC 8693 令牌交换sub=人 · act={agent_instance} · cnf.jkt（DPoP） · authorization_details=[agent_task]15:00TTL
-
[3]
Tup 你的网关 → AgentPAM，换取上游凭据以 header 注入上游 API · 无绑定 · 是整条链上价值最高的东西，所以最短命3:00TTLAGENT 永远看不到这一行
-
[4]
Ts′ 子 agent 委派 —— 重跑 [2]，不是接在 [3] 之后scope ⊂ 父 Ts 的 scope（强制严格子集） · TTL ≤ 父 Ts 的 15:00 · act 链嵌套5:00TTL
宽度 = 权限范围每一跳只能更窄、更短命禁止裸 bearer：DPoP RFC 9449 绑定
TTL 阶梯是非对称的，而且是故意的：Ts 有 DPoP 绑定和逐调用的策略检查，被窃后没有私钥就是废纸，所以可以活得久一点；Tup 是一份没有绑定的上游凭据，谁拿到谁能用 —— 所以它必须最短命。 看完整的 claim 设计 →
The empirical argument
没有服务端补丁可打，因为 PAT 的 scope 本身就是漏洞。
- GitHub MCP — 提示注入导致私有仓库外泄
- Supabase MCP / Cursor — 通过被授权的查询路径泄漏数据
- Asana MCP — 跨租户数据暴露
- Salesloft Drift → Salesforce — OAuth token 被盗取
- Nx — 恶意软件驱使 coding agent 自己去找密钥
把这些事件排在一起，会得到一个反直觉但一致的结论：它们都不是内存安全漏洞，也都不是「少了一个批准弹窗」。每一起里，那次工具调用都在 agent 的授权范围内。变成灾难的原因，是那份凭据的范围太宽、寿命太长。
这决定了控制点的位置。提示注入防护、工具描述固定、审批弹窗 —— 全都坐在凭据之上。它们能阻止 agent 提出请求，阻止不了那份凭据继续有效。一个被污染的工具描述、一个被投毒的 npm 版本、一个读取 ~/.claude.json 的信息窃取器，抵达的是同一个静态 PAT，而没有一个会经过 PreToolUse 钩子。
反过来说：如果凭据从未落到笔记本上，工具投毒就从「外泄整个私有仓库」降级为「做一次被授权的、有日志的、可撤销的调用」。
—— 这一句就是 AgentPAM 的全部设计前提The problem
身份坍缩
今天一个 AI agent 访问敏感 API 的全部身份材料，是一个躺在点文件里的长期 API Key。这个静态字符串把四个维度压扁成一个值。
哪个人human
哪个实例agent
什么任务task
什么时刻time
⇒压扁
"ghp_xxxxxxxxxxxx"
所有下游控制 —— 授权、审计、撤销 —— 都建立在这个字符串上，因此全部失去分辨率。目标 API 的日志只能说「某个 token 调了我」，永远回答不了「是谁的哪个 agent、为了什么任务」。
证据
- > 2/3的企业无法清晰区分 AI agent 与人类的动作CSA 调查
- 88%的安全决策者把「特权用户」定义为仅限人类行业调查
- 79%的 MCP server 把凭据明文存放，仅 8.5% 使用 OAuthMCP 生态扫描
以上为第三方调查数据，非我们自采；引用前请自行复核来源。
Why classic PAM does not carry over
三个 PAM 从未面对过的新变量
PAM 已经做了二十年的会话录制和限时借出。它对 AI agent 不成立，不是因为做得不够好，而是因为威胁模型里少了三条。
agent 是一个可被劫持的代理
agent 读到的任何内容 —— 网页、issue、日志、上一个工具的返回值 —— 都可能是攻击者写的指令。因此 agent 的授权不能等同于它所持凭据的授权。传统 PAM 的威胁模型里没有这一条。
缺一种降权的人格
agent 代表某人行动，但不完全是那个人。传统 PAM 只有「用户」和「服务账号」两种主体，缺少「降权的、有范围的、有时限的人格」。
我们的表述AI agent 不是一种新的身份类型，而是一种新的授权链形态。 人的链长为 1、意图自明；机器的链长为 1、意图在编译期已知；AI 的链长 ≥ 2，中间节点自主，意图到运行时才知道。产品要做的，是让
人 → 委派 → agent 实例 → 代持 → 工作负载凭据 这条链的每一跳都可验证、可裁剪、可撤销、可审计。
Identity model
三层对象：类型、实例、会话
「短时效 token」和「持久 agent 身份」不是二选一 —— 它们在不同层。实例长期存在以承载策略、担保人和审计历史；会话每任务签发以承载 on-behalf-of 与任务范围。
AgentBlueprint
持久 · 类型/模板这一类 agent 是什么、最多能请求什么。凭据挂在蓝图上，不挂在实例上。
- publisher / verified_publisher
- model {provider, name, version}
- declared_capabilities [] — 能力天花板
- credential_ref — 凭据在这里
AgentIdentity
持久 · 授权主体稳定、可寻址的注册实例。担保人强制且必须是人，因此构造上不存在孤儿 agent。
- sponsor → HumanIdentity（强制）
- owner → HumanIdentity（可选）
- granted_capabilities ⊆ declared
- state active | disabled | soft_deleted
AgentSession
临时 · 每任务签发永不作为身份对象持久化。 人的绑定是会话上的一个 claim，不是身份的属性 —— 同一个实例可能自主运行，也可能在不同时刻代表不同的人。
- on_behalf_of → Human | null
- task {id, purpose, sensitivity}
- delegation_chain [] — 单调收窄
- binding {dpop | mtls, jkt}
- lifecycle_binding {task_id, …}
为什么人的绑定必须在会话层把「代表谁」绑在身份层，语义上就是错的，而且会二选一地失败：要么为每个人复制一份实例（数量爆炸），要么丢失代表关系（审计断链）。我们同时从第一天就显式区分主体类型 —— agent 和人在 token 里绝不能都表现为同一种
idtyp。
Where we sit
你的网关是 Resource Server，我们是 Authorization Server
MCP 授权规范已经完成了 Resource Server 与 Authorization Server 的拆分。我们天然就是那个 AS —— 这不是硬插进去，这是规范原生的集成点。
Human ---- SSO / OIDC ----> Your IdP (Okta / Entra / Google)
| |
| launches | Tu id_token, TTL ~1h (your policy, not ours)
v |
+-----------------------------+ |
| Agent host process | |
| Claude Code / Cursor / | |
| Codex / in-house framework | |
+--------------+--------------+ |
| MCP (stdio | HTTP)
v |
+-----------------------------+ |
| AgentPAM Local Attestor |<-+ V2 . user-space only . heuristic
| process + device signals |
| Secure Enclave device key |
| DPoP per-request signature |
| strips creds from the env |
+--------------+--------------+
v
+-----------------------------+
| YOUR MCP Gateway | Resource Server -- yours. We do not build one.
+--------------+--------------+
| RFC 9728 AS delegation | RFC 8693 token exchange | ext_authz
v
+=========================================================+
| AgentPAM control plane (your Linux, air-gap capable) |
| Identity registry Blueprint / Identity / Session |
| PDP AuthZEN + COAZ, per-tool/param |
| Credential broker RFC 8693 exchange, DPoP-bound |
| Audit spine OCSF + W3C Trace Context |
| CAEP consumer revoke inside one token TTL |
+=============================+===========================+
| Tup 60-300s, header-injected
v *** THE AGENT NEVER SEES THIS ***
+-----------------------------+
| Sensitive API |
| GitHub / Postgres / AWS / |
| Snowflake / internal SaaS |
+-----------------------------+==== 框起来的那一层控制平面。IdP 是你的，网关是你的，上游 API 是你的。Local Attestor 是纯用户态的可选组件，其证明信号是启发式的。 见安全模型「和你的 PAM 聊天」
给既有产品套一个 MCP server 的外壳。安全价值：零。售前必须主动澄清我们不在这一层，否则会被归入噪音。
agent 发现与治理
把 IGA 指向一份 agent 清单。这一层真实有用，也是我们的 V1 楔子 —— 但它只盘点，不拦截。
运行时代理 agent → 资源访问
在请求路径上，逐调用校验身份、判策略、注入凭据、写审计，并且能说不。这是唯一能逐工具调用执法的位置。
Integration
配置，不是工程
MCP 规范要求网关作为 Resource Server，在 RFC 9728 protected resource metadata 中指明外部 Authorization Server。也就是说，接入我们所需的大部分动作，是任何合规网关本来就要能做的事。
- 发布
/.well-known/oauth-protected-resource，其中authorization_servers指向你的 AgentPAM 实例。MCP 规范强制 - 401 时返回指向它的
WWW-Authenticate。MCP 规范强制 - 校验我们签发的 token（JWKS + audience）。MCP 规范强制
- 把网关的
backendAuth.oauthTokenExchange.tokenEndpointPath指向我们的 token 端点。这一步是唯一真正新增的配置。
网关有授权钩子，但不支持 AS 委托
我们实现 AuthZEN / COAZ-MCP 的 PDP 接口，注册为外部授权器（gRPC guardrails 或 Envoy ext_authz），凭据注入靠 allow 时的 header mutation。代价：我们看得到请求，但不拥有 token 签发。
不透明网关，没有任何钩子
我们作为上游 MCP server 被你的网关代理，变成真实工具前面的策略执行代理。代价：多一跳，且只看得到被路由过来的流量。好处：对你的网关零要求。
兼容性矩阵与逐网关的实测状态见架构页 —— 其中大部分条目仍标注为「待实测」，我们不会把未实测的写成已验证。 看兼容性矩阵 →
Enforcement tiers
分层执法，从凭据代持开始
我们不一次性铺满所有执法层。原因很实际：OS 级执行需要内核扩展、MDM 推送和安全团队审批，开发者不会自装 —— 而第一批用户正是开发者。更重要的是，Tier 0 在原理上已经吃掉了大部分绕过场景。
TIER 0
V1
凭据代持 —— 凭据永不下发给 agent
决定性的控制点。 agent 手上没有凭据，那么它绕过我们直接 curl 也没有用。这一条在原理上就吃掉了 Tier 3 的大部分价值。
TIER 1
V1
MCP 逐工具调用授权 + 审计
主控制面。默认拒绝：未被策略显式允许的工具调用一律拒绝，禁止 fail-open。粒度到 server 级、tool 级、以及参数级。
TIER 2
V1.5
出站兜底（loopback 代理 + CA 注入）
拦截残留凭据与工程师既有凭据 —— ~/.aws/credentials、kubeconfig 这些本来就在机器上、不经过 MCP 的东西。
TIER 3
V2 企业版
OS 级执行（eBPF / Endpoint Security Framework）
回答「非 MCP 动作掉在策略外」这个竞标攻击。这是企业版阶段的问题，不是 V1 的问题。
Deployment posture
整个控制平面跑在你的机房里，不回连我们
这不是一个部署选项，是一条硬约束。凭据代持意味着我们持有通往你所有敏感 API 的钥匙 —— 那把钥匙不应该离开你的网络边界。
完全私有化，可气隙
控制平面在你自有的 Linux 环境中运行，不要求任何出站云端访问。任何依赖我方 SaaS 才能工作的功能都不会被做出来。
容器化交付
OCI 镜像 + Compose / Helm。最小基础镜像、非 root 运行、只读根文件系统、明确的能力集与网络策略 —— 因为你的安全团队会做镜像审计。
零遥测，零回家
没有遥测、没有在线许可证校验、没有自动更新回连。 许可证是离线签名文件；更新是你主动拉取的镜像。任何「回家」的网络行为，在气隙客户处就是一次事故。
由此产生的连锁后果 —— 我们把它写在这里，因为它们是真的成本
- 单租户，因此更简单
- 不需要多租户隔离、跨租户泄漏防护、租户级配额。架构显著简化，攻击面也更小。
- 根密钥可托管在你的 KMS / HSM
- Broker 持有通往所有敏感 API 的钥匙，因此必须支持通过 PKCS#11 使用你自己的 KMS / HSM 持根密钥。纯软件密钥模式会被明确标注为较低保障等级。
- 我们看不到你的日志
- 支持能力的生死线在于一键导出脱敏诊断包（配置、版本、健康指标、脱敏错误日志），由你审查后再交给我们。我们不会要求你开放任何入站访问。
- 气隙下的进程证明强度更低
- Local Attestor 依赖代码签名与公证身份，而 Apple 的公证在线校验在气隙环境中不可用。离线路径只做本地静态验签（Team ID、签名链、hardened runtime）加装订票据验证。我们会明确标注这一档的强度低于联网环境，不会假装没有差别。
- 60 秒 TTL 会撞上时钟漂移
- 气隙环境常无外部 NTP，跨机漂移几十秒是常态，足以让凭据「刚签发就过期」。控制平面启动时检测集群时钟偏差并告警，定义明确的容忍窗，并在偏差超阈值时 fail-closed 并明确报错 —— 绝不静默放行。
- 没有云端威胁情报
- 恶意 MCP server 信誉、工具描述投毒特征这类情报，在气隙下拿不到实时更新。改为签名的离线策略包由你主动导入，并在界面上明示情报库的版本与日期 —— 你必须知道自己有多旧。
还有一条结构性推论，值得直说：任何以公有云捆绑为前提的方案，在气隙环境中根本不作为选项存在。 这不是我们比谁强，这是部署形态决定的。
What ships
四个交付物
客户侧端点开源，控制平面闭源变现。先做发现与归属，再做执法 —— 因为没人会为一个数不清的群体买执法。
Collector
只读 CLI / 轻量守护进程。一条 docker run，不连任何东西，产出：有多少个 agent、各自持有什么凭据、上周碰过什么、哪些在 SOC 2 CC6 下不可归属。零爆炸半径。
Portal + 控制平面
OCI 容器组，部署在你自有的 Linux 上 —— 不是 SaaS。 身份注册表、策略编辑、审计视图、审计师就绪报告，以及批准疲劳度量 —— 审批通过率接近 100% 就是橡皮图章信号。
PDP / Credential Broker
同一容器组内的服务。逐调用策略决策与 RFC 8693 令牌交换，凭据在这里代持并按请求注入。目标 P99 延迟 < 200ms。
Local Attestor
代码签名守护进程。不能是 SDK —— SDK 跑在被证明者进程内，自己证明自己，逻辑上无效；而且要在 agent 进程之外持有凭据。
定价原则不按 agent 计价。 agent 是临时的、会成千上万地生成；按 agent 计价会促使客户合并 agent 以降低账单，这是一个安全反模式。我们按受保护资源 / 策略化集成计价，agent 不限量。
Boundaries
我们不是什么
这一节在这里，是因为它对你比对我们更有用。下面每一条如果我们含糊其辞，你的团队在第二次会议上就会戳穿。
- 不是 MCP Gateway
- 你已经有一个，而且网关这一层已经被商品化了。我们接入你的网关，不替换它。任何要求你换掉网关的方案都是我们设计失败。
- 不是 IdP
- 你已经有 SSO。人类认证一律委托给 Okta / Entra / Google，我们只消费它们的断言。我们不存人类口令，不做 MFA。
- 没有发明 agent 身份
- 主流 IdP 已经有 agent 对象模型、担保人、条件访问、风险检测和审计 schema。我们不跟这些正面打，我们打它们之间的缝：跨 IdP、跨云的那一段没有人在管，而且结构上没人有动力去管。
- 不能防止提示注入
- 我们无法阻止一次被授权的调用。我们能做的是准确的三件事：把它的伤害降级（凭据范围窄、寿命短）、把它留痕（可归属到人+agent+任务）、让它可撤销（一个 token TTL 内失效）。任何宣称「防提示注入」的产品都在过度承诺。
- 本地进程证明不等于硬件远程证明
- 笔记本上没有可用的信任根：macOS 上基本没有 TPM，Apple App Attest 是 iOS 系列的 API 且不支持任意 macOS CLI 进程，SPIFFE 在这里塌缩成 UID 加二进制路径。我们的证明是复合启发式、是纵深防御，我们会公布它的绕过成本，不会把它说成硬件证明。
- 不拿 EU AI Act 当销售论证
- 「EU AI Act 强制要求记录 AI agent 特权操作」是对法规的曲解 —— Article 12 约束的是高风险系统的提供者，且高风险义务已推迟。我们的合规论证建立在今天就成立的东西上：SOC 2 CC6.1 / CC6.6 的归属性要求，以及金融业在 DORA 下的 ICT 风险管理义务。
- 我们自己是一个新的高价值目标
- AgentPAM 持有通往所有敏感 API 的钥匙。一个被攻破的中介等于所有下游被攻破 —— 这正是 Salesloft Drift 那类事件的形状。我们把这条列在威胁模型的第一位，而不是最后一位。