<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=630640) </details> <!--IssueSummary end--> ### Summary A custom Duo Agent Platform Flow can read an Incident, but can't read its native timeline or the project's deployment records. The timeline field returns `null`; the deployment API returns `403 insufficient_scope`. Those records exist and are readable through the triggering user's normal API account. We encountered this while building an incident review guide. The Flow needs the chronology and deployed revision to compare a reported failure with a code change. Without those reads, it either needs people to copy the observations into the issue or risks treating unavailable information as an empty history. This appears to be missing support for the `ai_workflows` token scope, not a missing project role. Restricting agent tokens is intentional; we're asking whether these read endpoints should be available within the existing composite-identity permissions. We haven't established that this is a regression. ### Steps to reproduce 1. In a GitLab.com project with Duo Agent Platform enabled, create an Incident and add at least one native Timeline event. Run a pipeline that records a deployment to an environment. Confirm both records are visible to the user who will start the Flow. 2. Create and enable a custom Flow with the `gitlab_graphql` and `gitlab_api_get` read tools. Enable its Mention trigger. Leave its normal service-account and token permissions unchanged. 3. Mention the Flow on the Incident and ask it to read the timeline using the query below. Use the Incident's database ID in the `IssueID` value, not its project-local IID. 4. In the same Session, ask it to call `gitlab_api_get` with endpoint `/api/v4/projects/86817463/deployments` and parameters `{"per_page":100}`. Substitute your project ID when reproducing elsewhere. 5. Compare both responses with the same reads through the triggering user's authenticated API client. In the example project, the Flow receives `null` and `403`, while the user can read the events and deployments. ```graphql query IncidentTimeline($path: ID!, $incident: IssueID!) { project(fullPath: $path) { incidentManagementTimelineEvents(incidentId: $incident, first: 100) { nodes { id note occurredAt updatedAt } pageInfo { hasNextPage endCursor } } } } ``` ```json { "path": "gl-demo-ultimate-pmurrell/dap-cookbook-incident-current", "incident": "gid://gitlab/Issue/204094774" } ``` ### Example Project [DAP Cookbook incident current](https://gitlab.com/gl-demo-ultimate-pmurrell/dap-cookbook-incident-current) contains a small reservation application and synthetic incident observations, not customer production data. - [Incident #1 and its Timeline tab](https://gitlab.com/gl-demo-ultimate-pmurrell/dap-cookbook-incident-current/-/work_items/1). Timeline events include `6754900`, `6755011`, and `6755012`. - [Timeline read, Session 8615774](https://gitlab.com/gl-demo-ultimate-pmurrell/dap-cookbook-incident-current/-/automate/agent-sessions/8615774). - [Deployment read, Session 8615311](https://gitlab.com/gl-demo-ultimate-pmurrell/dap-cookbook-incident-current/-/automate/agent-sessions/8615311). - [Environment records](https://gitlab.com/gl-demo-ultimate-pmurrell/dap-cookbook-incident-current/-/environments). Example deployment IDs: `1584083769`, `1584099169`, and `1584102206`. - [Regression MR !1](https://gitlab.com/gl-demo-ultimate-pmurrell/dap-cookbook-incident-current/-/merge_requests/1) and [its release job](https://gitlab.com/gl-demo-ultimate-pmurrell/dap-cookbook-incident-current/-/jobs/16688996440). - [Rollback MR !2](https://gitlab.com/gl-demo-ultimate-pmurrell/dap-cookbook-incident-current/-/merge_requests/2) and [its release job](https://gitlab.com/gl-demo-ultimate-pmurrell/dap-cookbook-incident-current/-/jobs/16689030226). These are direct reproduction links. The demo project's existing access settings still apply. ### What is the current *bug* behavior? The Incident read succeeds, but its timeline field is `null` despite populated events. The deployment list returns HTTP `403`: ```json { "error": "insufficient_scope", "error_description": "The request requires higher privileges than provided by the access token.", "scope": "api read_api" } ``` We repeated the read-only comparison on September 23, 2026 using a short-lived token issued by the supported `POST /ai/duo_workflows/direct_access` endpoint for the same project. Its reported scopes were `ai_workflows` and `mcp`. It reproduced both failures; the ordinary authenticated account returned the records. The diagnostic token stayed in memory and wasn't saved or included in this report. That diagnostic helps isolate the scope restriction. It isn't a replacement for the normal Mention Sessions linked above, and it isn't a proposed authentication method for readers of the guide. ### What is the expected *correct* behavior? If these reads are intended to be supported, the Flow should receive the Incident timeline and deployment records that both the triggering user and service account are allowed to read. No broader token scope or personal access token should be needed. If these reads are intentionally outside DAP's supported API access, please document that limitation and return an actionable permission explanation where possible. In particular, a `null` timeline shouldn't be interpreted as confirmation that there are no events. ### Relevant logs and/or screenshots The Session links above retain the original tool calls and results. The JSON response above is the later direct-access reproduction. No credentials are included. ### Output of checks This happens on GitLab.com. We haven't reproduced it on Self-Managed or established the first affected release. #### Results of GitLab environment info Not applicable: GitLab.com; no server access. #### Results of GitLab application Check Not applicable: GitLab.com; no server access. ### Possible fixes At inspected revision `c48538fbcfa51797a0e540594b05324f81f4bce6`, the [Incident timeline fields](https://gitlab.com/gitlab-org/gitlab/-/blob/c48538fbcfa51797a0e540594b05324f81f4bce6/app/graphql/types/project_type.rb#L635) and [TimelineEvent type](https://gitlab.com/gitlab-org/gitlab/-/blob/c48538fbcfa51797a0e540594b05324f81f4bce6/app/graphql/types/incident_management/timeline_event_type.rb) don't opt into `ai_workflows`. The [deployment read routes](https://gitlab.com/gitlab-org/gitlab/-/blob/c48538fbcfa51797a0e540594b05324f81f4bce6/lib/api/deployments.rb#L74) also lack that scope. This source revision explains the observed behavior; we don't know which exact commit GitLab.com was running. [MR !233592](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/233592) added the scope for other work-item reads after similar failures. It doesn't cover these incident/deployment paths. A fix here should preserve role and composite-identity checks, with tests for authorized reads and inaccessible projects—not give the Flow unrestricted `api` access. The [documented Flow token permissions](https://docs.gitlab.com/user/duo_agent_platform/composite_identity/#token-permissions-for-ai-catalog-flows) explain why changing a project role alone doesn't address the scope check. ### Patch release information for backports No backport request or severity claim yet. Please assess affected versions after confirming the intended support for these reads.