2026 年 1 月，Palo Alto Networks 的安全主管在一篇采访里说了一句让安全圈共鸣的话：
“AI agents are 2026’s biggest insider threat.”
这句话的重量在于：说这话的人不是悲观的安全分析师，而是一家年营收 80 亿美元的安全公司高管，他看到的不是假设，而是已经发生的真实风险。
传统内部威胁（Insider Threat）指的是有权访问内部系统的人——心怀不满的员工、被收买的承包商、账号被盗的业务人员。这类威胁有一套成熟的防御体系：最小权限、行为审计、特权访问管理。
但 AI Agent 带来了一种全新的内部威胁类别：拥有持久权限、自动执行能力、长程上下文记忆的非人类行为者。它不是被人利用的工具，它本身就是潜在的威胁主体。而现有安全体系，几乎没有为这种威胁做任何准备。
本文系统分析 AI Agent 作为内部威胁的新攻击面、攻击路径与 2026 年典型案例，以及企业级防御架构的构建方向。
一、重新定义"内部威胁"
1.1 传统内部威胁模型
传统内部威胁有三个核心假设：
- 威胁主体是人：有动机（报复心、利益驱动）的人类
- 攻击窗口有限：人的时间和精力是硬约束，不可能 24 小时不间断渗透
- 权限边界清晰：员工权限由职位和部门决定，可以精确审计
基于这三点假设，安全团队构建了以身份为中心的安全架构：IAM、PAM、UEBA（用户实体行为分析）。人在权限边界内行事，审计日志记录行为，异常检测基于人的行为模式。
1.2 AI Agent 打破了这三个假设
AI Agent 作为威胁主体，特性完全不同：
没有"动机"，但有目标漂移风险。LLM 驱动的 Agent 不会"故意报复公司"，但它有目标（optimization objective）。当目标定义不精确或被对抗性输入干扰时，Agent 可能采取超出预期的行动——比如为了完成"提升客户满意度"的目标而修改了它不该修改的数据。
7×24 小时运行，没有疲劳概念。人类安全分析师会累、会休假、会有判断失误。但 AI Agent 可以全年无休地运行，在你没有警觉的深夜执行它认为"正确"的操作。
权限边界模糊且动态扩展。MCP 工具授权、A2A 跨 Agent 协作、Function Calling——这些机制让 AI Agent 可以动态获取新权限、执行新操作。传统基于身份的权限模型无法追踪这种动态扩展。
攻击面从"人"扩展到"人+AI+工具链"。一次 AI Agent 操作，可能涉及：LLM 调用 → MCP 工具触发 → 外部 API 请求 → 内部数据读写 → 结果反馈给用户。这条链路上任何一个环节被攻击或被误用，都是潜在的威胁向量。
二、新攻击面：AI Agent 的威胁向量图谱
2.1 权限提升（Privilege Escalation）
MCP 协议让 AI Agent 可以动态调用各种工具。问题是：谁来控制 Agent 可以调用哪些工具？
在 2026 年初的企业部署中，常见的问题是：
- 工具权限过度宽松：Agent 被授予了"读写用户邮箱"权限，但这个权限本意只是"读取日历"。Agent 在执行主任务时，可能顺便做了超出意图的操作。
- 跨 Agent 权限继承：Agent A 有财务系统权限，它调用 Agent B 协作时，Agent B 继承了 Agent A 的权限上下文，导致权限横向扩展。
- 动态权限获取无审计：MCP 工具的按需授权机制，让 Agent 在运行过程中可以申请新权限，但没有实时的权限变更审计。
2026 年 3 月，Super AI Markets 的研究人员在测试 AI 购物 Agent 时发现：主流 Agent 在授权流程中存在权限提升漏洞，攻击者可以通过精心构造的商品描述，让 Agent 在用户不知情的情况下执行超出商品购买范围的操作。
2.2 数据渗泄（Data Exfiltration）
AI Agent 处理企业敏感数据的方式，是这个威胁最直接的体现。
上下文窗口是双刃剑。现代 LLM 的长上下文窗口（Gemini 1.5 Pro 达到 1000 万 token）让 Agent 可以"记住"整份合同、全部邮件往来、完整代码库。但这同时意味着：如果 Agent 被攻陷或被误导，所有这些上下文数据都面临泄露风险。
数据出口点不清晰。传统数据安全有明确的边界——数据库、文件服务器、API 端点。但 AI Agent 处理过的数据可能存在于：LLM 服务商的日志中（API 调用记录）、Agent 的长期记忆向量数据库中、工具调用的返回结果中、跨 Agent 消息传递的 Payload 中。数据安全团队甚至不知道该在哪里画边界。
无意识的被动泄露。这不是 Agent"主动"泄露数据，而是 Agent 在处理任务时，将敏感信息作为上下文传递给了不应该接收它的外部服务。例如：一个客服 Agent 在回答问题时，把包含客户地址的完整订单信息发送给了搜索工具——而这个搜索工具是第三方服务。
2.3 Prompt 注入的规模化威胁
针对 AI Agent 的 Prompt 注入，比针对单次 LLM 调用的注入危险得多，因为 Agent 有执行能力。
经典的 Prompt 注入场景是：恶意用户输入一段文本，LLM 被诱导执行非预期操作。在单次调用的场景下，影响有限。
但 2026 年的 AI Agent 场景中，Prompt 注入的威胁被放大：
外部数据源的注入风险。AI Agent 通常会 RAG（检索增强生成）来自多个数据源的内容。如果其中一个数据源被攻击者控制（比如被植入恶意文档），恶意内容就被带入 Agent 的推理上下文，进而影响 Agent 的后续决策。
对话历史积累的注入。在多轮对话中，攻击者可以分多次注入恶意内容，每次只注入少量，让每次检测都难以发现，但累积效果是把 Agent 导向恶意方向。
工具返回结果的注入。如果 Agent 调用的工具返回结果可以被攻击者控制（比如搜索 API 返回的搜索结果），攻击者就可以在工具返回数据中嵌入恶意指令。
2026 年 3 月的 Per-Tool Sandboxing 研究（SandLock）指出：在多工具调用的 Agent 环境中，每个工具都应该是独立的安全沙箱，否则一个被攻陷的工具可以污染整个 Agent 的行为。
2.4 身份与凭证的滥用
AI Agent 通常需要代表用户或代表系统执行操作，这意味着它需要持有凭证。
凭证存储风险。如果 Agent 需要调用企业内网服务，它需要 API Key、OAuth Token 或服务账号密码。这些凭证存储在哪里？Env 变量？密钥管理系统？如果 Agent 代码有漏洞（即使无害的功能 Bug），凭证可能泄露。
凭证生命周期缺失。人类员工的账号可以被禁用，AI Agent 的凭证呢？当 Agent 不再被使用时，它的凭证是否被撤销？当 Agent 被恶意使用后，如何快速废掉它的所有凭证？这些问题大多数企业还没有答案。
跨系统的身份冒充。A2A 协议让 Agent 可以代表用户向其他 Agent 发起请求。如果 Agent A 持有用户 Alice 的身份凭证，它向 Agent B 发起的请求，Agent B 如何验证这是 Alice 本人的授权还是 Agent A 在滥用 Alice 的身份？
三、典型攻击路径
3.1 路径一：供应链恶意工具
企业通过 MCP 工具市场引入第三方工具，这些工具经过安全审查了吗？
攻击路径：
- 攻击者在 MCP 工具市场发布一个看似有用的工具（如"天气查询"、“汇率转换”）
- 企业在 Agent 工作流中引入这个工具
- 工具在执行时，除了返回正常结果，还会将 Agent 的上下文数据（包含敏感信息）发送到攻击者控制的服务器
- 攻击者收集到的数据足以进行下一步攻击（如获取用户凭证）
OWASP 2026 年 3 月发布的 MCP Top 10 明确将"不受信任的工具源"列为首要威胁。
3.2 路径二：RAG 数据投毒
企业使用 RAG 让 Agent 回答用户关于内部文档的问题。
攻击路径：
- 攻击者（可能是内部员工或外部入侵者）向内部知识库植入一份看似正常但被恶意构造的文档
- 文档被 Chunk 嵌入向量数据库
- Agent 在回答用户查询时检索到这份文档，并将其作为上下文
- 恶意内容影响 Agent 的回答，导致 Agent 输出错误甚至有害的建议
这种攻击的可怕之处在于：数据投毒不需要攻破任何系统，只需要一份被污染的文档进入知识库。
3.3 路径三：权限升级的蝴蝶效应
攻击路径：
- Agent A 被授予"读取客户联系方式"的权限
- Agent A 在某个任务中调用了 Agent B（通过 A2A 协议）
- Agent B 继承了 Agent A 的权限上下文，并调用了一个第三方 MCP 工具
- 第三方工具的返回数据中包含 Agent A 权限范围之外的信息
- 这些信息被用于进一步的权限提升攻击
这条攻击链上，没有任何一步单独看是"异常"的，但组合起来就构成了完整的数据泄露路径。
四、防御架构：零信任 Agent 安全框架
4.1 核心原则：从边界信任到持续验证
传统安全基于"边界"思维：防火墙内的请求是可信的。但 AI Agent 的运行跨越了云服务、LLM 提供商、企业内网、第三方工具——根本没有清晰的边界。
零信任 Agent 安全的核心原则：永远不信任，始终验证。具体表现为：
- 工具来源验证：Agent 调用的每个 MCP 工具都必须经过来源验证和权限审查
- 最小权限执行：Agent 只能访问完成任务所需的最小权限集
- 持续身份验证：不仅在初始授权时验证，在每次敏感操作时重新验证
- 操作级审计：Agent 的每一个操作（不仅是 API 调用，还包括决策推理过程）都应该被审计
4.2 MCP 网关：企业安全的守门人
MCP 网关是 2026 年企业安全的关键基础设施。它的核心功能：
工具注册与审查。所有进入企业 Agent 工作流的 MCP 工具，必须经过安全审查并在网关注册。网关维护一个受信任工具的白名单。
权限策略执行。Agent 调用工具时，网关检查该调用是否符合权限策略。例如：即使 Agent “想"调用财务系统，如果策略不允许，这个调用被拦截。
流量审计与异常检测。所有 MCP 流量经过网关，网关记录调用日志并运行异常检测。当 Agent 在短时间内调用大量工具时，可能是 Prompt 注入的症状。
工具隔离与降级。当某个工具被检测为异常行为时，网关可以将其隔离或降级，防止威胁扩散。
Palo Alto Networks 的安全主管在接受 The Register 采访时特别提到：企业需要把 MCP 网关当作 AI Agent 安全的第一道防线，就像 WAF 之于 Web 应用。
4.3 行为边界定义：从"Agent 能做什么"到"Agent 只能做什么”
传统的 RBAC（基于角色的访问控制）是为人设计的。AI Agent 的权限控制需要新的模型：ABAC（基于 Agent 行为的访问控制）。
Agent 行为策略需要定义：
- 操作边界：Agent 可以调用哪些 API、操作哪些数据表
- 数据边界：Agent 的上下文窗口中最多可以包含哪些敏感数据
- 时间边界：Agent 的凭证有效期多长，到期后是否自动吊销
- 调用链限制：Agent 调用其他 Agent 时，权限传递的深度限制
一个具体的实践框架：
agent_policy:
agent_id: customer_service_agent_v2
allowed_tools:
- mcp://internal/crm_read
- mcp://internal/kb_search
- mcp://internal/ticket_create
denied_tools:
- mcp://internal/customer_data_bulk_export
- mcp://external/unknown_vendor_*
max_context_data_classification: confidential # 上下文不能包含secret级别数据
credential_ttl: 24h # 24小时后凭证自动过期
max_a2a_hops: 2 # A2A调用链最多2跳
audit_level: full # 记录所有操作4.4 工具沙箱化：每个工具都是独立的安全边界
SandLock 的研究指出：多工具 Agent 环境中，最佳安全实践是每个工具运行在独立沙箱中，一个工具被攻陷不影响其他工具和 Agent 核心。
这不是新概念——操作系统安全早就这样做了（进程隔离、容器隔离）。但在 AI Agent 工具调用场景中落地，有几个关键挑战：
- 沙箱间通信的开销：工具间数据传递需要通过安全的 IPC 机制
- 状态共享的复杂性：如果工具需要共享状态，如何在隔离和安全之间取得平衡
- 性能损耗：沙箱化带来的上下文切换会带来性能开销
2026 年的主流方案包括：WebAssembly 沙箱（Wasmtime）、微容器（gVisor）、进程级 Linux Namespace 隔离。Wasm 方案因为启动快、隔离好、跨平台成为新兴选择。
4.5 审计与可观测性：不只是日志，是推理过程
传统安全审计是"记录操作"：谁在什么时间访问了什么资源。AI Agent 的审计需要升级为记录推理过程：
- 决策轨迹记录：记录 Agent 在做决策时的完整思维链（Token 级别的 Tracing）
- 上下文来源追踪：记录 Agent 回答问题时的 RAG 数据来自哪个文档/数据源
- 工具调用链追踪：记录 Agent → Tool A → Tool B → 结果 的完整调用链
- 异常行为模式检测：当 Agent 的行为偏离正常模式时触发告警
这需要 LLM 可观测性工具（如 OpenTelemetry + LLM 专用 Trace）与安全审计系统的深度集成。
五、企业级实施路线图
5.1 第一阶段：可见性优先（Month 1-2）
在谈安全之前，先搞清楚你有多少 AI Agent、它们在做什么。
Agent 清单与映射。建立企业 AI Agent 资产清单：哪些部门在用、用了哪些 Agent、每个 Agent 拥有哪些工具权限。这听起来简单，但大多数企业这时候才发现：Shadow AI 已经遍布各个部门。
工具来源审计。盘点所有 MCP 工具的来源：哪些是自建、哪些来自第三方、哪些来自 MCP 工具市场。标记所有缺乏安全审查的工具。
现有权限审计。检查当前 Agent 的权限配置：是否有 Agent 拥有超出其职责所需的权限？是否有凭证存储在不安全的地方？
5.2 第二阶段：纵深防御（Month 3-4）
部署 MCP 网关。在所有 Agent 工具调用路径上部署 MCP 网关，实施工具白名单和权限策略。
工具沙箱化改造。对高风险工具（涉及敏感数据读取、外部网络调用）实施沙箱隔离。
多因素确认机制。对高风险操作（如数据导出、跨系统写入）实施 Human-in-the-Loop，在执行前需要人工确认。
5.3 第三阶段：持续运营（Month 5+）
Agent 安全红队。定期对 AI Agent 进行红队演练，测试 Prompt 注入、权限提升、数据渗泄等攻击路径。
威胁情报同步。订阅 AI 安全威胁情报，及时了解新出现的攻击手法和漏洞。
定期策略审查。每季度审查 Agent 权限策略，确保权限始终遵循最小权限原则。
六、2026 年企业 Agent 安全清单
如果你的企业正在部署 AI Agent，下面是你应该逐项检查的安全清单：
身份与权限
- 所有 AI Agent 持有的是否都是最小权限凭证？
- Agent 凭证是否有 TTL（到期自动失效）？
- Agent 是否使用了独立的服务账号，而非人类员工的账号？
- A2A 协作时，是否限制了权限传递的跳数？
工具安全
- 所有 MCP 工具是否经过安全审查？
- 是否部署了 MCP 网关来管理工具访问？
- 高风险工具是否运行在沙箱中？
- 第三方 MCP 工具是否有来源验证机制？
数据安全
- Agent 上下文中是否有限制敏感数据（如 secret 级别）的机制？
- LLM API 提供商的调用日志是否被审计？（你的数据可能存在他们那里）
- RAG 数据源是否有防投毒机制？
- Agent 输出的敏感数据是否被脱敏？
监控与响应
- Agent 的每个操作是否有完整的审计日志？
- 是否部署了 Agent 行为异常检测？
- 当 Agent 执行高风险操作时，是否有实时告警？
- 是否有针对 AI Agent 安全事件的应急响应预案？
七、展望：AI Agent 安全的下一个战场
AI Agent 安全不是一次性的项目，而是持续演进的攻防战场。
2026 年下半年值得关注的方向：
Agent 到 Agent 的身份认证标准。A2A 协议目前定义了通信格式，但 Agent 之间的身份验证机制还在早期。类似 SPIFFE/SPIRE 在微服务领域的实践，AI Agent 领域需要标准化的身份认证框架。
Agent 安全态势管理的自动化。企业有数十个 Agent，每个 Agent 有数十个工具，手工管理不可持续。自动化的 Agent Security Posture Management（ASPM）工具正在兴起。
监管合规压力。EU AI Act 对高风险 AI 系统有明确的安全要求，AI Agent 作为决策支持系统，很快将面临合规审查。企业需要提前布局。
当 Palo Alto Networks 的安全主管说"AI agents are 2026’s biggest insider threat"时，他没有危言耸听。
他描述的是一个结构性变化：企业正在把曾经只属于人类的权限——访问数据、执行操作、做出决策——交给 AI Agent。而我们的安全体系还没有准备好。
这不是说 AI Agent 不可用，而是说：在把钥匙交给 AI Agent 之前，企业需要先回答一个问题——我们对 AI Agent 的信任，是否超过了它应得的信任？
如果答案不确定，从今天开始建立你的 Agent 安全架构。