Topic-based policy routing: map governance profiles to projects via GitLab topics

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem

Enterprises need to apply different governance profiles to different categories of projects. A PCI project needs strict push rules; a SOX project needs 2-reviewer approval; an internal tool needs relaxed settings. Today, this mapping must be configured manually per project.

Security policies can be scoped to compliance framework labels, but push rules and branch protections have no equivalent scoping mechanism. There is no concept of reusable governance profiles that auto-apply based on project metadata.

Agentic Context

Agent-created projects can be automatically tagged by workflow type (e.g., topics like agent:security-scan, agent:sdlc-v2, compliance:sox). Topic-based policy routing means governance profiles apply the instant a project is tagged, with no manual configuration step. This enables differentiated governance for different agent workflows: a security scanning agent project gets strict push rules automatically, while an internal tool project gets relaxed settings.

This is especially relevant for the MCP Registry 3-layer model (&20421) where tool permissions are scoped by risk category (read/write/destroy). Topic-based governance routing is the project-level equivalent of tool-level permission scoping.

Field Evidence

A Professional Services tool deployed at a regulated enterprise customer maps governance profiles to projects via GitLab topics with AND/OR logic. Example: projects tagged audit:sox automatically inherit a SOX compliance profile (specific push rules + branch protections + compliance framework). Reusable strategy profiles compose into a precedence chain: defaults < topic profiles < namespace overrides < project overrides.

Proposal

  1. Allow governance profiles (sets of push rules, branch protections, compliance framework assignments) to be defined as reusable templates
  2. Map profiles to projects via GitLab topics with boolean logic (any_of / all_of)
  3. When a topic is added to or removed from a project, automatically apply or remove the associated governance profile
  4. Support a precedence model: instance defaults < group profiles < topic profiles < project overrides
  5. Surface active governance profiles per project in the UI

Connection to Existing Work

  • #463747 -- "Settings enforcement via compliance frameworks + project templates" (same problem, template-based routing)
  • #565625 -- "Configuration Profile User Stories" (Epic &16204, security scanner profiles)
  • #560663 -- Profiles vs. Policies taxonomy

DAP & AI Governance Cross-References

  • &14897 -- Custom compliance frameworks improvements (proposed parent epic)
  • &20421 -- MCP Registry & Tool Governance (3-layer permission model, same scoping pattern)
  • #585929 -- DAP Governance: Granular access management (allowlist/denylist at tool/action level)
  • #573629 -- UX for DAP Permissions and Governance (UI alignment)

Part of Governance-as-Code Series

This is one of 9 related issues: #591821, #591822, #591823, #591824, #591825, #591826, #591827, #591828, #591829

Edited by 🤖 GitLab Bot 🤖