正文
企业准备把 AI Agent 接进开发流程时，先不要只问“哪个模型最强”。更关键的问题是：这个 Agent 能访问什么系统、能替谁执行动作、每一次工具调用是谁批准的、出问题后能不能追责。
2026 年 6 月，围绕 Agent authorization 的讨论明显升温。WSJ 报道 Arcade.dev 融资 6000 万美元，核心问题正是企业如何控制 AI Agent 在应用、数据库和工具里的授权边界。参考：WSJ 报道。
这件事对开发者很直接：AI Coding 不再只是补全代码或写函数。Agent 开始能读仓库、跑命令、开 PR、调 MCP Server、访问企业工具。只要它能行动，授权层就会成为第一道门槛。
先确认 Agent 能做什么
先把 Agent 的能力拆开，不要用一句“它能帮我写代码”概括。
如果这些问题答不上来，先不要把 Agent 接到企业环境。模型能力再强，也不能替代权限边界。
| 读代码 | 能读哪些仓库、目录、分支和历史 |
| 改代码 | 能不能直接写文件、提交 commit、创建 PR |
| 跑命令 | 能不能安装依赖、执行脚本、访问网络 |
| 调工具 | 能不能调用 GitHub、Slack、Jira、数据库、云服务 |
| 用账号 | 是用用户自己的授权，还是共享服务账号 |
| 保留记忆 | 会不会把项目上下文、日志或客户数据带到后续任务 |
模型判断不能替代授权
AI Agent 会“判断”下一步该做什么，但授权不能只靠模型判断。模型输出是概率性的，权限控制必须是确定性的。
一个安全的企业工作流，至少要把这三层分开：
如果推理层和执行层直接连在一起，Agent 一旦误判、被提示注入影响或扩大任务范围，就可能越权操作。授权层的作用是让“模型想做”不等于“系统允许做”。
| 推理层 | 理解任务、提出计划、选择工具 |
| 授权层 | 判断这次工具调用是否被允许 |
| 执行层 | 真正访问文件、API、数据库或终端 |
工具调用前要有硬检查
真正有用的授权不是事后审计，而是工具调用前的硬检查。Agent 准备执行动作时，系统应该先判断这次动作是否满足策略。
你可以把策略写成几类问题：
研究方向里已经出现“pre-action authorization”这类方案，重点就是在工具调用执行前做确定性策略判断，并生成审计记录。参考：Before the Tool Call。
- 这个用户是否有权让 Agent 操作这个仓库？
- 这个 Agent 是否被允许写文件，还是只能读？
- 这次命令是否会联网、安装依赖、删除文件或改 Git 状态？
- 这次 API 调用是否超出 OAuth scope？
- 这次动作是否需要人工确认？
- 这次操作是否触发预算、数据分类或合规限制？
不要把人类权限整包交给 Agent
最危险的默认做法，是让 Agent 继承人类账号的全部权限。人类有经验、责任、组织约束和风险意识；Agent 没有同样的社会约束。它会为了完成目标反复尝试工具，直到被权限或策略挡住。
企业应该优先使用更小的授权方式：
如果一个工具要求 admin、full access、all repositories、全空间读写或长期 token，先不要接入默认工作流。
| 读仓库 | 单仓库、只读、限定分支 |
| 开 PR | 允许创建分支和 PR，不允许直接合并 |
| 跑 CI | 允许触发指定 workflow，不允许改 secret |
| 查工单 | 只读项目工单，不读全公司空间 |
| 访问数据库 | 只读视图、脱敏数据、测试环境优先 |
| 操作云资源 | 临时凭据、单项目、单动作审批 |
MCP 和 A2A 会放大授权问题
MCP 让 Agent 更容易连接工具和数据源；A2A 让不同 Agent 之间更容易协作。能力变强后，授权问题也会放大。参考：MCP 官方介绍、AIP 论文。
你现在要特别注意两种边界：
如果多 Agent 工作流里没有身份、授权、委托链和审计记录，出问题后很难回答“是谁让它做的”。日志里只看到某个 API token 调用了接口，不等于能追到真实用户意图。
- Agent 调工具：它是否有权调用这个 MCP Server，参数是否被完整展示，token 是否只给了必要 scope。
- Agent 委托 Agent：下游 Agent 是否继承了上游权限，还是拿到更小的临时权限。
审计日志要能区分三件事
企业审计不能只记录“工具被调用了”。至少要能区分：
没有这三层，事后复盘会变成猜测。用户可能只是让 Agent “整理 issue”，但 Agent 可能读取了额外仓库、修改了 label、触发了自动化、调用了外部 MCP Server。审计日志要能把这些动作拆开。
| 用户意图 | 用户原始请求、批准动作、审批时间 |
| Agent 决策 | Agent 为什么选择这个工具、传了哪些参数 |
| 工具执行 | 实际 API、文件、命令、返回结果和副作用 |
企业先做哪几个最小动作
如果团队已经在用 Claude Code、Codex、GitHub Copilot、Cursor 或自建 Agent，不需要等完整平台上线才治理。先做几个最小动作：
这几件事不复杂，但能立刻改变默认风险：Agent 不能因为目标模糊就自动扩大权限。
- 列出所有 Agent 能访问的仓库、目录、工具和账号。
- 把 install、联网、删除、提交、推送、发消息、改数据库列为需要确认的动作。
- 给 MCP Server 和第三方工具设置最小 scope。
- 禁止共享长期高权限 token 给 Agent。
- 在 PR 或任务记录里保留 Agent 使用和验证结果。
- 对高风险任务要求人工审批和回滚方案。
- 定期撤销不用的 OAuth app、MCP Server 和服务账号。
开发者自己怎么判断一个 Agent 能不能进团队
你可以用下面这张表做采购、试点或内部接入检查。
如果一个 Agent 产品只展示“模型很强、速度很快、能自动完成任务”，但说不清这些边界，不适合直接进入企业开发环境。
| 能不能限制仓库和目录 | 可以按项目、仓库、目录或环境限制 |
| 能不能限制工具 | 可以按工具和动作开关 |
| 高风险命令会不会停下来 | 删除、安装、联网、推送、生产操作需要确认 |
| OAuth scope 能不能最小化 | 可以选择只读、单仓库、单资源 |
| 日志能不能导出 | 能看到用户、Agent、工具调用和结果 |
| 出错能不能回滚 | 有 diff、分支、PR、命令日志或快照 |
| 数据能不能分级处理 | 支持排除敏感目录、secret、客户数据 |
结论：Agent 落地先过授权关
AI Agent 的价值来自行动能力：它能读上下文、调用工具、修改代码、跑流程。企业风险也来自同一个地方。
所以 Agent 落地的第一道门槛不是模型榜单，而是授权层。开发团队要先确认 Agent 能访问什么、能改什么、谁批准、怎么审计、怎么撤回。只有这些边界清楚，模型能力才会变成可控生产力，而不是新的权限黑箱。