在上一篇，我们试图通过修改 Prompt（提示词）来教大模型"不要听坏人的话"。
但真正的安全专家都知道一条铁律："永远不要信任客户端传来的数据，也永远不要把身家性命押在一段 Prompt 上。"
大模型（LLM）是有概率"发疯"的。如果某天它真的被黑客的"提示注入"洗脑了，决定调用底层的工具去执行 DROP TABLE users;（删库跑路）。
这时候，能挡住它的唯一一道墙，就是工程层面的工具与权限安全。
本篇，我们将抛开那些玄学的 Prompt，教你如何用冷冰冰的代码和架构，把发疯的 AI 死死锁在笼子里。
1. 最小权限原则（Least Privilege）：不要给保洁配金库钥匙
很多新手在开发 Agent 时图省事，配置数据库工具时直接给了 AI 一个拥有最高权限的 root 账号。
这就好比你雇了一个保洁阿姨，却把公司金库的密码和公章全交给了她。
最小权限原则（Least Privilege） 是网络安全的第一法则。它要求：每个 Agent 只能拥有完成当前任务所需的最少权限。
如何落地到 AI 工具上？
- 数据库层 ：如果 Agent 的任务是"查询商品库存"，那么它拿到的数据库账号必须是
Read-Only（只读）。如果它试图执行UPDATE或DELETE，底层数据库会直接报错拦截。 - API 层 ：如果 Agent 需要操作 GitHub，不要给它生成拥有全部权限的 Personal Access Token。只勾选
read:issues权限，让它连提交代码的按钮都摸不到。 - 工具封装层 ：不要直接把
execute_sql(query: string)这种极度危险的通用工具暴露给 AI。把它封装成具体的业务工具，比如get_stock_by_item_id(item_id: string)。这样 AI 就失去了写自由 SQL 的能力。
2. 沙箱（Sandbox）：让 AI 在防弹玻璃房里玩火
当你在做一个"能帮我写 Python 脚本并自动运行分析数据"的 Agent 时，你面临着巨大的风险。
如果 AI 写了一段包含 os.system("rm -rf /")（清空服务器硬盘）的恶意代码，并且你的系统傻乎乎地执行了，你的服务器就完蛋了。
解法：沙箱（Sandbox）隔离。
- 是什么：沙箱就是一个与你的宿主机（真实服务器）完全隔离的"防弹玻璃房"。
- 怎么做 ：不要在服务器裸机上运行 AI 生成的任何代码。必须在一个轻量级的 Docker 容器 或者更安全的微虚拟机（如 Firecracker）里执行。
- 效果：哪怕 AI 在沙箱里把硬盘格式化了、感染了病毒，都没关系。代码运行结束后，你只要把这个 Docker 容器一键销毁，真实服务器毫发无损。
- 额外限制 ：沙箱不仅要隔离硬盘，还要切断外网（防止 AI 把数据偷发给黑客），并限制 CPU 和内存（防止 AI 写个死循环把服务器卡死）。
3. 证据门控与审计（Audit Logging）：事后算账的底气
如果发生了数据泄露，安全部门来查水表："上周五谁把客户名单导出来了？"
如果你答不上来，那这个锅就是你背。
审计日志（Audit Logging） 是洗脱嫌疑的唯一证据。
所有的 Agent 工具，特别是涉及到读取敏感数据（PII）或修改系统状态的工具，在底层代码执行前，必须写一条不可篡改的日志到安全的存储系统中。
一条合格的工具审计日志必须包含：
Who：是哪个用户触发了这个 Agent？When：调用发生的时间戳。What：调用了什么工具？传入了什么参数？Context：为什么调用？（附带当前的Trace_ID，以便回溯完整的对话历史）。
4. 本篇产出：权限分级与审批策略（SOP）
不是所有的工具都需要沙箱，也不是所有的工具都需要人类盯着。
为了在"安全性"和"自动化效率"之间取得平衡，请在内部实施以下这份**《Agent 工具权限分级与审批 SOP》**：
| 风险等级 | 工具示例 | 定义与影响范围 | 授权与拦截策略 (SOP) |
|---|---|---|---|
| L0：极低风险 | get_weather (查天气) calculator (计算器) |
无副作用的只读操作，不接触任何用户数据和公司内部数据。 | 完全放行：无需特殊权限，不记录详细审计日志。 |
| L1：低风险 | query_public_wiki (查公开文档) search_web (网络搜索) |
只读操作，涉及公司公开或半公开数据。 | 静默审计：允许自动执行，但必须在后台记录审计日志 (Who/What/When)。 |
| L2：中风险 | read_user_profile (读取特定用户信息) query_order (查订单) |
只读操作，但涉及用户的 PII（个人隐私数据）或敏感业务数据。 | 身份校验 (Auth)：执行前，底层系统必须校验当前提问的用户 Token，确认他确实有权查询此订单。 |
| L3：高风险 | send_email (发邮件) update_ticket (更新工单状态) |
具有副作用的写操作，会改变系统状态，或对外部产生影响。 | 限流与阻断：严格限制每日调用次数。必须做好"幂等性校验"防止重复操作。 |
| L4：极高风险 | execute_python (执行代码) delete_database (删库) refund_money (退款) |
致命写操作或代码执行，可能导致资金损失或服务器被控。 | 1. 沙箱隔离 ：代码执行必须放入无网沙箱。 2. 人类在环 (HITL) ：任何退款/删除操作，系统必须挂起 Agent，通过飞书/钉钉发消息给对应主管，人类点击【同意】后才允许放行。 |
总结与复盘
- Prompt 是防君子的，架构是防小人的。
- 最小权限原则 让发疯的 AI 成了被拔掉牙齿的老虎，虽然叫得凶但咬不死人。
- 沙箱隔离 让你敢于放心大胆地执行 AI 生成的未知代码。
- 审计日志 是你给安全部门交差的保命符。
- 只有严格落实了工具的权限分级（L0 - L4） ，并在高危节点引入 人类审批（Human-in-the-loop），你的 Agent 才能真正安全地走向生产环境。
下一步路线提示 ：
工具的安全底线我们守住了，但还有一个比工具更脆弱、也更值钱的东西------数据 。
如果用户在聊天框里发了一句："帮我算算这几个人的工资：张三 5000，李四 8000。"
这段包含着敏感隐私的话，被原封不动地发给了国外的 OpenAI 服务器，你们公司的合规部门会立刻把你的系统封杀。
下一篇，我们将探讨企业数据安全的底线：《数据安全：PII、密钥、合规与脱敏》。