AI Agent 安全：教程里不会教的防护层

每一个 Agent 教程的结局都一样。你接好模型，给它几个工具，看它查个数据库或约个会议，感觉就像魔法。然后你把它上线了。这些教程几乎从不提及的是，从安全角度看你刚刚做了什么：你把凭证交给了一个自治进程，并把它指向了生产环境。

我想聊聊这个差距，因为这是把一个漂亮 Demo 变成线上事故的转折点。

Agent 是一个新的身份，所以要像对待身份一样对待它

当你构建一个 Agent 时，你实际上不是在添加一个功能，而是在添加一个用户。一个只认证一次、从不睡觉、模型决定什么就做什么的用户。如果你把自己的 Token 交给它来"让它跑起来"，它所做的每一项操作在日志里都和你无法区分，你所有的访问权限都在它背后撑着。

从第一天起就给每个 Agent 它自己的身份。它自己的服务账号、它自己作用域受限的 Token、它在审计日志里自己的名字。当凌晨两点出问题的时候，你希望日志说的是"是 invoice-agent 干的"，并准确显示它能触达什么，而不是让你眯着眼睛看一行像是你自己干的记录。

给工具划分作用域，而不只是给 Prompt 划分

危险的权限在你给 Agent 的工具里，不在你的 System Prompt 的措辞里。一个只有单表只读数据库权限的工具的模型，和持有任意 SQL 执行权限的工具的模型，是完全不同的风险。同一个 Agent，爆炸半径天差地别。

所以在连接一个工具之前，先问问对它的最坏调用是什么样的。如果你的发邮件工具可以发给任何人，一个被迷惑或被操控的 Agent 就能把你的整个客户列表发个遍。如果你的数据库工具可以删表，一次糟糕的决策就是灾难性的，而不是令人烦恼的。给每个工具赋予工作所需的最小能力。默认只读。只操作一个资源，而不是整个账号。

一个数字让这变得具体：IBM 2025 年泄露报告发现，97% 遭受 AI 相关泄露的组织都缺乏proper的 AI 访问控制。失败模式几乎总是过度授权访问，而不是天才攻击者。

假设模型会被说服做某事

这是开发者最低估的一点。你的 Agent 读取外部内容：一个网页、一封邮件、一个工单、一条用户消息。任何控制这些内容的人都可以把指令埋在里面，而模型无法可靠地把你的指令和藏在它正在处理的数据里的指令区分开。这就是 Prompt Injection，自从 LLM 风险列表存在以来，它就一直排在 OWASP 列表的首位。

你无法完全阻止它，所以要按它一定会发生来构建。救命的规则：永远不要让同一个 Agent 既摄取不可信输入，又持有强大的、不可逆的能力。如果一个 Agent 读取任意网页，它就不应该还能转账或删除记录。把这些拆分成具有独立访问权限的不同 Agent，这样那个负责读取的被劫持了也够不到能造成损害的工具。

在单向门前放一个人

自治对于可逆操作是没问题的。让 Agent 起草、排序、总结、查询、重试，一整天都行。对于那些无法撤消的事情——发送、付款、删除、发布、部署——加上一个人工审批步骤。是的，这样就没那么神奇了。但这也是 Agent 犯个错和 Agent 犯了个你无法挽回的错之间的全部区别。

一个便宜但有效的模式：Agent 提议那个不可逆操作，一个人在 Slack 或一个小仪表盘里批准它，然后它才执行。你保留了几乎所有的速度，同时把负面影响限了顶。

如果你在构建 Agent，大部分安全工作和 AI 无关，也毫不光鲜。给 Agent 它自己的身份。把每个工具的作用域限制到最小。让不可信输入的 Agent 远离你的危险能力。把不可逆操作放在人工后面审批。做好这四件事，你就覆盖了生产环境中真正出问题的大部分情况。

Demo 是最简单的那部分。访问模型才是产品。