产品经理 Wiki

Appearance

Agent 安全工程 ​

方向定位：Agent 特有的安全工程问题——协议层（MCP 十大风险）、身份层（OBO/CIBA/范围衰减/递归委托）、执行层（预执行拦截 + 防篡改审计）。围绕"模拟用户 → 委托授权"这条贯穿主线立体把握 Agent 安全 当前版本：v0.1 首次构建：2026-05-18 最近更新：2026-05-20 文件名日期同步：2026-05-18 来源数：4 篇

方向定位 ​

本方向聚焦 Agent 系统（多步工具调用 + 跨域协同 + 持久化上下文）特有的安全工程问题，区别于姐妹方向《AI 系统安全攻防体系》（聚焦单模型/单应用的攻防分类与护栏产品）。本方向回答三个问题：

  1. 协议层怎样守住——MCP（Model Context Protocol）作为 Agent 调用工具的标准协议，OWASP 已公开十大风险，工具投毒、影子 MCP、上下文注入是 MCP 特有的高危项
  2. 身份层怎样守住——智能体身份管理从"模拟用户（Impersonation）"必须转向"委托授权（Delegated Authority）"，OAuth 2.1 + OBO + CIBA + 范围衰减是核心机制，OpenID 基金会 2025-10 发布的《Identity Management for Agentic AI》白皮书是核心一手源
  3. 执行层怎样守住——当前 Agent 框架"模型生成 → 框架解析 → 直接执行"的链路在副作用发生前缺乏框架无关的控制点，AEGIS 三阶段预执行拦截 + Ed25519 防篡改审计是工程化方向

读者对象为 Agent 框架开发者、企业 IAM 工程师、Agent 安全乙方。目标是建立"协议 + 身份 + 执行"三层视图，明确每一层的攻击面和工程化对策。

与姐妹方向的分工：本方向不重复讲解"AI 系统通用攻防"——经典四类攻击（闪避/药饵/后门/模型窃取）、LLM 五类威胁、护栏产品形态、OWASP Top 10 for LLM、红队方法论详见《AI 系统安全攻防体系》；提示注入（LLM01）的基础形态在该方向"核心概念"节集中讲解，本方向只覆盖其在 Agent 链路中的特化形态（意图流劫持、上下文注入、工具投毒）。具身场景下的"语言理解权 vs 动作执行权"拆分与本方向"执行层预执行拦截"是同源思想的两个延伸，详见《具身智能安全》。

知识图谱 ​

  • 协议层（MCP Top 10）
    • 身份与权限类
      • LLM01 令牌管理不当与密钥暴露
      • LLM02 权限范围蔓延导致提权
      • LLM07 认证与授权不足
    • 工具与协议完整性类
      • LLM03 工具投毒（MCP 特有高危）
      • LLM04 软件供应链攻击
    • 执行链路类
      • LLM05 命令注入与执行
      • LLM06 意图流劫持（Intent Flow Hijacking）
    • 运行时治理类
      • LLM08 审计与遥测缺失
      • LLM09 影子 MCP 服务器
      • LLM10 上下文注入与过度共享
  • 身份层（Agent IAM）
    • 两层认证挑战
      • 智能体认证（工作负载身份 / SPIFFE）
      • 用户委托认证（OAuth 2.1 + PKCE + OBO）
    • 核心机制
      • OBO（On-Behalf-Of）流程
      • CIBA 异步授权
      • 范围衰减（Scope Attenuation）
      • 撤销 vs 取消配置
    • 四种身份架构模型
      • 增强型服务账户
      • 委托用户子身份
      • 联合信任与互操作
      • 主权可移植身份
    • PEP/PDP 外部化架构
    • 可扩展同意三模式
      • 策略即代码
      • 基于意图的授权
      • 基于风险的动态授权
  • 执行层（预执行拦截）
    • 当前框架结构性缺陷
    • AEGIS 三阶段管道
      • 深度字符串提取
      • 内容优先风险扫描
      • 可组合策略验证
    • 防篡改审计追踪
      • Ed25519 签名
      • SHA-256 哈希链
    • 部署前自检清单

核心概念 ​

  • MCP（Model Context Protocol）：Agent 调用外部工具的标准协议。OWASP MCP Top 10 vs Skill Top 10 的核心区别——Skill 关注"装进 Agent 里的能力包本身有没有问题"（打包、分发、权限声明、加载、隔离），MCP 关注"模型通过协议连接外部工具和上下文时，调用链会不会失控"（token、身份、工具契约、上下文、执行链路、运行时审计）[来源 #1]

  • 工具投毒（MCP 特有高危风险）：不是普通恶意插件，而是 schema、manifest、tool descriptor 以及工具输出本身被篡改，让模型在"表面合法"的情况下做错事。典型案例：一个无害操作名实际映射到破坏性动作。日志里看到的仍是"合法调用"，agent 是按照 schema 行动的，但 schema 本身已被污染[来源 #1]

  • 意图流劫持（Intent Flow Hijacking）：Intent Flow = agent 把用户高层目标翻译成工具调用和执行动作的关键路径。攻击者把恶意指令藏进被 agent 信任的上下文里（资源文档、schema 定义、工具输出），让 agent 在流程内部被带偏。比 prompt injection 更隐蔽，因为攻击发生在 agent 自己的执行链路内部[来源 #1]

说明：提示注入（Prompt Injection / LLM01）的基础定义见姐妹方向《AI 系统安全攻防体系》"核心概念"节；意图流劫持是其在 Agent 多步工具调用场景下的特化形态——攻击面从单次输入扩展到整条执行链路。

  • 影子 MCP 服务器（Shadow MCP）：Shadow IT 的 AI 版本——未经批准、未经监管的 MCP 实例，被开发/研究/数据团队临时搭起来测试，常带着默认凭证、宽松配置或未加固 API，运行在正式治理体系之外。企业应对第一步不是"防攻击"，而是"先把所有活跃的 MCP 实例找出来"[来源 #1]

  • 委托授权（Delegated Authority）：智能体身份管理的核心范式——从"模拟用户"（Impersonation，问责黑洞）转向"委托授权"。访问令牌中包含两个不同身份：sub（授权用户）和 act（执行操作的智能体），PEP 可据此生成区分"谁授权"与"谁执行"的审计日志[来源 #2]

  • OBO（On-Behalf-Of）流程：智能体直接使用用户凭证 = 模拟 = 问责黑洞。OBO 通过在 JWT 中同时携带 sub（用户）和 act（智能体）两个身份解决这一问题，是委托授权的标准实现[来源 #2]

  • CIBA（Client Initiated Backchannel Authentication）：异步授权机制。智能体无需阻塞工作流，通过带外机制请求用户授权；三种交付模式：轮询（批处理）/ 探测（节省流量）/ 推送（最快响应）。解决长时间运行任务中敏感操作需要用户批准但用户不在线的问题[来源 #2]

  • 范围衰减（Scope Attenuation）：主智能体 → 子智能体 → 孙智能体的递归委托中，权限必须逐级收缩。两种机制：OAuth 2.0 令牌交换（集中策略控制，向授权服务器请求权限缩减的新令牌）和 Biscuits / Macaroons（去中心化，令牌持有者可离线创建更受限版本）[来源 #2]

  • 撤销 vs 取消配置：撤销 (Revocation) = 立即让活动令牌失效，终止当前会话；取消配置 (De-provisioning) = 永久移除智能体身份及所有相关权利。单个受损智能体身份可通过递归委托引发级联故障，因此取消配置必须是不可逆、全系统传播的[来源 #2]

  • PEP/PDP 外部化架构：PEP（策略执行点，API 网关 / 服务网格 sidecar）+ PDP（策略决策点，集中式授权服务，OpenID AuthZEN 工作组标准化中）。PEP 同时承担：解析委托凭证、区分用户与智能体、兼容遗留系统（将丰富智能体令牌转换为传统 API Key）[来源 #2]

  • AEGIS 预执行拦截：Agent 工具调用的框架无关安全控制点。当前主流框架（LangChain、AutoGPT 等）把安全能力内置在各自实现里，导致跨框架无法统一管控。AEGIS 在工具执行前拦截，不修改框架内部逻辑，支持 14 个框架（Python、JavaScript、Go）[来源 #3]

  • 防篡改审计追踪：Ed25519 签名 + SHA-256 哈希链——每条记录包含前一条记录的哈希值，无法删除中间某条记录而不被发现；高风险操作的人工审批决策也记录在链上，可追溯谁在什么时间批准了什么。Agent 安全不只是拦截能力，还包括"出事后能不能把链路讲清楚"[来源 #1, #3]

方法论与框架 ​

框架一：MCP Top 10 四组分类（OWASP） ​

风险组编号核心
身份与权限类1、2、7核心是 token 管理、权限边界、身份绑定
工具与协议完整性类3、4核心是 schema/manifest 可信度、依赖链完整性
执行链路类5、6核心是输入净化、意图锚定、上下文信任边界
运行时治理类8、9、10核心是可见性、审计、影子实例发现、上下文隔离

完整十大风险按 MCP 特有性（★ 数）分级——其中 LLM01（Token 管理）、LLM02（权限蔓延）、LLM03（工具投毒）、LLM06（意图流劫持）、LLM09（影子 MCP）、LLM10（上下文注入）均为 ★★★ MCP 特有高危[来源 #1]

框架二：MCP 五条可复用决策规则 ​

  1. 任何 secret 都不应该进入 context 或 log——包括临时凭证
  2. 外部取回的自然语言内容统一视为不可信——无论来自哪个受信来源
  3. schema 变更 = 代码变更——需要同等级别的审查和签名
  4. 先做 MCP 资产盘点——找出所有活跃实例，再谈加固
  5. 审计链是安全基线——没有不可篡改审计链的 MCP 系统不应上生产

这五条规则在工程化时可作为 MCP 系统上线的硬性门禁条件[来源 #1]

框架三：Agent IAM 两层认证挑战 ​

层次问题方案
智能体认证智能体软件本身是否可信工作负载身份（SPIFFE/SPIRE、客户端 ID 元数据）
用户委托认证用户授权意图是否被可验证地捕获OAuth 2.1 + PKCE + OBO 流程

代表用户行动的智能体必须同时解决两个认证问题，单解决其一都不构成完整方案[来源 #2]

框架四：智能体身份的四种架构模型 ​

模型适用场景特点
增强型服务账户企业近期部署扩展现有工作负载身份，token 中富含 agent_model/version 元数据
委托用户子身份直接代表用户行事OBO 流程，身份不同但与用户权力绑定
联合信任与互操作跨域无中央 IdPOpenID Federation + X.509 证书跨信任域验证
主权可移植身份去中心化生态DID + 自管理加密密钥，点对点断言身份

四种模型对应不同部署形态——大多数企业从增强型服务账户开始，逐步演进到委托用户子身份；跨域场景才需要联合信任；主权可移植身份对应公链/Web3 生态[来源 #2]

框架五：六大失效场景与对应解法 ​

场景核心挑战解法方向
高速智能体同意疲劳预授权 + 策略即代码
异步长任务令牌超期、持久委托CIBA + 委托身份作一等公民
跨域联合无统一 IdPOAuth 令牌交换 + 可验证凭证
递归委托网络权限无法衰减Biscuits/Macaroons 离线衰减令牌
信息物理系统操作不可逆机器可读操作范围策略 + 强制升级人类审批
代表多名用户权限交集问题ABAC 细粒度授权（当前无完美方案）

最后一条"代表多名用户"在 2026 年仍无完美方案，是身份管理研究的开放问题[来源 #2]

框架六：可扩展同意三模式（解决同意疲劳） ​

单个用户可能有数十个智能体每天做出数千决策。三种新模式取代"每操作点一次批准"：

  1. 策略即代码：预定义运营范围（预算上限、数据访问层级），IAM 程序化执行
  2. 基于意图的授权：用户用自然语言批准高级意图，系统转化为最小权限许可集
  3. 基于风险的动态授权：常规操作自动批准，异常操作触发 CIBA 带外人类审批

三种模式可组合——常规走"策略即代码 + 基于意图"，异常触发"基于风险 + CIBA"[来源 #2]

框架七：AEGIS 三阶段管道 ​

[14 个 Agent 框架 SDK 层]
        ↓ 拦截 tool_use
[AEGIS 网关 - 三阶段管道]
        ↓
  阶段 1：深度字符串提取    → 遍历嵌套结构 / Base64 / 序列化对象
  阶段 2：内容优先风险扫描  → SQL 注入 / 命令注入 / 路径遍历 / 数据泄露
  阶段 3：可组合策略验证    → 允许 / 拦截 / 升级人工审批
        ↓
[合规驾驶舱 - 人工审核待定调用]
        ↓
[防篡改审计追踪 - Ed25519 签名 + SHA-256 哈希链]

设计哲学：前两阶段做技术判断（可自动化）；第三阶段做业务判断（必要时才触发人工介入）。8.3ms 中位延迟的来源：大部分调用在前两阶段完成，只有高风险操作进入人工审批[来源 #3]

框架八：Agent 应用部署前自检清单 ​

已有 Agent 应用必须评估的三个问题：

  • 模型生成的工具调用是否会经过框架无关的控制点？
  • 这个控制点能否在执行前拦截（而不只是事后记录）？
  • 拦截策略是否可以跨框架、跨语言统一管理？

三个答案都是"否" → Agent 应用处于裸奔状态[来源 #3]

框架九：多租户 Agent 上线 8 项安全检查（PM 视角） ​

框架八是单租户 Agent 的 3 项基础自检。当 Agent 服务多个企业租户时，隔离失败 = 数据泄漏 = 大客户流失 + 合规罚款。以下 8 项检查从 PM / 产品负责人视角出发，覆盖六面隔离的安全维度。

#检查项通过标准失败后果
1数据存储层隔离tenant_id 行级 / 库级 / 物理隔离已实施，且有自动化测试覆盖跨租户查询A 租户直接读到 B 租户数据
2RAG 检索层 Pre-filtering向量检索链路中 tenant_id 在相似度计算前过滤（Pre-filtering），且应用层做二次校验检索结果泄漏无权文档，过不了安全审计
3Prompt 装载链路校验四层 Prompt（平台/行业/租户/用户）装载时校验 tenant_id 一致性，且版本化可回滚加载错误租户 Prompt = 越权 + 业务规则泄漏
4长任务状态分区持久化状态按 tenant 分区（Redis db / 表 schema / bucket），断点续跑时强制校验 tenant_id状态串台 = 不可恢复事故
5工具权限隔离工具白名单按租户动态管理，凭据存保险柜且按租户隔离凭据泄漏引发链式攻击
6计费配额隔离按租户独立计 token / QPS / 存储，配额耗尽时只影响该租户配额漏算 = 无法定价；资源争抢 = 租户间互相拖慢
7跨租户访问红队演练季度内至少一次模拟攻击（尝试以 A 租户身份访问 B 租户资源），报告 + 修复闭环无演练 = 不知道隔离是否真的生效
8框架八的 3 项基础自检模型工具调用经过框架无关控制点 + 执行前可拦截 + 跨框架统一管理Agent 基础安全裸奔（与多租户无关但是前提）

框架十：Computer Use Agent 安全部署 4 条最佳实践 ​

来自 Anthropic CU 最佳实践（2026-05-13）。CU Agent 直接操作用户桌面/浏览器，安全风险从"数据层"升级到"操作层"——一次误操作可能不可逆（删文件、发邮件、提交表单）。以下 4 条是 Anthropic 官方推荐的 CU 安全部署底线。

#实践工程要点不做的后果
1Human-in-the-loop 常驻关键操作（支付、删除、发送）前强制弹窗确认；不可逆操作永远不允许自动批准CU Agent 自主执行破坏性操作，无人知晓
2权限范围最小化CU Agent 运行环境限制可访问的应用/网站/目录；禁止访问密码管理器、银行网站、管理后台Agent 被 prompt injection 劫持后，攻击面等于用户全部权限
3操作日志全程记录每步截图 + 动作 + 时间戳写入不可篡改日志；支持事后回放完整操作链路出事后无法追溯"Agent 在什么时间做了什么"
4网页内容视为不可信浏览器中获取的所有文本/图片/脚本统一视为外部不可信输入；与 MCP 决策规则 2"外部取回的自然语言内容统一视为不可信"同源网页嵌入恶意指令劫持 Agent 行为（意图流劫持的 CU 变体）

与本方向其他框架的关系：

  • 框架十的第 4 条与 MCP 决策规则 2 同源——不可信输入原则从"MCP 工具返回内容"扩展到"CU Agent 浏览器所见一切"
  • 框架十的第 3 条与 AEGIS 防篡改审计追踪同源——CU 操作日志是 Agent 审计链在"屏幕操作"维度的延伸
  • 框架十是框架八"执行前可拦截"在 CU 场景的具体化——CU 的"执行"不是 API 调用，是鼠标点击和键盘输入

（来源：Anthropic CU 最佳实践博客"Prompt injection defenses" + "Security best practices"节，2026-05-13）

与框架八的关系：框架八是地基（单租户也要过），框架九是上层建筑（多租户额外要求）。8 项中第 8 项就是框架八本身——如果框架八都没过，多租户检查无意义。

风险与机会：

  • 🚨 风险：8 项中任一项缺失都可能导致跨租户数据泄漏——安全不是最强面决定的，是最弱面决定的
  • 🚀 机会：通过全部 8 项检查可作为安全合规的卖点写入合同 SLA，成为竞争壁垒

可行动项：

  • P0 → 对照 8 项清单逐项检查当前产品状态，输出"多租户安全缺口清单"（PM + 安全 + 工程，2 周内完成）
  • P2 → 建立季度红队演练机制（第 7 项常态化）（PM + 安全，季度内启动首次演练）

（来源：多租户 Agent 隔离设计实践，B2B SaaS 工程向，2026-05-20；与 Agent工程实践与工具生态 第四章联动）

案例库 ​

案例 A：工具投毒的隐蔽性（MCP 特有高危） ​

  • 场景：一个无害操作名（如 archive_old_records）实际映射到破坏性动作（DELETE FROM records）
  • 为什么难防：日志里看到的仍是"合法调用"，agent 是按照 schema 行动的，但 schema 本身已被污染
  • 防护方向：对 schema 和 manifest 做签名校验；Registry 做成不可变 + 可追溯；Schema 变更实施多人审批；把语义约束写成 policy（如"archive 不能映射为 DELETE"）[来源 #1]

案例 B：意图流劫持的两个典型攻击向量 ​

  • 向量一：让 agent 总结日志 → 日志里的隐藏指令诱导 agent 外传日志
  • 向量二：让 agent 查仓库状态 → 仓库文本里的恶意内容触发额外动作
  • 共性：攻击都发生在 agent 自己的执行链路内部，外部 prompt 净化无法阻止
  • 防护方向：锚定用户原始目标（全程追踪 intent）；外部取回的自然语言上下文统一视为不可信；检测执行动作是否偏离原目标；高风险偏移时强制人工确认[来源 #1]

案例 C：OBO 流程中的双身份 JWT ​

JWT {
  sub: "user_alice"         # 授权的用户
  act: "agent_assistant_v2" # 执行操作的智能体
}

PEP 可据此生成区分"谁授权"与"谁执行"的审计日志，解决传统 Impersonation 模式下的问责黑洞[来源 #2]

案例 D：递归委托的级联故障 ​

  • 背景：主智能体委托给子智能体，子智能体进一步委托给孙智能体
  • 风险：链末端的孙智能体出问题时，故障会沿委托链向上传播
  • 解决：链末端的资源服务器必须能加密验证回溯到原始用户的整个委托路径；取消配置（De-provisioning）必须不可逆、全系统传播
  • 机制对比：OAuth 2.0 令牌交换（中心化策略控制）vs Biscuits/Macaroons（去中心化离线衰减）[来源 #2]

案例 E：AEGIS 性能指标 ​

指标数值
中位延迟增加8.3ms（1000 次连续拦截）
误报率1.2%（500 个良性工具调用）
攻击拦截率100%（48 个精心设计的攻击实例）

启发：预执行拦截层的工程化已经能做到生产可用——8.3ms 延迟对绝大多数 Agent 应用是可接受成本[来源 #3]

案例 F：经济层的智能体支付协议 ​

协议解决问题核心机制
FAPI 2.0高风险 API（银行转账等）发送者受限令牌（mTLS/DPoP）+ 严格同意记录
AP2（Google）自主商业交易意图验证签名授权书（Intent Mandate + Cart Mandate）构成不可否认审计链
KYAPay智能体首次与新服务交互冷启动"了解你的智能体"(KYA) + JWT 绑定身份声明与支付授权

经济层是 Agent IAM 的延伸——当 Agent 可以代表用户做出有金钱后果的决策，传统支付授权链需要新协议支撑[来源 #2]

案例 G：Anthropic Computer Use 内置 Prompt Injection 三层防御 ​

  • 场景：CU Agent 在浏览器中操作时，网页内容可能包含恶意指令试图劫持 Agent 行为（如隐藏的"ignore previous instructions"文本）
  • 三层防御架构：
层机制特点
L1 训练时加固通过 RL 在训练阶段教模型识别和抵抗 prompt injection内化到模型权重中，零运行时开销
L2 实时分类器部署分类器实时检测对话中的注入尝试运行时拦截，覆盖训练未见过的新型攻击
L3 持续红队演练持续人工 + 自动化红队测试发现新攻击向量闭环更新 L1 和 L2，对抗攻防演化
  • 关键限制：三层防御仅在使用 Anthropic 官方 computer_20251124 工具类型时自动启用。自建 CU 工具（如自定义截图+点击工具）不享受这些内置保护——安全防线与 API 工具声明绑定，不与模型能力绑定
  • 与本方向"预执行拦截"的关系：Anthropic 的三层防御是 Agent-native safety（AI 厂商内置于模型/API 的安全能力），AEGIS 预执行拦截是 Enterprise-wide governance（跨模型跨框架的外置安全层）。两者互补不替代——用官方 CU 工具可获得 L1-L3 保护，但企业若同时使用多家 AI 厂商的 CU 能力，仍需 AEGIS 类外置层做统一治理
  • PM 启示：构建 CU Agent 产品时，必须使用 Anthropic 官方工具类型而非自建工具——这不仅是功能差异，更是安全防线的有无之别

（来源：Anthropic CU 最佳实践博客"Prompt injection defenses"节，2026-05-13）

关键洞察 ​

  1. MCP 安全的核心是"出事后能不能把链路讲清楚"：8 大风险中"审计与遥测缺失"的危险特性是静默性——没有被监控的 agent 可能连续数周执行敏感操作或外传数据，无人知晓。MCP 安全不只是拦截能力，还包括事后审计链。这一原则与 AEGIS 的防篡改审计追踪是同源思想[来源 #1, #3]

  2. MCP 工具投毒和 Skill 安全是两条平行赛道：Skill Top 10 关注"装进 Agent 里的能力包本身"（打包、分发、权限声明、加载、隔离），MCP Top 10 关注"模型通过协议连接外部工具时调用链会不会失控"（token、身份、工具契约、上下文）。两者互补不替代——企业部署 Agent 时要同时建立两套治理体系[来源 #1]

  3. 身份管理范式必须从 Impersonation 转向 Delegation：智能体直接使用用户凭证 = 模拟 = 问责黑洞。OBO 流程在 JWT 中同时携带 sub（用户）和 act（智能体）是范式转换的具体实现。这一转换不仅是技术细节，更是合规要求——GDPR 等法规对"谁做了什么"的追溯要求 Agent 时代仍然成立[来源 #2]

  4. 递归委托是 Agent IAM 最难的问题：单个受损智能体身份可通过递归委托引发级联故障，因此取消配置必须不可逆、全系统传播。Biscuits/Macaroons 这类基于 OCap 模型的去中心化离线衰减令牌是新方向，但与现有 OAuth 生态集成仍有挑战[来源 #2]

  5. Agent 安全的工程化核心是"框架无关的预执行控制点"：当前各主流框架（LangChain、AutoGPT 等）把安全能力内置在各自实现里，导致跨框架/跨语言/跨版本无法统一管控。AEGIS 这类"在工具执行前拦截、不修改框架内部"的网关化方案是工程方向，配套防篡改审计是事后追溯的兜底[来源 #3]

  6. 同意疲劳是 Agent 时代独有的新问题：单个用户可能有数十个智能体每天做出数千决策，"每操作一次批准"在物理上不可能。三种新模式（策略即代码 / 基于意图 / 基于风险动态）是 IAM 产品角度必须支持的能力——批准粒度从"操作级"上移到"意图级 + 风险触发"[来源 #2]

  7. Agent 安全的三层独立但必须联动：协议层（MCP 加固）+ 身份层（IAM/OBO）+ 执行层（预执行拦截）任何一层缺位都构成裸奔。但三层不能相互替代——MCP 把好门不等于身份不会失真，IAM 严格不等于工具调用安全，执行层拦截不等于审计能讲清楚。企业部署 Agent 必须三层同建[来源 #1, #2, #3]

  8. 第四层 endpoint 治理（AES）是 Agent 安全的产业化落地形态：协议-身份-执行三层是 Agent 安全的工程内核，但企业真正落地时还需要第四层——endpoint 上的"agent / MCP server / IDE 扩展 / 浏览器扩展 / npm·PyPI 包 / 本地模型 / 容器"如何在 install-time 被治理。Palo Alto 2026-04-14 收购 Koi 并命名 AES（Agentic Endpoint Security）就是这一层的产业化代表——Koi 提出的 "Supply Chain Gateway" 把 GitHub / Hugging Face / Chrome Web Store / VS Code Marketplace / Homebrew 入口纳入控制，正是"影子 MCP（LLM09）发现 + 工具投毒（LLM03）预防 + 软件供应链攻击（LLM04）治理"在 endpoint 侧的工程化对应。对应关系：LLM09 Shadow MCP → AES 资产发现；LLM03/LLM04 工具投毒与供应链 → AES Supply Chain Gateway；LLM08 审计与遥测缺失 → AES 工具调用审计；本方向的"案例 A 工具投毒"与"案例 B 意图流劫持"在 endpoint 侧的兜底治理面 = AES（来源：用户提供文本「Palo Alto花30亿买下Koi」，2026-05-19；关联《AI 重塑网络安全》v1.1 案例 G）

  9. Agent 从"回答"走向"行动"使安全从可选项升级为基础设施级刚需：📌 2026-05-20 Anthropic 收购 Stainless（SDK/CLI/MCP Server 工业化生成平台）的潜台词之一——当 Agent 大规模进入真实系统（读文档、调数据库、操作 SaaS、发请求、改配置、查订单），权限/审计/风控/隔离/回滚不再是"安全加分项"，而是 Agent 能否被企业采纳的前置门槛。工具连接能力的爆发式增长与安全治理能力必须同步扩展——这与本方向"多租户 Agent 上线 8 项安全检查"的工程判断同向：Agent 能调用的工具越多，安全基础设施的覆盖面就越不能有缺口。（来源：Anthropic 收购 Stainless 公告分析，2026-05-20）

观点张力 ​

  • 中心化 vs 去中心化的范围衰减：OAuth 2.0 令牌交换（中心化，集中策略控制）vs Biscuits/Macaroons（去中心化，OCap 模型）。前者更易管控但有单点故障，后者更弹性但撤销传播是难题。2026 年企业级首选中心化路径，但 Web3 / 多组织协作场景倒逼去中心化方案演进[来源 #2]

  • 预执行拦截 vs 模型自带拒绝能力：AEGIS 主张"安全不能依赖模型自觉"，必须在工具执行前外置拦截；模型厂商主张通过 RLHF / Constitutional AI 让模型自身具备拒绝有害工具调用的能力。两条路径不冲突但产品角度——可审计的外置拦截层更适合企业级生产部署[来源 #3]

  • 开放协议 vs 厂商专有：IPSIE 等标准化工作组推动 Agent 身份的开放协议互操作，但供应商专有智能体身份系统在快速涌现。OpenID Foundation 的白皮书明确把"碎片化风险"列为未解难题——产品规划时押注开放标准是更稳路径，但短期可能错过专有生态红利[来源 #2]

  • 隐私 vs 问责：可追溯性是 Agent 审计的核心要求，但全链路追踪会创建详尽的行为档案，与隐私保护冲突。零知识证明是方向但与现有标准集成困难。当前没有完美方案[来源 #2]

  • Agent-native safety（AI 厂商内置）vs Enterprise-wide governance（安全厂商跨 Agent）：AI 公司（OpenAI / Anthropic / Google / Microsoft）能把安全做进 agent 自身——agent 自己知道何时该问人、何时降权、何时拒绝；模型厂商也最懂 prompt injection / tool confirmation / sandbox 边界。但企业现实是同时用 ChatGPT / Claude / Gemini / Copilot / Cursor / Windsurf / 开源 agent / 垂直 agent，CISO 想买的是"all agents security"而非"Claude security"——这一中立性要求决定了"agent-native safety"无法独占企业治理面。安全厂商（Palo Alto / CrowdStrike / Microsoft Security 等）天然跨模型跨 agent，且已接 SIEM/SOAR/IdP/DLP/SASE/CASB/XDR，更适合做企业治理控制台。最终格局：AI 厂商守 agent-native safety 上限（用户体验、模型级 telemetry），安全厂商守 enterprise-wide governance（跨 agent 治理、合规审计、SOC 联动），平台型厂商做融合。这与本方向"执行层预执行拦截"的"安全不能依赖模型自觉"是同源思想（来源：用户提供文本「Palo Alto花30亿买下Koi」，2026-05-19）

待探索问题 ​

  • IPSIE / MCP / OpenID Federation / SCIM 等标准在 2026—2027 年的演进路径是什么？哪些会成为事实标准？
  • Biscuits/Macaroons 的工程落地案例——除了 CockroachDB、Tailscale 之外，在 Agent 场景下是否有规模化生产部署？
  • 浏览器/Computer-Use 智能体绕过 API 授权层的问题是否能解决？Web Bot Auth 协议方向的进展？
  • AEGIS 这类外置拦截层在多 Agent 协同（A2A）场景下是否仍有效？跨 Agent 工具调用的拦截点应该建在哪一层？
  • 影子 MCP 服务器的发现工具——是否会出现专门的"MCP 资产盘点"产品类？类似 CMDB 但专门为 MCP？
  • 同意疲劳的"基于意图的授权"如何避免意图理解偏差导致的过度授权？意图描述的形式化标准是什么？
  • 持久化上下文（agent memory）的多租户隔离工程实现——namespace 严格隔离是否足够？内存层泄露的检测方案？
  • 多租户 Prompt 装载链路的形式化验证：四层 Prompt 叠加时是否有形式化方法证明"不可能加载错误租户的 Prompt"？还是只能依赖运行时校验 + 测试覆盖？
  • 跨租户红队演练的自动化：是否能把"以 A 租户身份尝试访问 B 租户资源"的攻击场景自动化为 CI/CD 管道中的安全测试？
  • 智能体支付协议（FAPI 2.0 / AP2 / KYAPay）在国内场景下的合规路径——与人民银行、网信办的监管要求如何对齐？

来源索引 ​

#标题来源收录日期贡献章节
1OWASP MCP 十大安全风险全景：Token 管理、工具投毒、上下文注入OWASP MCP Top 102026-04-13协议层 / MCP 十大风险 / 案例 A-B / 决策规则
2OpenID 智能体身份管理白皮书 — 委托授权、递归委托与 Agent IAM 全景OpenID Foundation 2025-102026-04-14身份层 / Agent IAM / 案例 C-D / 案例 F
3AEGIS 预执行拦截 — Agent 工具调用安全护栏三阶段架构微信公众号（arxiv 2603.12621）2026-04-14执行层 / AEGIS 三阶段 / 案例 E / 自检清单

注：原始单笔记已于 2026-05-18 路由整合后归并删除，本文档为唯一沉淀载体。

关联方向 ​

  • 姐妹方向：《AI 系统安全攻防体系》（docs/01-认知/技术认知/05-AI与Agent/05-AI安全/AI系统安全攻防体系.md）——本方向覆盖 Agent 系统特有的安全工程（协议/身份/执行）；姐妹方向覆盖单模型/单应用的攻击分类与护栏产品。CSA 12 类 Agent 威胁是两个方向的接合面。
  • 姐妹方向：《AI 重塑网络安全》（docs/01-认知/技术认知/05-AI与Agent/05-AI安全/AI重塑网络安全.md）——其中 NHI（非人类身份）/ 影子 Agent 检测 / 零常驻权限是本方向"Agent IAM"的产业层投射。
  • 关联：《Harness 失效模式与反馈机制》（docs/01-认知/技术认知/05-AI与Agent/02-Harness工程/Harness失效模式与演化方向.md）——Harness 视角下的工具调用稳定性问题，与本方向的"执行层预执行拦截"是同一问题的两个面（一个看可靠性，一个看安全性）。
  • 关联：《AI 重塑网络安全》新增「AES（Agentic Endpoint Security）新品类」节点（v1.1，2026-05-19）——Palo Alto 收购 Koi 把"协议-身份-执行"三层之外的第四层 endpoint 治理产业化。本方向的 LLM09（Shadow MCP）/ LLM03（工具投毒）/ LLM04（软件供应链攻击）/ LLM08（审计与遥测缺失）在 endpoint 侧的工程化对应，正是 AES 的核心治理对象（agent / MCP / IDE 扩展 / 浏览器扩展 / 包 / 本地模型 / 容器）。两个方向构成"工程内核（本方向）+ 产业落地形态（AES）"的互补关系。
  • 关联：《Agent 工程实践与工具生态》第四章"多租户 Agent 工程"（../01-Agent核心/Agent工程实践与工具生态.md）——本方向框架九（多租户 Agent 上线 8 项安全检查）是该章六面隔离对照表在安全维度的展开。Pool/Bridge/Silo 隔离模式选型直接决定安全检查的深度要求。

演进记录 ​

日期版本变更摘要
2026-05-18v0.1首次构建，由 /route-knowledge 路由分析触发。融合 3 篇来源（OWASP MCP / OpenID Agent IAM / AEGIS），沉淀 8 个方法论框架、6 个案例、7 条关键洞察、4 组观点张力、8 个待探索问题
2026-05-19v0.2/route-knowledge 路由整合"Palo Alto/Koi/AES 品类诞生"长文（主沉淀在《AI 重塑网络安全》v1.1）。本方向轻量补充：新增关键洞察 8（第四层 endpoint 治理 AES 是 Agent 安全的产业化落地形态）+ 新增观点张力（Agent-native safety vs Enterprise-wide governance）+ 关联方向新增 AES 节点指针
2026-05-20v0.3由 /route-knowledge-pm 路由触发：新增框架九"多租户 Agent 上线 8 项安全检查（PM 视角）"——覆盖数据存储/RAG检索/Prompt装载/长任务状态/工具权限/计费配额/红队演练/基础自检 8 面。待探索问题 +2（Prompt 形式化验证 / 红队自动化）。关联方向新增 Agent 工程实践与工具生态第四章指针
2026-05-20v0.4由 /route-knowledge-pm 路由触发（Anthropic CU 最佳实践 2026-05-13）：新增框架十"Computer Use Agent 安全部署 4 条最佳实践"（Human-in-the-loop / 权限最小化 / 操作日志 / 网页内容不可信）；新增案例 G"Anthropic CU 内置 Prompt Injection 三层防御"（训练时 RL / 实时分类器 / 持续红队）。来源数 3 → 4

MIT License

Copyright © 2026 Derek