Introduction
Access to AI Governance is granted through the platform's own role system, not through a separate set of governance permissions. If you can reach the module, an administrator has given your role access to it.
Where access is managed
Roles are defined and assigned in Settings > Governance > Roles. That is where to go to request access, review who has it, or change it.
Every page in this module carries the same pointer, so you never have to remember which surface owns permissions.
What to ask your administrator for
Access to AI Governance is granted through platform roles, and this module does not define its own. A reader who needs access has to ask someone — so ask for the capability, naming the surface and the action, rather than for a role name this documentation cannot supply.
To do this | Ask for |
Open AI Governance at all | Read access to the AI Governance module |
Add a connection to Discovery | Access to the connection you intend to sweep — connections are shared platform objects |
Delete an agent or model record | Delete permission on that record. The row action is hidden without it, which is why it can look missing rather than forbidden |
See the | Global project read access, plus the all-workspaces view. Without both the column hides itself |
Read incidents | Deliberately scoped access — see below. Incident content is the material your controls were written to catch |
See the | The STANDARD permission on the policy entity type. Without it you see Custom Policies only |
Create a connection from inside | Create permission on Connection, and create permission on that connector |
Edit or delete a policy or a control | Edit or Delete permission on that record |
Choose a | Project view access, in the all-workspaces view |
Open the Evaluation tabs, or run an experiment | View on Experiment, Dataset and Metric; Execute to run an experiment |
Note: A missing button is usually a permission, not a missing feature. Row actions and whole columns hide themselves when you lack the permission behind them rather than appearing disabled. If a colleague can see something you cannot, compare permissions before reporting a bug.
What access does not control
Two things are worth separating from permissions, because they look like access problems and are not.
What Discovery can see — Bounded by the credentials on the connection, not by your role. A sweep that returns less than you expected is usually a connection scoped narrowly on the platform side. See How Agent Identification Works.
What a control can do — Bounded by the asset's connection tier. A control that detects but never blocks is not a permissions issue — see Connection Types.
One thing to raise with your administrator
Incident titles are the offending content itself. An incident list is, by construction, a collection of exactly the material your controls were written to catch — personal data, credentials, prohibited topics.
Treat access to Incidents as access to that data, and scope it deliberately rather than by default.