最近看智能体演示，很容易被那个会自己点网页的光标吸引。它能查资料、填表，也能调用接进来的公司工具。真正决定这套东西能否进企业的部分，常在演示画面之外。它拿到了哪个账号，能读什么，又能改什么。
我把 MCP 的授权规范和几份公开的智能体安全文档对了一遍。规范花了很大篇幅处理令牌受众、跳转地址和授权码保护。这些细节看着离业务很远，落到日常工作里却很直接。一枚原本发给客户系统的令牌，不能拿去访问另一套服务。一个浏览器登录态，也不该顺手变成智能体通行所有后台的证件。
先把任务写窄
“看看邮箱，把该处理的都处理了”给人的空间很大，给智能体的风险也很大。邮件正文里可能有外部发来的指令，附件和网页也可能夹着误导模型的文字。OpenAI 的 Codex Action 安全文档把拉取请求正文、提交信息、仓库指令文件和截图都列进不可信输入范围。它们可以提供材料，不能自动取得更高权限。
任务最好写到具体对象和动作。读取今天标记为售后的邮件，提取订单号并生成回复草稿，这样的边界能检查。直接发送邮件、退款或修改客户资料，需要另一个明确步骤。读取和改写也应分开授权。智能体先交一份待办，人确认以后才执行有后果的动作。
这种安排会少一点演示里的流畅感。它换来的是可追查。出了错，可以看到模型读过哪些材料，调用了哪个工具，最后是谁批准了修改。
令牌也要认准去处
MCP 授权规范要求客户端在授权与令牌请求中注明资源，服务端也要核对令牌是否确实签发给自己。规范还要求公开客户端使用 PKCE，防止授权码在跳转过程中被截走，并建议使用短期访问令牌与轮换刷新令牌。
企业不必先背这些名词。采购或开发时问几件具体的事就够了。令牌能访问哪些系统，多久失效，离职账号怎样收回，日志里会不会留下完整令牌。供应商若只能回答“已经接入 OAuth”，信息还不够。授权协议解决了登录过程，权限大小仍由系统设计者决定。
触发入口也要收紧。Codex Action 的文档提醒，开放给任意用户触发的工作流可能消耗绑定的 API 密钥。能提交问题的人很多，能让智能体运行脚本的人应该少得多。外部输入可以进入队列，真正执行前要经过可信身份和规则检查。
每次工具调用都要过关
OpenAI Agents Python 的公开文档区分输入护栏、输出护栏和工具护栏。输入检查只能看任务开头，工具护栏会在每次自定义工具调用前后运行。这个区别很要紧。智能体起初收到的要求可能很正常，浏览网页以后才碰到恶意内容。只检查第一句话，拦不住后面出现的新风险。
我的判断很简单。智能体接入企业系统时，先给只读权限，先跑一项范围很小的任务，再把发送、删除、付款和改权限留给人工确认。连续运行一段时间，日志能说明错误率和误触发情况，再决定是否放开下一项动作。
会点网页已经很有用。权限收得住，这个能力才适合留在公司的日常流程里。