AI Agent 也会被社交工程？看懂提示词注入与工具权限风险

让 AI 帮你读 GitHub Issue、摘要网页，本是日常操作。但如果 Issue 里藏了一句恶意指令，AI 可能转头去读取你的私人仓库，甚至把薪资信息写进公开 PR——而你从头到尾没让它这么做。这不是科幻，而是安全研究团队已经公开演示过的攻击。

当 AI 不只是「回答」，还能「动手」

传统聊天机器人只输出文字，风险停留在「说错话」。如今的 Coding Agent 和 AI 浏览器接入了工具，能读文件、发请求、操作已登录的网站。能力边界一扩大，攻击面也随之扩大。

据 YouTube 频道对 Invariant Lab 与 Brave 两项研究的解读，攻击者不需要偷密码，也不需要篡改 MCP Server 代码，只需控制 AI 接下来会读到的内容，就能诱导它用自己原本合法的权限去做不该做的事。这类攻击被称为 Prompt Injection（提示词注入）。

Prompt Injection（提示词注入）与传统的 SQL 注入、命令注入在原理上同构：系统把「数据」和「指令」放在同一条输入通道里处理，攻击者只需在数据中伪造指令语法，就能让解析方混淆两者边界。LLM 的特殊之处在于，它的输入天然是自然语言，模型无法像编译器那样严格区分「这是待处理的内容」和「这是要我执行的命令」。常见变体包括：直接注入（用户在对话中直接输入越权指令）、间接注入（恶意指令藏在网页、文档、Issue、邮件等模型后续会读取的内容里），以及越狱（jailbreak，诱导模型绕过自身安全策略）。本文两个案例都属于间接注入——攻击者从未与目标 AI 直接对话，只是污染了它会读到的资料。这也解释了为何单纯在系统提示里写「忽略不可信内容」收效有限：模型仍需逐字阅读不可信文本才能判断其是否可信。

两个真实研究案例：一张 Issue 与一次摘要

案例一：GitHub Issue 里的隐形指令

Invariant Lab 在公开仓库中创建了一张带有恶意指令的 Issue（GitHub 上用于回报问题的区域）。仓库拥有者只是请 AI 查看公开项目有哪些待处理问题，AI 读到该 Issue 后开始访问私人仓库，并把部分私人信息写进公开的 Pull Request。研究展示的外泄内容涉及私人项目信息、搬迁计划和薪资相关数据。

关键点在于：用户没有要求公开任何东西，攻击者也没有拿到 GitHub 密码。攻击利用的是 GitHub 官方 MCP Server 的正常连接——AI 能看什么、改什么，取决于连接时授予的工具与权限。

案例二：AI 浏览器从网页摘要跳到 Gmail

Brave 安全团队演示了 Comet AI 浏览器的攻击链：研究人员在 Reddit 评论中藏入恶意指令，用户仅要求「摘要当前网页」，AI 读取评论时一并读到了指令，随后被诱导查看账户信息、获取邮箱地址、触发一次性验证码（OTP），再前往已登录的 Gmail 读取验证码，最终通过 Reddit 回复将信息带出。

这个案例的要害不是 Reddit 或 Gmail 被攻破，而是 AI 浏览器能代表用户操作多个已登录站点。当它把网页内容误当成操作指令，合法的浏览器权限就成了攻击者的跳板。Brave 公开了漏洞通报与修补时间线，最终测试显示问题已被修复——这说的是当时演示的漏洞，不能推断现在的 Comet 仍存在同样问题。

MCP：能力接口，也是权限入口

MCP（Model Context Protocol）常被比作 AI 的 USB 接口，让 AI 通过统一标准连接 GitHub、信箱、数据库等外部工具。但「接得上」只代表能通信，不代表该被允许做任何事。权限配置才是真正的安全边界。

MCP 采用客户端—服务器架构：AI 应用作为 Host，为每个外部系统建立独立的 MCP Client 连接，由 MCP Server 把 GitHub、数据库等能力封装成标准化工具暴露给模型。连接建立时通常会声明能力范围（capabilities）与作用域（scope），例如 GitHub MCP Server 的 token 拥有哪些仓库的读写权限。安全设计的关键在于：模型只能调用 Server 已注册的工具，而工具实际能做什么由后端凭据和策略决定。因此「模型想读私人仓库」与「模型能读到私人仓库」是两回事，后者取决于 token scope、工具白名单与服务端鉴权。把权限收窄到任务所需的最小集合（如只读、只针对特定仓库），即使模型被注入说服，也会在工具调用层被拒绝——这正是本文所说的第二层防线。

注入为什么有时成功，有时失败

恶意指令出现在文件里，不等于攻击成功。判断要看两层：AI 是否接受了外部指令，以及工具端是否真的执行了操作。

• 第一层挡住：AI 识别出那只是文档中的一段文字，继续完成摘要，没有读取私人档案，行为未被改变。
• 第二层挡住：AI 受到影响并请求读取私人档案，但工具端检查后发现该 Agent 没有权限，直接拒绝。
• 两层都失守：AI 接受指令且恰好拥有对应权限，GitHub MCP 研究展示的正是这一种。

这套分层判断很实用：攻击失败时要分清失败在哪一层。是模型没上当，还是权限拦住了？结果看起来都是「没出事」，但防护机制完全不同，不能一概归功于模型本身安全。

RAG 与 Agentic SOC：同一个问题的不同面孔

RAG（检索增强生成）让 AI 先检索资料再回答。如果知识库混入针对 AI 设计的恶意指令，检索环节就成了注入入口。

Agentic SOC 面临同样的结构性问题：日志、EDR 事件、邮件附件、HTTP User-Agent 中可能含有攻击者可控的文字。如果 AI 只负责整理告警，主要风险是分析被误导；如果它还具备封锁 IP、停用账号、隔离主机的能力，风险等级立刻上升。

Coding Agent、RAG、Agentic SOC 的共同点是：AI 必须读取资料才能工作，但读取资料不等于接受资料里的指令。OWASP 在 LLM 风险清单中将提示词注入列为 LLM01，说明这仍是 Agent 安全的核心议题。

OWASP Top 10 for LLM Applications 是面向大模型应用的行业风险清单，2023 年首版将 Prompt Injection 列为 LLM01（最主要风险），2025 版仍将其置于首位，并细分为直接注入与间接注入。与之并列的风险还包括不安全的输出处理、敏感信息泄露、过度代理权限（Excessive Agency）等，其中「过度代理」恰对应本文强调的工具权限问题：模型被赋予过多自主决策与执行能力，却没有相应的人类监督与约束。该清单的价值在于把风险从「模型会不会说错话」重新框定为「系统在架构层面是否留了刹车」，与本文主张的「从盯回答转向盯行为能力」一致。开发者可据此逐项自查 Agent 的输入通道、工具暴露面与审计能力。

三层防护：从「求模型听话」到「用系统兜底」

只靠一句「忽略不可信内容」远远不够——那句话本身仍要交给模型理解与遵守。实际部署至少要落地三件事。

最小权限：少给一点，安全很多

只处理公开 GitHub 项目，就不要顺手开放所有私人仓库；只摘要一份文件，就不要让它任意访问敏感目录。

最小权限原则（Principle of Least Privilege）源自操作系统与访问控制领域，要求主体仅持有完成当前任务所必需的最小权限，且时限尽可能短。落到 AI Agent 上，通常体现为几种工程手段：按任务签发短期、窄范围的凭据（如只读 token、限定单仓库）；对工具做分级，把「读取」与「写入/外发」拆成不同权限档位；对高风险动作引入人工确认（human-in-the-loop）；用沙箱隔离文件系统与网络访问。与之配套的是「权限提升」应当显式发生——Agent 若需临时扩大权限，应触发一次明确的授权事件并留痕，而不是默认继承用户全部身份。这让攻击者即便成功注入，也只能在受限的工具面上行动。

工具层校验：高风险动作必须拦截

分析类 Agent 未必需要改文件、发邮件或执行 shell 指令。读取私人仓库前，系统应确认本次任务是否授权，而不是模型说「我需要」就放行；外传敏感数据、修改权限等操作应要求用户明确核准。

完整审计：回答不等于行为

AI 说「任务完成、未修改其他文件」，并不等于它真的没动过。要确认它调用过哪些工具、执行了哪些指令、产生了哪些非预期变更。对 Agentic SOC 而言，还需对照告警记录、工具执行结果与系统实际状态。

记住三个检查方向：资料从哪里来、Agent 有哪些权限、它最后实际做了什么。这比问 AI「你有没有遵守规则」可靠得多。

观念转变：别只盯回答，要盯行为能力

两个研究案例的共同模式清晰可见：AI 原本在执行合法任务，接触到的外部资料试图改变它的工作方向，而它恰好握有足够的工具权限，让不该发生的要求变成了实际操作。

如果你正在开发自己的 AI Agent，或准备把 MCP 接入企业内部系统，先检查三件事：资料来源、工具权限、操作记录。安全的重心，正在从「模型说了什么」转向「Agent 能做什么」。