AI Privileged Access Control Plane

控制点是凭据，
不是那个批准弹窗。

至今每一起高影响的 MCP 安全事件里，那次工具调用都是 agent 被授权做的。伤害来自 MCP server 手上那份凭据的范围与寿命。

AgentPAM 给每个 AI agent 一个一等公民身份，把它绑定到一个负责的人类担保人，并签发短时的、任务范围的、发送方约束的凭据 —— 而 agent 永远看不到这些凭据。

读架构读威胁模型与边界我们不是什么

先说清楚： ~~MCP Gateway~~ — 你已经有了 ~~IdP~~ — 你已经有了 ~~提示注入防护~~ — 我们只降级它

Token Ladder · RFC 8693

四步令牌阶梯，逐跳收窄

示意 · 40× 加速时钟

[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:00TTL

AGENT 永远看不到这一行
[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 生态扫描

以上为第三方调查数据，非我们自采；引用前请自行复核来源。

Self-diagnosis

AI agent 访问的八类挑战

这是一套用客户语言写的问题分类。先看看你有几条 —— 然后再看我们的答案，以及我们覆盖到哪一步。

1

Uncontrolled OAuth Permissions

失控的 OAuth 授权

我们的答案RFC 9396 RAR 的 authorization_details 表达细粒度授权；MCP 增量 scope 同意（在 WWW-Authenticate 里中途索取），不再一次性给出最大授权。

已覆盖
2

Human-Equivalent Agent Access

agent 拿到与人等同的权限

我们的答案agent 拿到的是那个人的严格子集：granted_capabilities ⊆ blueprint 能力天花板，act 链单调收窄。agent 绝不等同于它背后的人。

核心能力
3

Opaque Agent Actions & Decisions

agent 的动作与决策不透明

我们的答案审计携带 task.purpose 与 sensitivity —— 我们主动采集已声明的意图，而不是被动录制流量。每次调用都绑定到那个声明。

部分覆盖
4

Standing Tokens & Secrets

常驻令牌与密钥

我们的答案Tier 0 凭据代持 + 四步 TTL 阶梯（Tup 60–300s）。没有常驻 token，因为 agent 从来就没拿到过。

核心能力
5

Lack of Auditability & Traceability

缺乏可审计性与可追溯性

我们的答案厂商中立的事件 schema（人 / agent / 蓝图 / 任务 / 工具 / 资源 / 决策 / 义务 / 委派链）+ W3C Trace Context 关联 + 哈希链防篡改。

已覆盖
6

Inconsistent Guardrails Across Tools

各工具护栏不一致

我们的答案跨 IdP、跨云的单一策略平面。 Entra 管 Entra 里的 agent，AgentCore 管 AWS 里的 —— 没有人管全部。

差异化
7

User-Driven Agent Connections

用户自行连接 agent

我们的答案EMA / ID-JAG 把同意与策略决策从终端用户移到企业 IdP —— 无 OAuth 同意屏、无影子连接、单一撤销点。

有缺口
8

Privilege Creep in AI Workflows

AI 工作流中的权限蠕变

我们的答案单调收窄（scope 只能变窄）+ lifecycle_binding（任务终止即失效，不等 TTL 走完）+ 禁止 scope 沿链扩张。

差异化

第 3 条的真实边界 —— 我们不会越过这条线解释 agent 为什么这么做的 transcript 活在 client 里，不在网络链路上。 在 broker / 网关这个位置，我们录得到「做了什么」，录不到「为什么」。我们能做的是要求 agent 在开启任务时声明意图，再把每次调用绑定到该声明 —— 这让审计可以问「这次调用与它声称的任务相符吗」。但它不是思维链的真相。 我们不会宣称「完全的决策可解释性」，也不会说我们能解释 agent 的推理 —— 那是虚假的安全声明。

第 7 条同时是一个我们尚未解决的开放问题「用户自行连接 agent」的另一面，是未注册 agent 怎么处理，而我们还没有定论：拒绝则安全，但开发者会绕过或干脆卸载我们 —— 那会杀死采用；放行则采用顺滑，但留下了口子。我们目前的倾向是 quarantine 蓝图 —— 未注册 agent 以最低权限自动放行，同时告警并推送注册引导，把一次安全事件转化为一条注册路径。这是我们当前的思路，不是已发货的功能，仍待与真实客户验证。

Why classic PAM does not carry over

三个 PAM 从未面对过的新变量

PAM 已经做了二十年的会话录制和限时借出。它对 AI agent 不成立，不是因为做得不够好，而是因为威胁模型里少了三条。

非确定性

下一个动作由推理决定

CI job 和微服务的行为可以预先枚举并白名单化。AI agent 的下一个动作由 LLM 在运行时决定。策略不能只写「允许调用 X」，必须能对运行时的意图做判断。

提示注入 = 混淆代理

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, …}

我们和 NHI（Non-Human Identity）类目的关系我们属于 NHI 类目。 agent 实例、蓝图、生命周期、孤儿治理、所有权归属 —— 这些全是 NHI 的语汇和方法论，我们直接继承。但要害在于：我们做的是 NHI 与人的复合，不是纯 non-human。准确的自我描述是「把 NHI 做成一条委派链」：人（sub） → agent 实例（act） → 上游凭据 —— 强制 sponsor、严格子集、从不落到 agent。「non-human」这个词不能把「人还在链条里」挤掉 —— SOC 2 CC6.1 / CC6.6 的归属性论证，全部力量来自「追得回到人」。

为什么人的绑定必须在会话层把「代表谁」绑在身份层，语义上就是错的，而且会二选一地失败：要么为每个人复制一份实例（数量爆炸），要么丢失代表关系（审计断链）。我们同时从第一天就显式区分主体类型 —— agent 和人在 token 里绝不能都表现为同一种 idtyp。

Where we sit

你的网关是 Resource Server，我们是 Authorization Server

MCP 授权规范已经完成了 Resource Server 与 Authorization Server 的拆分。我们天然就是那个 AS —— 这不是硬插进去，这是规范原生的集成点。

deployment.txt横向可滚动

  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

配置，不是工程

RFC 9728 要求网关公布 authorization_servers，而规范允许那个 AS 指向外部 —— 于是接入我们在支持该配置的网关上就是改配置。但要说清楚：规范并不强制那个 AS 是外部的，网关完全可以自任 AS，因此这条路径不是通吃的。实测 12 家网关中 4 家干净支持。

发布 /.well-known/oauth-protected-resource，其中 authorization_servers 指向你的 AgentPAM 实例。RFC 9728 强制
401 时返回指向它的 WWW-Authenticate。⚠️ 自 2025-11-25 规范（SEP-985）起这一步已变为可选 —— 客户端可回退到 .well-known 发现。
校验我们签发的 token（JWKS + audience）。RFC 9728 强制
把网关的 backendAuth.oauthTokenExchange.path 指向我们的 token 端点。这一步是唯一真正新增的配置。（本地 YAML 键是 path；tokenEndpointPath 是 xDS/proto 字段名，写进配置文件会加载失败。）

兜底 A

网关有授权钩子，但不支持 AS 委托

我们实现 AuthZEN / COAZ-MCP 的 PDP 接口，注册为外部授权器（gRPC guardrails 或 Envoy ext_authz），凭据注入靠 allow 时的 header mutation。代价：我们看得到请求，但不拥有 token 签发。

兜底 B

不透明网关，没有任何钩子

我们作为上游 MCP server 被你的网关代理，变成真实工具前面的策略执行代理。代价：多一跳，且只看得到被路由过来的流量。好处：对你的网关零要求。

兼容性矩阵与逐网关的实测状态见架构页 —— 其中大部分条目仍标注为「待实测」，我们不会把未实测的写成已验证。看兼容性矩阵 →

Enforcement tiers

分层执法，从凭据代持开始

我们不一次性铺满所有执法层。原因很实际：OS 级执行需要内核扩展、MDM 推送和安全团队审批，开发者不会自装 —— 而第一批用户正是开发者。更重要的是，Tier 0 在原理上已经吃掉了大部分绕过场景。

TIER 0

凭据代持 —— 凭据永不下发给 agent

决定性的控制点。 agent 手上没有凭据，那么它绕过我们直接 curl 也没有用。这一条在原理上就吃掉了 Tier 3 的大部分价值。

TIER 1

MCP 逐工具调用授权 + 审计

主控制面。默认拒绝：未被策略显式允许的工具调用一律拒绝，禁止 fail-open。粒度到 server 级、tool 级、以及参数级。

TIER 2

出站兜底（loopback 代理 + CA 注入）

拦截残留凭据与工程师既有凭据 —— ~/.aws/credentials、kubeconfig 这些本来就在机器上、不经过 MCP 的东西。

V1.5

TIER 3

OS 级执行（eBPF / Endpoint Security Framework）

回答「非 MCP 动作掉在策略外」这个竞标攻击。这是企业版阶段的问题，不是 V1 的问题。

V2 企业版

Deployment posture

整个控制平面跑在你的机房里，不回连我们

这不是一个部署选项，是一条硬约束。凭据代持意味着我们持有通往你所有敏感 API 的钥匙 —— 那把钥匙不应该离开你的网络边界。

C-13

完全私有化，可气隙

控制平面在你自有的 Linux 环境中运行，不要求任何出站云端访问。任何依赖我方 SaaS 才能工作的功能都不会被做出来。

C-14

容器化交付

OCI 镜像 + Compose / Helm。最小基础镜像、非 root 运行、只读根文件系统、明确的能力集与网络策略 —— 因为你的安全团队会做镜像审计。

C-15

零遥测，零回家

没有遥测、没有在线许可证校验、没有自动更新回连。 许可证是离线签名文件；更新是你主动拉取的镜像。任何「回家」的网络行为，在气隙客户处就是一次事故。

由此产生的连锁后果 —— 我们把它写在这里，因为它们是真的成本

单租户，因此更简单: 不需要多租户隔离、跨租户泄漏防护、租户级配额。架构显著简化，攻击面也更小。
根密钥可托管在你的 KMS / HSM: Broker 持有通往所有敏感 API 的钥匙，因此必须支持通过 PKCS#11 使用你自己的 KMS / HSM 持根密钥。纯软件密钥模式会被明确标注为较低保障等级。
我们看不到你的日志: 支持能力的生死线在于一键导出脱敏诊断包（配置、版本、健康指标、脱敏错误日志），由你审查后再交给我们。我们不会要求你开放任何入站访问。
气隙下的进程证明强度更低: Local Attestor 依赖代码签名与公证身份，而 Apple 的公证在线校验在气隙环境中不可用。离线路径只做本地静态验签（Team ID、签名链、hardened runtime）加装订票据验证。我们会明确标注这一档的强度低于联网环境，不会假装没有差别。
60 秒 TTL 会撞上时钟漂移: 气隙环境常无外部 NTP，跨机漂移几十秒是常态，足以让凭据「刚签发就过期」。控制平面启动时检测集群时钟偏差并告警，定义明确的容忍窗，并在偏差超阈值时 fail-closed 并明确报错 —— 绝不静默放行。
没有云端威胁情报: 恶意 MCP server 信誉、工具描述投毒特征这类情报，在气隙下拿不到实时更新。改为签名的离线策略包由你主动导入，并在界面上明示情报库的版本与日期 —— 你必须知道自己有多旧。

还有一条结构性推论，值得直说：任何以公有云捆绑为前提的方案，在气隙环境中根本不作为选项存在。 这不是我们比谁强，这是部署形态决定的。

What ships

四个交付物

客户侧端点开源，控制平面闭源变现。先做发现与归属，再做执法 —— 因为没人会为一个数不清的群体买执法。

① V1 楔子 · 开源

Collector

只读 CLI / 轻量守护进程。一条 docker run，不连任何东西，产出：有多少个 agent、各自持有什么凭据、上周碰过什么、哪些在 SOC 2 CC6 下不可归属。零爆炸半径。

② V1 · 闭源 · 跑在你的机房

Portal + 控制平面

OCI 容器组，部署在你自有的 Linux 上 —— 不是 SaaS。 身份注册表、策略编辑、审计视图、审计师就绪报告，以及批准疲劳度量 —— 审批通过率接近 100% 就是橡皮图章信号。

③ V1.5 · 适配层开源

PDP / Credential Broker

同一容器组内的服务。逐调用策略决策与 RFC 8693 令牌交换，凭据在这里代持并按请求注入。目标 P99 延迟 < 200ms。

④ V2 护城河 · 部分开源

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 那类事件的形状。我们把这条列在威胁模型的第一位，而不是最后一位。

读完整威胁模型与开放问题