AI Agent 正在冒用他人身份：审计日志的隐性危机

当团队将 AI Agent 接入真实系统（支付 API、CRM、文档库）时，最快的做法往往是直接给它一个现成的凭证：服务账号，或者开发者环境里已有的 API Key。第一次尝试就能跑通，而问题恰恰出在这里。

从那一刻起，Agent 的每一个动作都被记录为该凭证所有者的操作。审计日志什么都没漏，却自信地错了——它显示某人批准了转账、编辑了记录或拉取了文件，而实际上是 Agent 代表此人执行的，可能发生在本人最后一次查看系统数小时之后。

为什么这比听起来更严重

对大多数软件而言，“这是谁干的”只是个调试问题。但在受监管的领域，这是审查员、审计师或客户安全团队最先提出的问题：

• 支付与银行：谁发起了这笔资金流动？依据什么权限？
• 经纪业务：谁授权了这笔交易？
• 医疗健康：哪个进程读取了该患者的记录？是否遵循了最小必要原则？
• 法律：谁检索了这份特权文件？

如果诚实的答案是“一个 Agent，用了某人的密钥”，你的记录无法呈现这一点，因为它们只认识密钥。

最小必要原则（Principle of Least Privilege）是信息安全中的基础准则：任何主体——用户、进程或服务——只应获得完成其当前任务所必需的最小权限，且仅在必要的时间内持有。这一原则最早由 Saltzer 与 Schroeder 于 1975 年系统提出，如今已写入 HIPAA、PCI DSS、SOX 等多项合规框架。对 Agent 而言，实践难点在于权限往往随凭证一并继承：开发者图省事复用自己的 API Key，Agent 便自动获得了该开发者名下的全部权限，远超单一任务所需。最小必要原则要求按任务动态签发短期、窄范围的凭证，而非长期复用宽权限密钥。

在审计与合规语境中，不可否认性（Non-repudiation）指系统能够确凿证明某项操作确实由特定主体发起，且该主体无法事后否认。传统访问模型默认“凭证持有人即操作人”，因此日志中的身份字段天然具备不可否认性。但 Agent 复用人类凭证后，这一假设被打破：日志记录的是凭证所有者，实际操作者却是 Agent，导致记录在形式上完整、在实质上失真。对于金融交易、医疗记录访问等场景，这种失真会直接瓦解审计链条——审查员无法据此判断责任归属，也无法验证操作是否获得恰当授权。

关于已连接 Agent 的三个必问问题

要评估任何已接入系统的 Agent，不妨从三个具体问题入手：

1. 每个工具调用以什么身份运行？ 不要看架构图上的说明，挑一个真实调用追踪下去。
2. 该身份能触及的范围，与任务实际需要相比如何？ 一个只负责汇总单个账户的 Agent，通常持有一把能读取所有账户的密钥。
3. 事后能否将 Agent 的行为与人的行为分开证明？ 如果 Agent 操作和人类操作在日志中归在同一个人名下，答案就是否定的。

这三个问题直指身份归属与权限边界，是排查风险的最小切口。

理想状态应该是什么样

一套可审计的 Agent 接入方案应满足以下条件：

• Agent 拥有自己的身份，与任何人类身份区分开。
• 其凭证按任务限定范围，而非从搭建者那里继承。
• 每次调用都记录 Agent、授权许可及（如有）批准人 三要素。
• 沙箱与生产环境的凭证相互隔离，生产密钥绝不放在编码 Agent 可读取的位置。

这些并非新奇要求。它们只是把常规的最小权限原则和审计追踪实践，应用到了一类大多数访问模型从未设计考虑的新主体上。

服务账号（Service Account）是为非人类主体设计的机器身份，常见于云平台与操作系统。它与人类账号的关键区别在于：不绑定个人、通常不启用交互式登录、凭证可轮换且权限可精细配置。然而，直接给 Agent 分配一个静态服务账号仍不充分——服务账号往往长期有效、权限宽泛，且多个 Agent 可能共用同一账号，导致日志中无法区分具体是哪个 Agent 实例所为。更理想的做法是为每个 Agent 实例签发独立身份，并结合短期令牌（如 OAuth 2.0 的客户端凭证模式或 SPIFFE 等工作负载身份标准），使凭证生命周期与任务周期对齐。

多源视角下的共识与分歧

本文的核心论点与 Jonathan Melton（FusionAL 创始人，专注审查 AI Agent 与 MCP 工具接入受监管系统时的权限配置）的观察一致。综合来看，行业对这一问题的认知存在明确共识：身份冒用是 Agent 接入的默认陷阱，而非偶发失误。

在具体解法上，各方略有分歧：一部分观点强调从身份层入手，为 Agent 建立独立身份与细粒度授权；另一部分则更看重运行时监控与日志分离，认为先让行为可区分、再逐步收紧权限更为务实。两种路径并不互斥，但优先级选择会影响落地节奏。

单一来源的洞见中，Melton 提出的“三个必问问题”尤其具有操作性——它们不依赖特定工具链，能直接用于现有系统的自查。

MCP（Model Context Protocol）是 Anthropic 于 2024 年底提出的开放协议，用于标准化 AI 模型与外部工具、数据源之间的连接方式。它让 Agent 能以统一接口调用文件系统、数据库、API 等资源，大幅降低了工具接入成本。但 MCP 本身聚焦于“如何连接”，并未规定“以什么身份连接”——工具服务器通常沿用部署环境的凭证，这恰恰放大了身份冒用风险。因此，在 MCP 生态中落地 Agent 独立身份与细粒度授权，需要额外在工具服务器侧引入身份代理或凭证交换机制，而非依赖协议默认行为。

实践建议

对于正准备或已经将 Agent 接入生产系统的团队，可以按以下顺序推进：

• 先审计再改造：挑选一个高频 Agent 调用，完整追踪其身份链路，确认日志中人与 Agent 是否混同。
• 拆分凭证：将 Agent 的服务账号与人类账号彻底分离，按任务最小权限重新签发。
• 隔离环境：确保生产密钥与沙箱、编码环境物理隔离，避免开发便利性侵蚀安全边界。
• 补充审批记录：在日志中显式记录授权来源与批准人，让“谁批准、谁执行”一目了然。

Agent 带来的效率提升是真实的，但若身份归属含糊，效率的代价可能是无法通过一次合规审查。把 Agent 当作一个有名字、有权限边界、有审计轨迹的独立主体来对待，才是可持续的接入方式。