给 AI Agent 增加工具权限时如何避免安全崩盘

最近在公司内部推动 AI Agent 落地，团队在工具链集成阶段踩了不少坑。很多开发者在给 Agent 接入能力时，习惯性地把关注点放在“它能干什么”上，却极易忽略“它不该碰什么”。其实，给 Agent 多配置一个工具，就意味着多增加了一分潜在的攻击面或误操作风险。

最核心的一个认知误区是：很多人把提示词（Prompt）当成了安全边界。在实际工程中，跟模型说“你没有网络访问权限”或“禁止删除根目录文件”，这在技术上完全不等于真正摘掉了网络权限或限制了文件系统操作。提示词只是引导模型生成某种行为，而真正的安全边界必须建立在操作系统、容器或 API 鉴权层。

这里分享一个典型的反面案例，来自 Anthropic 七月底发布的一份安全评估报告。当时他们在模拟环境下让三个 Claude 模型运行网络安全练习题，结果因为评估配置出现了 Bug，导致模拟环境实际上与外部网络相连。模型在执行任务时，虽然它“认为”自己处于隔离的模拟环境中，但实际上却向真实的 PyPI 仓库发送了一个恶意的 Python 包。这个案例深刻揭示了：当提示词约束与实际环境配置发生冲突时，模型会基于其执行逻辑直接操作环境，而不会因为一条 Prompt 就停止潜在的破坏行为。

基于这些教训，我们在落地内部助手时总结了一套权限治理方案，核心逻辑就是“默认最小权限”。

首先，权限必须严格按任务需求分配，绝对禁止给全量权限。很多团队为了图省事，直接给 Agent 一个具有读写权限的服务器账号。但在我们的实践中，如果 Agent 只需要读取代码库进行分析，我们只给它扫描仓库目录的 Read-only 权限，绝不给整个服务器的读写权限。如果需要执行命令，我们会通过一个中间层对 ls、cat 等基础命令进行白名单过滤，而不是直接把一个完整的 Shell 丢给模型。

其次，必须预设失败场景。不要假设你的环境配置是万无一失的，更不要假设提示词能起到约束作用。在设计架构时，我们要假设最坏情况——比如配置 Bug 导致网络突然打通，或者模型通过 Prompt Injection 绕过了指令。因此，在 Agent 调用的 API 层面，必须再次校验权限凭证，确保即使模型“想”做某件事，如果凭证不匹配，底层系统依然能将其拦截。

此外，可审计性是 Agent 治理的底线。Agent 能够执行操作，就必须保证每一个操作都留痕。我们为 Agent 增加了一套详细的日志审计系统，记录每一次工具调用的输入、输出以及执行时间戳。这不是因为不信任模型，而是因为一旦出现非预期结果（例如误删了某个配置文件），如果没有完整的调用链路审计，排查问题的成本将高到不可接受。

最后，单层防护在 AI 时代绝对不够。权限限制、环境隔离、监控告警，这三者必须形成多层防御体系。之前我们尝试只靠提示词约束，结果发现那就像一张纸，在面对复杂任务时极易被击穿。

总结来看，AI Agent 的失控本质上还是工程问题。模型只是整个系统中的一个组件，工具、凭证、环境、监控才是决定系统稳定性的关键。在 AI 时代，那些传统的工程原则——权限最小化、失败假设、多层防护——反而变得比以往任何时候都更值钱。