给 Agent 智能体划权限边界，复合身份是怎么兜底的
给 Agent 智能体划权限边界，复合身份是怎么兜底的
一个团队刚把 AI 智能体接进研发流程时，第一个让人睡不着的晚上通常不是因为代码写错了，而是因为一个问题没人答得上来：这份改动到底是以谁的身份提交的？
如果 Agent 直接用操作者的账号和令牌干活，它天然继承了那个人的全部权限——维护者乃至所有者级别的权限，一次提示词就能触达。如果反过来给它一个共享的机器人账号，权限是收窄了，但提交记录里再也看不出是谁发起的，出了事查无可查。前者是权限失控，后者是审计失效。
极狐GitLab 的 Agent 平台给出了第三条路：复合身份（Composite Identity）。它把两个身份合进同一个令牌，让权限取交集，让责任留双份。
什么叫复合身份
复合身份是一种把两个身份合并到单个令牌里的认证授权机制：次要作者是实际执行操作的服务账号（系统用户），主要作者是发起请求的人类用户。令牌的有效权限等于人类用户权限与服务账号权限的交集，但操作被明确归属为"服务账号代表某人执行"。该机制在极狐GitLab 18.3 引入，18.8 转为正式可用（GA），自 18.9 起自动包含在 Agent 平台中，不再提供开关。
理解这个定义有两个关键点。
一是"交集"而非"并集"。 如果一个维护者触发了某个任务流，而服务账号在项目里只是开发者角色，那么这次执行实际生效的是开发者权限。用户不能通过 Agent 完成自己无权完成的事，服务账号也不会因为被触发者身份高就临时提权。
二是"双署名"而非"冒名"。 生成的提交会显示由服务账号代表你创建，而不是假装是你本人写的。提交历史里能一眼看出哪次改动是机器做的。
为什么这道边界非划不可
对照官方文档给出的三条设计目标，可以更清楚地看到它解决的是什么：
可追溯性。 所有 Agent 活动统一归属到服务账号，审计日志和提交历史里，自动化操作是一眼可辨的一类对象。想查"上周有多少改动是机器写的"，不需要先 Purge 一堆人的记忆。
安全性。 Agent 只能执行服务账号和触发者双方都有权执行的操作，这种交集访问从机制上堵死了权限提升。
问责性。 人类用户的身份被嵌进令牌，形成从 Agent 操作回溯到具体发起人的审计链路。
第三条在受监管行业里尤其要紧。官方的合规说明指出：当任务流创建合并请求时，该合并请求归属于触发任务流的人类用户，而不是服务账号。这么做是为了满足 SOC 2、SOX、ISO 27001、FedRAMP 这类要求职责分离的合规框架——这些框架通常要求同一个人不能既编写变更又批准变更上线。归属模型的判断理由是：人类用户指示服务账号创建了更改，而提示 AI 编写代码在合规视角下等同于自己编写代码。
复合身份到底怎么跑起来
流程本身不复杂，关键在于每一步的权限都是被约束出来的：
在 AI 目录里创建任务流。 这一步不涉及复合身份的额外改动。
为项目启用该任务流。 系统会在顶级群组下创建服务账号，命名形如
ai-flowname-groupname，并把它以开发者角色加入项目。用户执行任务流。 这次执行由一次性复合身份承载：主要作者是人类用户（通过动态作用域把用户 ID 写进令牌作用域），次要作者是上述服务账号。
权限取更严格的一侧。 用户是维护者、服务账号是开发者，实际生效的就是开发者角色。
令牌作用域被二次收窄。 文档中明确了两类令牌的分工：AI 工作流中复合身份使用的 OAuth 令牌，访问权限被限制在
ai_workflows和mcp作用域内；作为任务流一部分触发的 CI 作业，其令牌还要进一步受可用的作业令牌权限限制。两者是不同类型的令牌、不同作用域，所以 CI/CD 作业的权限并不等于 OAuth 令牌的权限。
需要留意适用边界：复合身份覆盖内置任务流、自定义流程、外部 Agent，以及任何通过 api/v4/ai/duo_workflows/workflows 端点启动的流程；但它不适用于 UI 和 IDE 中的极狐GitLab Duo Agentic Chat。也就是说，这套边界保护的是"在 Runner 上跑起来的任务流"，不是聊天窗口里的一问一答。
落地示例：把边界一次配到位
下面这套配置按顺序做完，Agent 的权限边界就落在了具体机制上，而不是写在某份 Wiki 里靠自觉。
第一步，按官方先决条件备好运行环境。
使用任务流的先决条件包括：满足极狐GitLab Duo Agent Platform 的先决条件；为顶级群组开启"允许内置任务流"；配置推送规则以允许服务账号；配置自有 Runner 或为项目开启极狐GitLab 托管 Runner。其中第二条常被漏掉——服务账号推送本质上仍是服务账号在推送，被推送规则拦下的结果通常表现为任务流执行失败而不是权限报错。
第二步，用 API 端点触发任务流，让执行走复合身份路径。
curl --request POST \
--header "PRIVATE-TOKEN: <your_access_token>" \
--header "Content-Type: application/json" \
--url "https://gitlab.example.com/api/v4/ai/duo_workflows/workflows" \
--data '{"project_id": "<project_id>", "flow": "<flow_name>", "prompt": "<task_description>"}'请求体中的字段名称与必填项以官方 API 文档为准，这里重点在于：只要流程是通过这个端点启动的，就会走复合身份，而不是发起者的裸令牌。
第三步，用 AGENTS.md 收敛执行上下文。
官方文档建议用 AGENTS.md 文件为内置任务流和自定义任务流提供应遵循的上下文与指令。实践中常见的写法是把"允许碰什么、不许碰什么"写成硬约束：
# AGENTS.md
本项目 Agent 执行约束：
- 只允许修改 src/ 与 test/ 目录下的文件，不得改动 migrations/ 与 infra/
- 任何涉及数据库 schema 的变更，先产出合并请求草稿，不得直接修改
- 生成的测试用例必须能在本地执行 `make test-unit` 通过后再提交这三条约束会被任务流读取为执行上下文。它不替代权限机制，但能把"技术上允许、业务上不该做"的部分讲清楚，减少人工返工。
四个容易出问题的地方
1. 服务账号被加进哪些项目，决定了任务流的触达面。 官方文档写明：流程可以访问"用户有权访问的项目"以及"服务账号被添加到的项目"。举例说，如果服务账号已被加入其他项目，且触发者本人也有权访问，那么即使该用户此前没在这些项目里用过这个流程，流程也能访问。所以服务账号的项目清单要按"授予范围"来审，而不是开通后不管。
2. 版本门槛比想象中细。 Agent 平台在极狐GitLab 18.8 及更高版本中需已开启；在 18.7 及更早版本中，还需要额外开启测试版和实验性功能。另一条容易被忽略：在 18.9 及更早版本中，无法将 Agent 平台与极狐GitLab Duo Enterprise 附加组件一起使用，需要升级到 18.10 或更高版本。复合身份自身也经历同样过程——18.3 引入时带功能标志且默认禁用，18.8 才正式发布。
3. 别把工具级审批当成唯一防线。 官方文档里，Agent 工具治理（配置工具级审批策略，在执行时通过人工审批管控敏感的 Agent 操作）与 AI 审计事件报告、AI 治理仪表板目前均列在"测试版和实验性功能"区段，且不消耗极狐GitLab Credits。这类能力适合作为增强手段，边界的重心仍应压在复合身份与仓库权限上。
4. Chat 里的操作不在同一保护域。 复合身份明确不适用于 UI 和 IDE 中的极狐GitLab Duo Agentic Chat。给团队做安全说明时一定要写清楚这条边界，否则工程师会误以为所有 AI 操作都被收进了同一套权限模型。
FAQ
复合身份能挡住 Agent 误删仓库吗？
能收窄攻击面，但不能替代常规防护。关键在于生效角色取的是"用户角色 ∩ 服务账号角色"，而服务账号被加入项目时是开发者角色，本身不具删除项目的权限。受保护分支与推送规则仍应照常配置，两者是叠加而非替代关系。
为什么任务流产出的合并请求归属于人而不是服务账号？
为了满足要求职责分离的合规框架，包括 SOC 2、SOX、ISO 27001、FedRAMP。这些框架通常要求用户不能既编写代码更改，又批准这些更改用于生产部署。把 MR 归属给人类触发者，才能让审批环节真正构成第二只眼睛。
chat 窗口里让 Agent 写的代码会被算进审计吗？
复合身份不覆盖 UI 与 IDE 中的 Agentic Chat，这一路径的建议是把它限定在个人开发分支，改动仍需经过正常的合并请求评审流程才能进主干。
把 AI 智能体的权限边界落到你的项目里
从最小的任务流开始：建一个只读或单目录可写的流程，跑一次提交，去提交历史里确认署名是否符合预期，再去审计日志里确认是否能反查到发起人。边界配得对不对，一次执行就能验证。
