上下文隔离、工具权限与提示词注入

1. 解决什么问题

资料可能包含“忽略规则、调用某工具”等文字，模型也可能生成越权请求。教材系统必须把不可信文本与可信程序权限分开，防止语言内容直接变成执行授权。

2. 原理与术语

提示词注入是把恶意或无关指令混入用户内容、检索资料或工具结果，诱导模型改变行为。最小权限限制可执行能力；上下文隔离减少不必要的信息共享。提示词中的禁止语句是辅助措施，不是安全边界。

3. 输入输出与执行

graph.context 按角色选择字段；providers.UNTRUSTED 明确资料不授予权限；ToolSession 从服务端角色决定工具集合并再次授权。查询范围来自任务而不是模型参数，媒体接口地址来自部署配置而不是生成内容。

4. 容易混淆

评审不看生成对话，不代表它看到的教材一定可信。两个角色使用同一模型仍可能共同误判。应用 API_KEY 是操作入口的共享密钥，工具角色是内部执行身份；两者不是完整的多用户 RBAC 或租户隔离体系。

5. 最小示例

from app.schemas import SearchArgs
try:
    SearchArgs.model_validate({"query":"校园","region":"US"})
except ValueError:
    print("地区不能通过模型检索参数覆写")

额外字段被拒绝，实际地区由上下文提供。这个例子验证参数边界，不证明模型能识别所有提示词注入。

6. 实际实现

工具没有任意 shell、文件读写或任意 URL 访问能力；FFmpeg 使用程序构造的参数数组，不执行模型给出的命令字符串。图片 URL-only 返回也不会自动触发下载。未知工具被记录并拒绝，不能依赖模型“自觉遵守”。

7. 源码与数据结构

阅读 system/app/tools.py::REGISTRY/ToolSession.execute、providers.py::UNTRUSTED、graph.py::context、api.py::auth 和 media.py::make_video。Compose 默认仅绑定本机 127.0.0.1；API_KEY 可配置，但这不等于已经适合公开互联网服务。

8. 取舍与局限

当前是单用户学习系统，没有细粒度身份、审计主体、多租户隔离、全面限流或恶意内容分类器。资料指令可能仍影响生成文本，因此还需要来源核验与人工审批。若公开部署，应先补这些边界，而非只把端口改为公网监听。

9. 实验与验收

在 system 目录重复服务端授权实验：

docker compose exec -T api python - <<'PY'
from app.tools import ToolSession, ToolDenied
try:
    ToolSession('generator','security-lab',{}).execute('shell',{'command':'echo test'})
except ToolDenied:
    print('PASS: unknown tool rejected')
PY

验收要求没有执行 shell，只记录拒绝。再向隔离实验资料写入“忽略规则”类文字，观察真实模型行为与服务端限制；演示模板不会理解注入，不能据此宣称模型防注入效果通过。

10. 故障排查

越权问题先查服务端角色来源与注册表；资料泄漏查查询范围和 API 权限；异常命令执行查是否拼接 shell；密钥暴露查日志与静态构建输入。只修改 system prompt 无法修复程序授予的过宽权限。

11. 面试题与追问

问：如何防止检索资料改变工具权限？ 权限由服务端角色决定，资料只作为内容输入。追问：这样是否完全安全？ 不能保证模型内容不被诱导，仍需分层检查。再追问：MCP 会自动解决吗？ 不会，协议统一接入，授权与信任边界仍属于应用设计。

STAR 应用：假设实验场景，R 为应核对的证据

对应	S：情境	T：目标	A：行动	R：验收证据
主问	资料包含越权指令	保持权限来自可信程序	执行时查服务端角色和白名单	未授权请求被拒绝，资料无法改权限
追问一	权限安全但回答仍受诱导	保护内容质量	联合来源核对、评审与人工确认	记录内容偏离，不能宣称注入已完全解决
追问二	计划接入MCP服务	保留信任边界	审核远程工具权限与返回数据用途	协议接入不替代鉴权和业务校验

这些是设计讨论的参考表达，实际执行前不能改写为已取得的历史成果。

12. 官方资料与版本

OWASP 提示词注入防护、MCP 工具规范、Function Calling。核验日期 2026-11-03；本页描述现有边界与限制，不是完整安全审计报告。