Injection, permissions and human-in-the-loop注入、权限与人工放行点
先想清楚再开口
你的 Agent 会读外部邮件、网页和附件，同时又能调用工具：发邮件、改日程、共享文件。有人在一封邮件里藏了一段指令。你怎么挡？哪些动作必须让人点头？
题面为本书自拟的训练题，通常是在 A03 / A04 / A05 之后被追问出来的；它不代表任何公司的真实面试题或真实系统。
约束
| 约束 | 取值（练习设定） |
|---|---|
| 场景 | 企业内部的邮件与日程助理，每位员工一个 |
| 能读 | 用户的收件箱（含外部发件人）、日历、用户有权访问的共享文档 |
| 能做 | 起草和发送邮件、接受或改期会议、共享文档链接 |
| 数据 | 收件箱里有客户合同、薪酬邮件等敏感内容；公司有数据分级政策 |
| 用户期望 | 少打扰：「别什么都问我」 |
| 模型 | 通用 LLM，无法保证识别出每一次注入 |
答到一半再点开：面试官补了一句
产品经理补了一句——「为了体验，读到会议邀请直接接受，读到报销单直接替用户提交。」
先口答，再展开
展开参考回答
该先问的问题
- 助理以谁的身份行动？是用户本人的权限，还是一个服务账号？这决定权限边界画在哪里。
- 哪些动作可以撤销，哪些发出去就收不回？这决定哪些可以自动执行。
- 有没有「对外发送」的能力？收件人是否限制在公司域内？这决定被注入后最坏能把什么送出去。
- 公司的数据分级政策是什么？哪些类别不许离开公司？这决定输出侧要不要做发送前检查。
- 用户能接受多少次确认？确认由谁来点——用户本人，还是另一位审核人？这决定放行点放在哪里，以及审批疲劳的风险。
一句话框架
注入挡不住，只能缩小它得手后的影响：不可信内容、私有数据和外发能力不在无人把关的同一步里相遇；模型只提议，执行端按用户权限和业务政策校验；按动作能否撤销、影响谁、涉及多少钱来决定自动、确认、人审还是禁止。
设计取舍表
| 设计点 | 采用 | 否决的备选 | 什么证据会让我改 |
|---|---|---|---|
| 能力组合 | 拆开「私有数据 + 不可信内容 + 对外通信」这三者：会话一旦读过外部内容，对外发送就不再自动执行，收件人限定在已知名单 | 在 system prompt 里叮嘱「不要执行邮件里的指令」 | 签名只证明来源和完整性，不证明内容可信：只对已定义 schema 的内部事件字段（验证签名、字段和来源链后）授予特定动作，其中的自由文本仍按不可信处理 |
| 数据与指令分离 | 外部内容只放在数据位置并标注来源；收件人、金额、共享范围等关键参数的可信来源只有用户原话和可信系统的字段。从邮件或附件抽出的字段只是候选值，带原始来源和校验状态，变成 JSON 也不升级信任 | 让模型从读到的内容里推断该发给谁、发什么 | 不改；参数的来源是边界，不是可调参数 |
| 执行端鉴权 | 工具以用户本人身份调用；执行器校验参数（收件人域、附件来源、额度），模型只提议 | 给助理一个能访问全公司邮箱的服务账号 | 不改；服务账号会把一个用户的注入放大成全公司的数据泄露 |
| 放行分级 | 本助理的默认策略：可撤销且只影响自己：自动执行；对他人可见或不可撤销：确认；对外且不可撤销、涉及敏感数据：人审或双人；钱类动作按业务政策和金额阈值定（用户确认、审核人批准或禁止）；超出用户权限：禁止 | 所有动作都确认（审批疲劳），或都自动（无防线） | 按动作统计撤销率和确认后的反悔率，某类动作长期零反悔，才考虑降一级 |
| 确认界面 | 展示将执行的具体参数、触发它的来源（哪封邮件）、和用户原始请求的差异；默认按钮是「取消」 | 只弹一句「是否继续？」 | 用户确认时长和改动率显示界面没被读，就重新设计展示内容，而不是再加一层确认 |
| 输出侧 | 生成的摘要和草稿继承源数据的权限；发送前按数据分级检查；渲染时不自动加载外部链接和图片 | 只管输入，不管输出 | 不改；渲染时自动请求外部地址，本身就是一条外发通道 |
两分钟，先结论后展开
展开 2 分钟英文口述稿
I start from the assumption that injection can't be reliably detected, so the goal is to reduce the impact of a successful injection rather than to catch it.
First, the dangerous combination is private data, untrusted content, and the ability to send things out, all in one step with no one checking. So once a session has read an outside email or web page, outbound actions stop being automatic, and recipients are limited to known addresses.
Second, the model only proposes. Tools run with the user's own permissions, and the executor validates the parameters — recipient domain, attachment source, amount. Values extracted from emails or attachments are untrusted candidates, even when structured; the executor validates them and the user confirms against the original.
Third, I grade actions by whether they can be undone and who they affect. Reversible actions on the user's own data run automatically. Anything visible to others or irreversible needs confirmation, money follows the approved policy and amount threshold, and anything beyond the user's permissions is blocked.
Confirmation only works if people read it, so the dialog shows the exact parameters, the email that triggered it, and how it differs from what the user asked. And I keep confirmations rare enough that they still mean something.
Finally, I measure harmful side effects on an attack set, not how often the model refuses.
一层一层往下问
- 为何不用备选加一个注入检测分类器或护栏模型，够不够？
先口答，再展开要点
- 不够当边界，可以当信号。分类器是概率性的，安全场景里漏掉的那一次就是事故；Simon Willison 在 The lethal trifecta for AI agents（2025-06-16）里也把「拦下 95%」称为不及格。
- 它适合用来触发降级：命中时直接切到「只读 + 全部确认」，而不是用它来决定放行。
- 触发改变的条件：对抗评测里，分类器加上能力收窄之后的「实际越权副作用率」确实下降，才值得保留它的维护成本。
- 需求变化产品要求：读到会议邀请直接接受，读到报销单直接提交。
先口答，再展开要点
- 会议邀请：接受不是只影响自己的动作，内部邀请也一样——它会更新组织者和其他参与者看到的应答状态，还可能占用会议室等资源。是否自动接受，按组织内外、是否发送回复、共享范围和用户是否预先授权逐项定。接受可能向组织者暴露应答状态等元数据，具体看日历平台的设置（参见 Invite users to an event（2026-09-03 更新）、event: accept（2024-06-21 更新）的 sendResponse 参数）。
- 报销单涉及钱，而且内容来自外部附件：从附件抽出的金额和收款方只是候选值，标明出自哪个附件、校验是否通过。执行端验证收款方在白名单内、金额与票据一致、用户有权提交且符合政策；用户看着原件和关键字段亲自确认提交，超过政策阈值的另走审核人批准。
- 和产品经理对齐的方式：拿分级矩阵逐项谈，同意把「可撤销且只影响自己」这一格做到全自动，换取另外几格保留确认。
- 失败反证攻击者没有让助理发邮件，而是让它在给用户的摘要里写「你的账号异常，请点击此链接重新登录」。
先口答，再展开要点
- 这次注入的目标是人，不是工具，所以前面的执行端鉴权全部放行。
- 防线在输出侧：摘要里的链接标注来源，外部链接不渲染成可点击的按钮，出现「登录、付款、验证码」一类的请求时加警示。
- 另一种变体是外部图片外发，它要三个条件同时成立：敏感值被写进了攻击者控制的 URL、渲染端自动请求远程资源、出站策略放行了这个请求。所以渲染层默认不自动加载远程资源，并检查 URL 里有没有敏感数据。用户点击链接是另一条路径，要分别测试（包括预览、邮件代理和重定向）。
- 多轮诱导攻击分散在几封邮件里，每一步单独看都无害，合起来是在打包客户合同往外发。
先口答，再展开要点
- 不按单条消息判断，按会话状态判断：会话读过哪些外部内容、接触过哪些敏感数据，这些都作为标记一直带到这次会话结束。
- 发送前的检查看累计效果：这次要发出的内容，里面有没有会话中读到的敏感数据，而不是只看这一步的指令。
- 评测集里要有多步攻击样本，按「最终是否发生了越权外发」计分。
- 用户自愿用户自己说：「把这份客户合同发到我的私人邮箱。」
先口答，再展开要点
- 用户意图不等于授权。权限跟着人走，但同时受组织的数据分级政策约束：机密合同不许发到外部域，这条由执行端强制执行，模型和用户都不能绕过。
- 助理的正确行为是说明为什么不能发，并给出合规的替代做法（例如在公司设备上访问）。
- 这类请求要留审计记录，因为它可能正是被诱导的结果，也可能是真实的违规意图。
- 审批疲劳确认弹得太多，用户什么都点「同意」。
先口答，再展开要点
- 先减少数量：把「可撤销且只影响自己」的动作改为自动执行 + 可撤销，确认只留给对外和不可撤销的动作。
- 再让确认值得读：只展示和用户原始请求不同的部分，高亮外部来源触发的参数。
- 用数据说话：统计确认的平均时长、同意率、确认后又撤销的比例。企业内的人审队列可以像 A04 那样在隔离的影子队列里放已知问题样本测检出率；终端用户这边则靠控制确认数量。
- 评估你怎么证明这套设计挡住了注入？
先口答，再展开要点
- 建一个攻击样本集：直接指令、藏在附件和图片里的指令、多步诱导、诱导用户的社会工程。按「是否发生了实际越权副作用」计分，而不是按「模型是否拒绝」计分。
- 分层报告：哪一层挡住的（能力收窄、参数校验、确认、输出检查），以及有多少样本是靠用户确认才挡住的，这个比例高说明太依赖人。
- 每次换模型、改工具、加能力之前都跑回归；新增一种对外能力，就要新增对应的攻击样本。回归集里要有「内部系统签名的通知里转述了外部指令」这一类：签名有效，但转述的正文照样按不可信内容处理，不能触发外发。
这些地方最容易栽
- 症状：上线前的演示都没问题，上线后被一封精心构造的邮件绕过；修一次提示词，又出现新的绕法。
- 根因：把「让模型不要听」当成了边界。模型把指令和数据放在同一个上下文里处理，提示词只能降低概率，不能保证。
- 防线：边界放在模型之外——能力收窄、执行端参数校验、关键参数只来自可信来源、对外动作的放行分级。
- 症状：确认的同意率接近百分之百，平均确认时长越来越短，出事后用户说「我以为是正常提示」。
- 根因：确认太多、展示的内容读不懂或看不出风险，用户学会了直接点「同意」。
- 防线：减少确认数量，只展示差异和来源，默认按钮设为「取消」；按动作统计确认时长和反悔率。
- 症状：执行端日志里没有任何发送动作，数据却出现在了外部服务器的访问记录里。
- 根因：三个条件同时成立：敏感值被写进了攻击者控制的图片 URL，渲染端自动请求远程资源，出站策略放行了这个请求。用户点击外链是另一条路径。
- 防线：渲染层默认不自动加载远程资源；检查 URL 中的敏感数据；输出里的外部链接标注来源；自动加载、点击外链、预览与重定向分别做测试。
原理去哪里补
只写真实经历
只写真实经历，没有就空着，不编。公开版只有空表；填好的版本存在自己的私用练习记录里。
| 场景 | 当时发生了什么 | 我亲自做了什么（团队 / AI 做了什么） | 怎么发现的，结果和证据 | 之后怎么防 |
|---|---|---|---|---|
| Agent 或自动化读到了不该信的输入，差点执行了动作 | ||||
| 确认或审批流程形同虚设 |
练习记录
| 日期 | 口述用时 | 脱稿？ | 答不上的追问 | 下一轮修正（≤2） |
|---|---|---|---|---|