过去两年，企业评估合肥智能体开发公司时，问题几乎都集中在"效果好不好"：能不能准确回答、能不能自动完成流程。但从 2025 年下半年开始，一个更难回答的问题被反复提起：如果这个智能体做错了事，或者被外部内容"带偏"了，损失会有多大？

区别在于能力边界。当大模型只能输出文本时，最坏的结果是一段错误回答；当它获得了调用接口、读写文件、发起支付、代发邮件的能力，风险就从"说错了"变成"做错了"。这篇内容把智能体的安全边界与权限管控拆成可核对的清单，供企业在选型与验收时对照。

一、风险为什么会迁移

OWASP 已把"过度代理"列为大模型十大风险之一——当智能体拥有的权限超过其任务所需，事故的半径就会被放大到权限所及的全部范围。目前被认为最典型的四类威胁是：

其中有一个容易被忽略的细节：智能体读到的工具说明，和人看到的界面标签不是一回事。智能体会读取工具完整的结构化描述字段，而使用者只看到一个简化标签。攻击者可以把恶意指令藏在描述字段深处，做成俗称"工具投毒"的手法。有安全研究显示，这类攻击对主流智能体的成功率可达七成以上。也就是说，智能体的安全边界不能建立在"它应该听话"这个假设上。

这类风险的结构性特征值得单独强调：传统漏洞可以靠打补丁消除，而提示注入利用的是系统逻辑本身——攻击者不需要攻破防火墙，也不需要窃取口令，只需要让一段"不该被当成指令"的内容进入智能体的判断链路。这也是为什么业界把它列为增长最快的企业攻击面之一。防护思路因此也必须调整：不是想办法"过滤掉所有恶意输入"，而是接受这类输入一定会出现，然后确保它即使出现也掀不起风浪。

二、分层防护：四道关卡各自的职责

业界的共识做法是分层，而不是靠一道防线。四层的分工大致如下：

这里有一条被反复强调的原则，值得直接写进验收标准：让智能体"能做事，但做不了大事"。权限越收敛，事故半径越小。

与分层防护配套的，是"执行层治理"这个概念。传统上很多团队把精力放在模型层——做提示词过滤、内容审核、权限控制。但真正决定事故是否发生的，是执行层：智能体调用了哪个接口、用了什么凭证、目标地址是否在允许范围内。模型层管的是"说了什么"，执行层管的是"做了什么"，后者才是止损点。

一个具体的对比很能说明差异。同样面对一封夹带隐藏指令的邮件：在权限过大的传统设计里，智能体读取邮件、吸收注入指令，随后提取数据库凭证并调用外部接口，这个调用会成功，安全团队在日志里看到的只是一条"例行授权流量"；而在最小权限加运行时策略的设计里，同一个调用会被运行时网关拦下——因为目标地址不在任务范围内，系统当场拒绝执行并触发告警，日志里留下被阻断的异常、意图指纹和涉及的具名工具。差别不在模型更聪明，而在是否有一层不依赖模型判断的确定性防线。

三、上线前的检查清单

OWASP 中国给出的上线核对项只有五条，但覆盖了绝大多数现实攻击：

1. 是否移除了不必要的工具？能力没有被授予，就不会被滥用；
2. 高权限动作是否有二次确认？
3. 外部内容是否被明确标记为不可信？
4. 调用链路是否有完整日志？
5. 凭证是否按任务隔离？

把这五条固化进发布流程，成本并不高。有测算显示，实时多智能体监控护栏会让语言模型的总消耗增加 15% 到 35%，而确定性的代理网关带来的额外延迟通常在十几毫秒以内——相对于一次误操作可能造成的损失，这个代价是可以接受的。

更完整的做法还包括：给每个智能体分配独立的工作身份，而不是复用某个员工的账号，避免责任归属出现空白；采用短时、任务级的临时凭证，任务结束即失效，即使某一环节被攻破也难以横向扩散；审计日志记录到足够的粒度——动作类别、批准该动作的策略版本、授权结果、调用的工具版本，这些字段决定了事故复盘时能不能还原现场。

四、按风险分级，而不是一刀切

把所有智能体都按最高标准管控并不现实，更可行的做法是先分级。一个简明的三级划分：

• 低风险：摘要、检索、文档辅助。允许自主执行，重点做输入隔离与日志记录。
• 中风险：表单预填、脚本生成、工单准备。需要权限收敛与输出校验。
• 高风险：云资源访问、生产环境动作、密钥处理、数据修改与外发。必须沙箱隔离、人工审批、完整审计。

分级之后，资源就能集中到真正危险的地方。同时建议把智能体安全当成一个持续的项目，而不是上线前打勾的检查项：威胁模型随能力变化而更新，上线前做一轮专门针对提示注入与工具滥用的对抗性测试，每个智能体的权限集合指定明确责任人。测试方式也应当区别于传统验收——不是验证"输入正确能否得到正确输出"，而是主动构造恶意输入，看它能否被诱导偏离原定行为。

这里还要提醒一个常被忽略的组织现象：各部门各自把智能体接上自己的工具、用自己的凭证、写自己的提示词，很快就形成一片难以审计的"影子自动化"。它的技术债积累速度远超传统系统，因为没人说得清到底有哪些智能体在跑、各自能碰到什么。解决办法不是禁止，而是登记——先把在用的智能体盘出来，再按风险分级补齐最小控制基线。

安徽好牛软件有限公司在合肥本地交付智能体项目时，会把权限清单、人工确认点与审计字段作为设计方案的一部分提交给客户确认，而不是等上线后再补。原因很直接：权限是事后最难收紧的东西——它会牵动已经跑起来的流程，而在方案阶段确定下来的边界，几乎不增加任何成本。

常见问题解答

Q1：智能体安全和我们熟悉的网络安全是一回事吗？

不完全一样。传统安全防护的是确定性软件的漏洞，而智能体的行为本身具有不确定性，同样的输入不保证产生同样的输出。因此防护重点是"限制它能做什么"，而不是"保证它一定做对"。

Q2：提示注入能彻底消除吗？

很难。更现实的思路是结构化地"容纳"它——通过输入隔离、最小权限、沙箱与人工确认，让一次成功的注入也无法造成实质损害。目标是任何单点失效都会被下一道控制拦住。

Q3：加了安全护栏会不会明显拖慢响应？

确定性网关的额外延迟通常在十几毫秒量级，对交互体验基本没有影响。真正带来开销的是实时监控机制，测算显示会增加 15% 到 35% 的模型消耗，但这类机制一般只在关键流程中启用。

Q4：中小企业有必要做这么细吗？

看智能体接触什么。如果只是内部文档问答，标准可以放宽；一旦涉及客户数据、资金动作或生产系统，哪怕规模不大，最小权限与操作留痕也是必须的，因为事故损失与公司规模无关。

Q5：怎么在验收时检查服务商的安全设计？

可以索要三样材料：权限清单与人工确认点说明、审计日志字段样例、上线前的对抗性测试记录（是否做过提示注入场景）。安徽好牛软件有限公司在项目验收阶段会同步提交这三项材料，让安全设计从口头承诺变成可核查的交付物。