文章目录
当 Agent 只负责回答问题时，企业关心它回答得是否正确。当它可以移动文件、调用内部服务、修改配置时，另一个问题变得同样重要：它究竟被允许做什么？
一个能理解所有指令的 Agent，不应该因此拥有所有权限。企业需要把组织里的分工转化成可执行的规则，而且这些规则必须在实际操作发生时成立。
权限围绕身份、资源和动作建立
“能访问项目资料”不是一个足够精确的规则。一个人可能可以看到目录，却不能读取里面的文件；可以读取，也不一定可以覆盖或删除。
brazosd 企业权限把授权细化为具体身份对某类资源执行某种动作的许可。例如，一条规则可以限制某个云盘目录的读取，也可以控制某台设备的访问。
| 要素 | 回答的问题 | 例子 |
|---|---|---|
| 身份 | 谁在请求？ | 成员、Agent 所代表的用户、云函数服务身份 |
| 资源 | 要操作什么？ | 云盘目录、设备、平台中的业务资源 |
| 动作 | 准备做什么？ | 列出、读取、写入、删除、访问 |
| 策略与用户组 | 如何表达和复用组织规则？ | 项目组统一授权、敏感目录统一限制 |
表格可以左右滑动
这种表达方式让权限跟随业务资源，而不是依赖某个页面是否显示一个按钮。
组织规则如何合并
企业规则可以直接授予用户，也可以通过用户组和可复用策略关联。一个人同时属于多个团队时，系统需要确定这些规则怎样合并。
当前企业权限模式采用默认拒绝，并让明确的拒绝规则优先于允许规则。例如，项目组获得资料读取权限，但财务目录被明确禁止，不能靠加入另一个允许范围更大的组绕开这条限制。
这些规则还建立在原有的所有权和组织边界之上。普通组织与启用企业权限的组织适用的检查不同，不能把企业策略默认拒绝直接套用为所有账户的行为。
对目录操作而言，删除和移动还涉及整个子树。若只检查最外层目录，内部受到保护的材料可能被一起移动或删除。因此，权限不仅要看“入口”，也要考虑操作实际影响的范围。
Agent 可以配置权限，但不能创造权限
brazosd 已有用于管理企业权限的技能与平台控制工具。具备相应管理权限的用户，可以让 Agent 读取现有规则、组织调整方案，再调用 API 执行配置。
关键在于“代表谁”。当前会话中的平台调用使用会话用户的授权，设备访问也依据该用户的身份和设备权限。Agent 的表达能力、名称或提示词，不构成额外授权。
平台还提供权限预检：在不执行目标业务动作的情况下检查相应接口的前置授权。它有助于发现权限缺口，但不能证明所有业务校验都会通过。变更后仍需要读取实际状态，确认目标范围和原有约束都符合预期。
由此，自然语言成为管理入口，而可执行的权限规则仍然是系统的边界。
应用也需要自己的身份
云函数会主动读取文件、写入记录或调用其他 API。若它长期使用管理员的个人凭据，就很难区分人的操作和程序的操作，也难以单独收回权限。
brazosd 为云函数提供独立的服务身份。在企业组织中，它们可以通过专门的用户组和策略获得所需权限；创建函数并不意味着自动获得全部企业资源的访问权。
这为 brazosd on brazosd 提供了必要基础：用云应用构建平台功能时，应用仍然是受约束的参与者。
后台执行比界面限制更重要
隐藏按钮可以减少误操作，却不能替代 API 的授权检查。Agent、自定义前端和云函数都可能绕开官方界面直接调用接口。
brazosd 在 API 与相应资源访问路径上执行权限检查，并对云盘等能力加入具体资源范围的判断。涉及后台任务或新增内部调用路径时，仍需按实际路径设计和验证权限，不能假定一条界面规则覆盖所有执行方式。
企业级能力由这些边界累积而成。它也不等于天然获得某项合规认证，或自动记录一切操作；审计、运行监控与合规要求需要按具体场景继续建设。
权限让能力可以放心扩大
Agent 越能跨模块工作，越需要稳定的授权规则。组织可以允许它处理某个项目，同时保留财务、人事或其他敏感资源的边界。
因此，权限不是在能力做大之后补上的开关，而是让能力进入组织的前提。它把 Agent > UI 的便利，与设备互联和云应用的真实影响连接起来：入口可以简单，执行边界必须明确。