给 AI Agent 配权限：把它当实习生，不要当 root

Agent 像一位速度极快、记忆力很好、偶尔会误解任务的实习生。最糟糕的管理方式，是第一天就把机房总钥匙交给它。

AI 从回答问题走向执行任务后，安全边界不再只由模型能力决定，而由工具目录、账号权限、网络范围和确认策略共同决定。模型越能规划，权限设计越重要。一个优秀模型拿到过宽权限，造成的后果可能比一个普通模型更大，因为它更擅长把多步动作串起来。

OWASP 将 excessive agency 概括为过多功能、过多权限或过多自主性。MCP 则让工具接入更标准，也让“连接一个服务器就获得一组能力”变得容易。标准化不自动等于安全，关键在于每个工具如何授权和隔离。

从能力清单开始，而不是从 Agent 名称开始

不要只写“运维 Agent”或“内容 Agent”，而要列出它能读取哪些路径、调用哪些命令、访问哪些域名、使用哪个身份、是否能修改或删除。两个名称相同的 Agent，如果一个只能读取日志、另一个挂载 Docker socket，它们的风险完全不同。

工具接口应尽量窄。与其提供 run_shell(command)，不如提供 get_container_status()、read_recent_logs(service) 和 restart_service(approved_name)。窄接口更容易验证参数、记录审计和设置确认。通用 shell 可以保留在人工接管层，而不是默认工具箱。

只读不是标签，而是可验证属性

工具描述写着 read-only 并不能阻止实现偷偷写缓存、触发远程调用或读取后产生外发。只读应由操作系统权限、文件挂载模式和 API scope 共同保证。对于数据库，使用只读账号；对于文件，挂载只读目录；对于云 API，签发只读 Token。

读操作也可能敏感。读取 .env、SSH 私钥或完整客户数据库虽然没有修改状态，却能造成严重泄露。因此权限模型要同时考虑完整性和机密性，不能把所有 GET 请求都划为低风险。

MCP 的传输和授权边界

本地 MCP server 使用 stdio 时，攻击面通常限制在启动它的客户端和本机权限；一旦改成 HTTP，就需要认证、TLS、精确 redirect URI、短期 Token 和服务端 scope 校验。MCP 官方安全实践特别警告 confused deputy、session hijacking 和过宽 scope。

不要把 session ID 当认证。每个请求都应验证真正的访问 Token 及受众，session 只用来关联状态。远程 MCP server 不应因为请求来自内网就默认可信；内部网络也可能存在被攻破的浏览器、容器和开发机。

沙箱、网络和临时凭据

执行代码的 Agent 应在短生命周期沙箱中运行，默认没有宿主机家目录、Docker socket 和长期云密钥。把输入文件复制进任务目录，只把明确输出带回。网络默认关闭或按域名开启，比允许整个互联网后依赖模型克制更可控。

凭据尽量按任务签发并短期有效。Agent 完成发布后，发布 Token 随任务失效；备份检查只拿读取快照清单的权限。长期静态 Key 会让一次上下文泄露变成长期后门。

审批与审计要面向动作

把操作分成自动只读、可逆写入、高影响写入三层。查询状态和生成草稿可自动；修改单个可回滚配置需要展示 diff；删除、授权、公开发布、重启核心服务和更改防火墙需要明确批准。审批记录应包含工具、参数、目标身份和结果。

Agent 日志不能只保存最终回答。真正有用的是工具调用链、输入来源、权限提升和外部请求。审计数据也要脱敏，尤其不能把 Token 和完整私人文档原样写入。

可以直接照着做的检查清单

• 为每个 Agent 写出文件、命令、网络、身份和删除能力清单。
• 用窄工具替代通用 shell，并在服务端验证参数允许列表。
• 通过 OS、挂载和 API scope 真正实现只读，不只写提示。
• 远程 MCP 使用 TLS、短期 Token、精确 redirect URI 和最小 scope。
• 代码执行放入短生命周期沙箱，默认无宿主机秘密和公网。
• 按动作风险设置审批，并保存脱敏后的完整工具调用链。

延伸阅读

• MCP Security Best Practices
• MCP Authorization Guidance
• OWASP LLM06:2025 Excessive Agency
• NIST AI RMF Generative AI Profile

Agent 安全不是让模型永远判断正确，而是让一次错误判断最多影响一小块、持续一小会儿，并且能被看见和撤销。