Agent 的安全边界怎么划？一次划清

给智能体接工具之前，安全边界要先划清楚：它能调哪些工具、能碰哪些数据、单次动作的力度上限是多少。边界划得明白，才敢放手让它干活；边界含糊，一个误操作就可能波及线上数据。

类比给新员工配门禁：先给最基础的通行区域，表现稳定再逐步放开。失效之处在于，智能体的「表现」不像人那样容易观察，一次看似正常的任务里可能混着意外的调用组合，所以技术上的硬限制比信任更可靠。

边界划在工具这一层

模型本身只产出意图，真正落地的动作全靠工具执行，所以边界天然划在工具层：接哪个工具、允许哪些参数取值、单次调用影响多大，都在接入时确定。腾讯元宝、智谱清言等产品的插件开关就是这层思路的体现——不勾选的能力，模型说破天也调不到。

写操作和读操作分开看

读操作顶多把数据带出去，写操作会改变外部世界，两者风险量级不同。做法是把写操作单独归组：要求显式开启、限制可写范围、逐次留痕。删除、覆盖、对外发送这类不可逆动作，还要加二次确认或延迟执行，给反悔留窗口。

权限最小化落到三件事

第一，按任务配权限，做报表的智能体不需要发消息的能力；第二，按范围配数据，只暴露必需的字段和目录，而不是整个库；第三，按时效配授权，临时任务用临时凭证，到期自动收回。三件事都做到，出事时影响面就小得多。

边界之外还要有人盯着

边界挡已知风险，监控挡未知风险：调用记录要能回放，异常频率要能告警，见长时任务看哪些监控指标？内部门道在这。每次越界尝试都值得记录，它们往往暴露了配置疏漏。多智能体协作时权限会层层传递，责任与消耗都要按链路算清，见多 Agent 的成本怎么核算？拆开细算。

安全边界自查清单

• 写操作单独归组并要求显式开启
• 不可逆动作有二次确认或延迟执行
• 权限按任务、范围、时效三维度收窄
• 调用记录可回放，越界尝试有告警

一句话记住：边界不是限制能力，是让能力敢放开用。

白名单是边界最常用的载体，配置过程见工具白名单是怎么配的？过程拆开看；边界失守的典型入口是恶意输入，见提示注入在 Agent 上为什么更危险？；并发放量前先确认边界扛得住，见任务的并发度是怎么定的？关键步骤一次讲清。边界定得清，自动化才敢往前走。

边界配置最容易犯的错是抄模板：看别人配了什么就跟着配，不看自己的任务实际需要什么。别人的智能体要发邮件所以开放了邮件工具，你的只做数据汇总，抄过来就多了一个不必要的暴露面。每次接新工具前，把「我的任务真的需要它吗」问一遍，问不住的理由就不开。权限的回收同样重要：项目结束、任务下线时，对应的授权要同步收回，长期不用的权限是最容易被忽略的风险点，可以按月导出一份权限清单做核对。最后把边界文档化：每个智能体开了哪些权限、为什么开、谁审批的，写成一份简短说明存档，交接和复核时都有据可查。边界管理做的是慢功夫，前期多花十分钟，后期少出十次险。

关于安全边界再多问三句

• 边界会不会拖慢任务？：合理的边界只拦越界动作，正常路径几乎无感，感觉被拖慢多半是配得太粗。
• 模型自己能判断边界吗？：不能指望它，模型遵守的是提示词层面的约定，硬限制必须由执行层实现。
• 边界该多久复核一次？：任务范围变化、工具升级、出现越界告警时都要复核，平时按月例行过一遍。