Governance Service Authentication and RBAC
Credential validation and access enforcement in Governance Service, with guidance for integrators.
Governance Service relies on Auth Service to validate identity and role permissions. A request can represent a signed-in user, a user API key, or a platform service account depending on the workflow.
Access Model
Access is based on project and organization roles. Governance Service checks those roles before allowing users to view projects, apply policies, manage controls, create declarations and reviews, manage indicators, or work with credentials.
Listing an organization’s projects returns every project to that organization’s owner, and only assigned projects to other members.
An organization’s activity logs, and one member’s activity within it, follow the same rule: the organization’s owner reads every entry, and a member assigned to projects in that organization reads the entries from those projects. An Agent Operator with no project assignment gets an empty list, and any other member with no assignment in the organization gets 403 Forbidden.
Learn more about Roles and Permissions.
Integrator Guidance
Integrations should use API keys or service accounts only when machine access is required. Store credentials in a secrets manager, rotate them regularly, and scope them to the smallest practical set of workflows.
If an integration can authenticate but cannot perform an action, check the project context and assigned role before treating the issue as a service outage.
Related
- Roles and Permissions — the full role and permission matrix
- RBAC and Membership — the organization and project roles Auth Service enforces
- API Keys and Service Accounts — key scopes, project binding, and when to use a service account
- Activity Logs — the activity log view these access rules apply to
- Auth Service Operations — first checks when an integration authenticates but is refused