GitLab's AI Governance Dashboard Puts Agent Activity in One View

• The dashboard shows which agents ran, who used them, and which projects they touched, along with the tools and sessions associated with each agent.
• Three tiles show agents run, sessions started, and tool calls over the past seven or 30 days. Each tile shows the daily trend and the change from the previous period.
• Audit event storage is off by default. Events are recorded only after an Owner or Security Manager turns it on under Settings > GitLab Duo.
• Access requires the Owner role on the top-level group, or a custom role with the read_agent_artifacts ability.
• For Duo Agent Platform sessions, the post lists the prompt, tools called, MCP servers used, model that ran, and project changed. Sessions can be downloaded as an immutable copy or streamed to a SIEM system.
• External agents are connected with GitLab CLI (glab) 1.122.0 or later on macOS or Linux. Running glab govern setup installs the Claude Code hooks. Adding --agents codex,cursor sends Cursor and Codex sessions every 30 minutes, and glab govern doctor confirms the setup.

Why it matters #

The post frames the problem as activity that stays invisible. Agents from Duo Agent Platform run inside GitLab, while externally connected agents run on developers' own machines, and the post calls the result the shadow AI problem. The dashboard links each agent to the developer behind it, so you can check which agents ran against the agents you approved. The post also notes that teams often struggle to tell whether a developer used an approved tool or model.

The change matters most for audits. The post says traditional audit trails were built for human changes, so agent records are often scattered or missing. Every agent action is recorded as an audit event with the model, tools, and project involved. This suggests that an investigation or auditor request can draw on one record rather than several sources. The post does not state how long recorded events are retained, so check that against your own requirements.

How to turn it on #

Setup has four steps, and the first two decide who can see the data and whether any history is recorded. The post lists them in this order in AI Governance: One view of agent activity.

1. Confirm that the people who will watch agent activity have the Owner role, or create a custom role with the read_agent_artifacts ability.
2. Turn on audit event storage under Settings > GitLab Duo, by selecting Change configuration and then Store AI audit events in the Data and privacy section. An Owner or Security Manager role is required.
3. Open AI > Governance and select the Dashboard tab to see GitLab Duo Agent Platform activity.
4. Sign in with glab 1.122.0 or later, run the setup command for your agents, and confirm the result with glab govern doctor.

Who is affected #

Top-level group Owners are the first readers affected, because the dashboard requires the Owner role or a custom role with read_agent_artifacts. Turning on audit event storage is the step that starts recording history, and the post says events are not recorded until it is enabled. Groups on Premium or Ultimate can use the beta, according to the same post.

Teams that use Claude Code, Cursor, or Codex need glab 1.122.0 or later on macOS or Linux to connect those agents. Security and risk owners are the readers the post names for the questions the dashboard answers: who ran an agent, what it did, and who is accountable for it.