过去企业做权限管理最常见的一套逻辑是谁登录系统 → 他属于什么角色 → 这个角色允许访问什么资源。开发人员可以访问代码仓库测试人员可以进入测试环境财务可以查看财务系统管理员拥有更高权限。这套机制就是我们熟悉的RBACRole-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 TABLEALTER TABLEUPDATE那么“用户具有数据库权限”显然不足以证明Agent当前应该执行这个操作。同一个用户。同一个Agent。同一个数据库。不同任务。风险完全不同。2. RBAC无法理解操作上下文传统权限系统看到的可能只是User ZhangSanRole DeveloperResource RepositoryAction 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权限一定会越来越细ReadWriteExecuteDeleteDeployPublishTransferExternal Send每一种Action拥有不同风险等级。例如读取代码可以自动执行。修改Workspace可以自动执行。安装未知依赖可能需要策略判断。访问陌生域名需要审批。执行生产部署必须人工确认。删除资源必须人工确认。这其实已经类似Risk-Based Authorization。不是简单Allowed / Denied而可能变成Low Risk → Auto ExecuteMedium Risk → Policy CheckHigh Risk → Human ApprovalCritical Risk → DenyOpenAI内部运行Codex时公开描述的也是类似思路低风险日常动作尽量减少摩擦高风险操作则停下来接受审查Sandbox负责执行边界Approval Policy决定什么时候Agent必须请求批准。这非常值得企业关注。因为这可能就是Agent权限系统未来的重要形态RBAC Policy Sandbox Approval而不是RBAC单独承担全部责任。六、第四层Temporal Boundary——权限应该有生命周期传统企业账号权限经常存在一个问题权限一旦授权长期存在。但Agent其实非常适合使用Just-In-Time Permission。例如Task #4821目标修复支付接口Bug。那么Agent可能临时获得repository/paymentwritetest environmentexecutedocumentationread权限有效期当前Task。任务结束以后自动撤销。也就是说未来Agent权限更合理的方式不是Codex拥有数据库权限。而应该是Codex在Task-4821执行期间可以读取Database-A中的指定Schema。任务结束权限消失。这实际上把权限模型从Persistent Permission变成Ephemeral Permission。长期权限越少Agent出现意外行为时能够产生的Blast Radius也就越小。七、为什么还需要Approval而不能全部自动化很多Agent产品都在降低Approval次数。这是合理的。如果Agent每执行npm installgit statuspytest都问一次是否允许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 youAgent时代还需要继续回答What is the taskWhat can the agent accessWhat action can it performUnder what conditionsFor how longDoes it require approvalWhat actually happened最终可能形成这样一套架构**RBACABACTask ContextSandboxTool PermissionNetwork PolicyRisk EngineHuman ApprovalAudit Log**这才更接近Agent时代完整的企业权限模型。十、Agent越强真正值钱的反而可能是“限制Agent”的系统过去几年AI行业一直在解决一个问题怎么让Agent拥有更多能力让它访问代码。让它执行Shell。让它访问Browser。让它连接MCP。让它操作数据库。让它自动提交PR。让它完成越来越长的工作流。但当能力继续扩大以后下一个企业级问题一定会变成怎么证明它只在应该行动的时候行动所以Agent下一阶段的竞争可能不只是谁的模型更聪明。谁能连续工作更久。谁能调用更多工具。还包括谁能更可靠地回答这个Agent为什么拥有这个权限为什么允许执行这个动作这个权限什么时候失效这个动作是谁批准的出了问题以后能不能完整追溯从这个角度看Agent权限体系正在从传统的Access Control逐渐走向Execution Governance。RBAC仍然是入口。但真正决定企业敢不敢把ChatGPT、Codex以及未来更强Agent接入核心系统的可能是RBAC之后的那一整套边界、策略、审批、隔离、审计与证据链。而这才是Agent真正进入企业生产环境之后必须解决的问题。