ChatGPT、Codex趋势：Agent权限越来越大，为什么企业不能只靠RBAC？

过去企业做权限管理，最常见的一套逻辑是：

谁登录系统 → 他属于什么角色 → 这个角色允许访问什么资源。

开发人员可以访问代码仓库，测试人员可以进入测试环境，财务可以查看财务系统，管理员拥有更高权限。

这套机制就是我们熟悉的 RBAC（Role-Based Access Control，基于角色的访问控制）。

在人主要负责操作系统的时代，RBAC非常有效。

但Agent开始进入企业工作流之后，一个问题正在变得越来越明显：

“这个人有没有权限”已经不足以回答“这个Agent现在应不应该执行这个动作”。

尤其是ChatGPT、Codex这一类Agent开始具备读取文件、修改代码、执行命令、访问网络、连接外部工具甚至连续完成多步骤任务的能力之后，权限模型正在发生一个很重要的变化。

企业需要控制的对象，已经从：

User → Resource

变成了：

User → Agent → Tool → Resource → Action

这也是为什么未来企业Agent治理不能只依赖RBAC。

一、RBAC解决的是“你是谁”，Agent带来的问题却是“你现在准备做什么”

RBAC的核心其实非常简单。

例如：

开发人员属于 Developer Role。

于是他可以：

• 读取代码仓库；

• 提交代码；

• 使用开发环境；

• 查看部分日志。

管理员属于 Admin Role。

于是他可能拥有更多系统权限。

只要人的操作范围相对稳定，这种方式非常好用。

但是Agent出现之后，中间多了一层。

以前是：

开发人员 → GitHub

现在可能变成：

开发人员 → Codex → GitHub

看起来只是多了一个Agent，但安全模型已经发生变化。

因为人类工程师通常是一次完成一个动作：

打开文件。

修改代码。

运行测试。

提交PR。

而Agent接受的可能只是一句话：

帮我修复这个支付模块的问题，测试通过以后提交修改。

接下来Agent可能自主完成十几甚至几十个动作：

读取代码；

搜索依赖；

修改配置；

执行Shell命令；

安装依赖；

访问文档；

运行测试；

修改更多文件；

创建Git分支；

最后准备提交代码。

用户只授权了一次目标。

真正发生的，却是一整条执行链。

这时候问题已经不是：

这个开发者有没有代码仓库权限？

而是：

这个Agent在当前任务、当前目录、当前环境、当前步骤下，是否应该拥有这项权限？

这是两个完全不同的问题。

二、Agent最大的变化不是“更聪明”，而是拥有了执行权

很多人讨论ChatGPT和Codex时，关注的是模型能力：

模型会不会写代码？

推理能力怎么样？

上下文够不够长？

Bug修复能力强不强？

但对于企业而言，还有一个更重要的变量：

Action Surface——Agent能够真正产生影响的范围。

一个只能回答问题的模型，风险主要是：

回答错误。

但是一个能够：

读取内部文件、

修改代码、

执行命令、

连接工具、

访问网络、

调用外部系统

的Agent，风险完全不同。

OpenAI目前对企业级ChatGPT和Codex的设计其实已经能看到这种趋势。

OpenAI的企业部署文档除了RBAC和用户组之外，还明确涉及应用访问、功能开关、安全控制、监控以及哪些活动需要额外审批。

Codex相关插件权限也进一步区分了：

是否允许连接某个App；

只能读取还是可以执行动作；

某些动作是否需要用户确认；

数据源边界和其他应用级限制。

这说明Agent时代真正需要管理的，已经不只是：

Access

而是：

Action。

也就是说：

不仅要控制“它能看到什么”，还要控制“它能改变什么”。

三、为什么传统RBAC开始出现三个明显缺口？

RBAC不会消失。

但它更像Agent权限体系的第一层，而不是最后一层。

原因主要有三个。

1. RBAC通常是静态的，Agent任务却是动态的

假设一个开发者拥有生产数据库访问权限。

按照传统RBAC逻辑：

Developer A → Production DB → Allowed

那么理论上，由开发者启动的Agent是不是也应该拥有这个权限？

问题就在这里。

开发者今天可能让Agent：

分析线上SQL慢查询。

读取数据可能合理。

但明天任务可能是：

优化数据库结构。

如果Agent在过程中自主判断需要执行：

DROP TABLE

ALTER TABLE

UPDATE

那么“用户具有数据库权限”显然不足以证明：

Agent当前应该执行这个操作。

同一个用户。

同一个Agent。

同一个数据库。

不同任务。

风险完全不同。

2. RBAC无法理解操作上下文

传统权限系统看到的可能只是：

User = ZhangSan

Role = Developer

Resource = Repository

Action = Write

因此允许写入。

但是Agent治理需要进一步知道：

哪个Repository？

哪个Branch？

哪些文件？

来自哪个Task？

是否涉及生产配置？

是否修改CI/CD？

是否修改权限系统？

是否准备执行部署？

是否来自外部网页中的指令？

这就是：

Context-Aware Authorization。

权限判断开始从：

谁可以做什么

升级成：

谁，在什么情况下，通过什么Agent，为了什么任务，可以对什么资源执行什么动作。

3. Agent可以连续调用工具

这是最大的区别。

人类权限系统通常默认：

每一次操作相对独立。

Agent则天然是连续执行系统。

例如用户说：

调查为什么线上接口变慢并修复。

Agent可能形成这样的执行链：

读取日志
↓
搜索代码
↓
读取数据库配置
↓
查询线上指标
↓
修改代码
↓
安装依赖
↓
运行测试
↓
访问网络
↓
修改部署配置

其中每一步单独看可能都没有问题。

真正危险的是：

这些权限被组合起来以后，会不会形成原本不存在的能力？

这实际上就是经典安全问题中的：

Permission Composition。

Agent让这个问题更加突出。

四、Agent权限真正需要控制的是“四个边界”

未来企业部署Agent，我认为至少应该有四层边界。

第一层：Identity Boundary

解决：

谁可以使用Agent？

这一层RBAC依然非常重要。

例如：

普通员工是否可以使用Codex；

哪些开发团队可以使用Agent；

谁可以启用高级工具；

谁可以修改Agent配置。

这是身份层。

第二层：Resource Boundary

解决：

Agent可以碰什么？

例如：

只能访问项目A；

不能读取项目B；

只能写当前Workspace；

不能读取SSH目录；

不能访问生产Secrets；

只能读取指定数据库。

Codex本身就大量采用Sandbox设计。

OpenAI公开介绍其内部Codex安全实践时提到，Sandbox用于定义技术执行边界，包括Agent可以写入哪里、能否访问网络、哪些路径受到保护。

这已经不是单纯RBAC能解决的问题。

它属于：

Execution Isolation。

五、第三层才是Agent时代最重要的：Action Boundary

很多企业容易忽略这一层。

同样访问一个Git Repository：

读取README和删除整个仓库显然不是同一个风险等级。

因此未来Agent权限一定会越来越细：

Read

Write

Execute

Delete

Deploy

Publish

Transfer

External Send

每一种Action拥有不同风险等级。

例如：

读取代码：

可以自动执行。

修改Workspace：

可以自动执行。

安装未知依赖：

可能需要策略判断。

访问陌生域名：

需要审批。

执行生产部署：

必须人工确认。

删除资源：

必须人工确认。

这其实已经类似：

Risk-Based Authorization。

不是简单：

Allowed / Denied

而可能变成：

Low Risk → Auto Execute

Medium Risk → Policy Check

High Risk → Human Approval

Critical Risk → Deny

OpenAI内部运行Codex时公开描述的也是类似思路：低风险日常动作尽量减少摩擦，高风险操作则停下来接受审查；Sandbox负责执行边界，Approval Policy决定什么时候Agent必须请求批准。

这非常值得企业关注。

因为这可能就是Agent权限系统未来的重要形态：

RBAC + Policy + Sandbox + Approval

而不是RBAC单独承担全部责任。

六、第四层：Temporal Boundary——权限应该有生命周期

传统企业账号权限经常存在一个问题：

权限一旦授权，长期存在。

但Agent其实非常适合使用：

Just-In-Time Permission。

例如：

Task #4821

目标：

修复支付接口Bug。

那么Agent可能临时获得：

repository/payment：write

test environment：execute

documentation：read

权限有效期：

当前Task。

任务结束以后：

自动撤销。

也就是说未来Agent权限更合理的方式不是：

Codex拥有数据库权限。

而应该是：

Codex在Task-4821执行期间，可以读取Database-A中的指定Schema。

任务结束：

权限消失。

这实际上把权限模型从：

Persistent Permission

变成：

Ephemeral Permission。

长期权限越少，Agent出现意外行为时能够产生的Blast Radius也就越小。

七、为什么还需要Approval，而不能全部自动化？

很多Agent产品都在降低Approval次数。

这是合理的。

如果Agent每执行：

npm install

git status

pytest

都问一次：

是否允许？

Agent最终会退化成：

“自动执行，但需要人不停点确认。”

生产效率会非常低。

但另一个极端同样危险：

Full Access。

OpenAI介绍Codex Windows Sandbox时就直接指出，Full Access可以让Codex无需审批或限制地执行命令，减少摩擦的同时也会牺牲监督能力；Codex运行时可能执行测试、读取或编辑文件、创建Git分支等操作，因此需要系统级Sandbox约束执行范围。

所以企业真正需要的不是：

更多Approval

而是：

更聪明的Approval。

例如：

读取项目文件 → 自动

修改Workspace代码 → 自动

访问白名单域名 → 自动

访问未知域名 → Review

修改CI/CD → Review

修改IAM权限 → Review

访问生产Secret → Review

删除生产资源 → Deny / 强审批

也就是说：

审批应该与风险绑定，而不是与每个操作绑定。

八、最终还缺最后一层：Audit

即使前面的权限体系全部建立，企业仍然必须能够回答：

Agent刚才到底做了什么？

因此完整Agent治理体系最终应该变成：

Identity
↓
RBAC
↓
Task Context
↓
Policy Engine
↓
Sandbox
↓
Tool Permission
↓
Risk Evaluation
↓
Approval
↓
Execution
↓
Audit Log

这里Audit非常关键。

未来真正企业级的Agent平台不能只有：

Chat History

而需要：

Execution History。

至少应该能回答：

谁启动了Agent？

输入了什么任务？

Agent访问了哪些资源？

调用了哪些工具？

执行了什么命令？

修改了哪些文件？

访问了哪些域名？

哪些行为自动放行？

哪些经过人工审批？

最终产生了什么结果？

OpenAI目前对企业级Codex治理的描述也明显向这个方向发展，其企业控制体系涉及身份、授权、策略执行、审计、数据流以及管理员可见性等能力。

这说明AI Agent进入企业之后，权限问题最终一定会与：

Policy + Observability + Auditability

结合。

九、未来可能不是RBAC被淘汰，而是RBAC被“包进去”

所以标题里的：

为什么企业不能只靠RBAC？

并不是说RBAC过时了。

恰恰相反。

RBAC仍然会存在，而且仍然是企业权限体系非常重要的基础。

只是它解决的主要是第一道问题：

Who are you？

Agent时代还需要继续回答：

What is the task？

What can the agent access？

What action can it perform？

Under what conditions？

For how long？

Does it require approval？

What actually happened？

最终可能形成这样一套架构：

**RBAC

• ABAC

• Task Context

• Sandbox

• Tool Permission

• Network Policy

• Risk Engine

• Human Approval

• Audit Log**

这才更接近Agent时代完整的企业权限模型。

十、Agent越强，真正值钱的反而可能是“限制Agent”的系统

过去几年，AI行业一直在解决一个问题：

怎么让Agent拥有更多能力？

让它访问代码。

让它执行Shell。

让它访问Browser。

让它连接MCP。

让它操作数据库。

让它自动提交PR。

让它完成越来越长的工作流。

但当能力继续扩大以后，下一个企业级问题一定会变成：

怎么证明它只在应该行动的时候行动？

所以Agent下一阶段的竞争，可能不只是：

谁的模型更聪明。

谁能连续工作更久。

谁能调用更多工具。

还包括：

谁能更可靠地回答：

这个Agent为什么拥有这个权限？

为什么允许执行这个动作？

这个权限什么时候失效？

这个动作是谁批准的？

出了问题以后能不能完整追溯？

从这个角度看，Agent权限体系正在从传统的：

Access Control

逐渐走向：

Execution Governance。

RBAC仍然是入口。

但真正决定企业敢不敢把ChatGPT、Codex以及未来更强Agent接入核心系统的，可能是RBAC之后的那一整套：

边界、策略、审批、隔离、审计与证据链。

而这，才是Agent真正进入企业生产环境之后必须解决的问题。