智能体是不会自我克制的高权限用户
只要 AI 智能体认为某项工具对完成任务有所帮助,它就会去使用您赋予它的每一项工具。这是其优势,也是其风险。一个对生产数据库具有写权限的智能体,如果判定那是达成目标的最佳途径,绝对会去修改生产数据;它不会停下来想:"且慢,也许我应该先和谁确认一下。"
这意味着,您的权限架构必须充当护栏。您不能指望智能体自我设限。如果某件事不该做,它就不应具备做这件事的能力。
把最小权限原则用在智能体上
最小权限并非新原则,但用在智能体身上,意义有所不同。具备生产库访问权限的人类开发者,会判断何时真正去执行查询;智能体则没有这层过滤。因此,智能体的最小权限应比同岗位的人类更为严格。
具体而言:仅需查询数据时,使用只读数据库凭据;为智能体提供作用域受限的 API 令牌,只允许访问其确实需要的端点;文件系统访问限定在特定目录,而非整盘开放。每一项权限都应对应智能体被设计实施的某项具体能力。
分层式权限模型
合理的做法是分层授权。第一层是智能体可访问哪些 MCP 服务器;第二层是这些服务器使用哪些凭据;第三层是后端服务允许这些凭据做什么。每一层都可独立加以限制。
例如,您可让智能体访问数据库 MCP 服务器(第一层),把该服务器配置为以只读数据库用户连接(第二层),而该用户仅对特定表拥有 SELECT 权限(第三层)。即便智能体以某种方式绕过了第一层,第二、三层仍能为您兜底。
环境隔离
生产与开发环境应为智能体使用完全独立的凭据。这听似显而易见,但在快速迭代时极易疏漏。在一次"快速测试"中给智能体配置了生产凭据、之后又忘记还原——这是一种常见且危险的模式。
请为开发与生产分别建立独立的 MCP 配置,清楚标识,并设法让"误用生产凭据运行开发智能体"变得困难。这一事故预防投入,会在第一次成功阻止失误时就回本。
对智能体动作进行审计
有权限而无日志,只构成一半图景。您需要知道智能体究竟用其权限做了什么。请记录每一次工具调用、每一次 API 请求、每一次数据库查询。当问题发生(早晚会发生),正是这些日志帮助您还原经过,并据此收紧权限。