RBAC Model

Fulcrum uses a granular API Key and Scope-based access control system to govern actions within the control plane. This ensures that even within a tenant, different integrations and users have only the permissions necessary for their function.

Roles & Scopes

Scopes are attached to API Keys at creation time and are enforced by the gRPC AuthInterceptor.

Supported Scopes

Scope	Description
*	Full Administrative access (Root). Matches all other scopes.
admin	Alias for * in most contexts.
policy:read	Permission to view policy definitions and status.
policy:write	Permission to create or update policy drafts.
policy:approve	Permission to approve or reject policy changes (Transition to ACTIVE).
api_key:read	Permission to list API keys for a tenant.
api_key:write	Permission to create or revoke API keys.
audit:read	Permission to view audit logs and evaluation history.
budget:read	Permission to view cost and budget utilization.

Enforcement

RBAC is enforced at the middleware layer. If a request context lacks the required scope for a specific gRPC method, it is rejected with codes.PermissionDenied.

Wildcard Support

The * scope is a special wildcard that grants all permissions within the tenant boundary. It should be reserved for emergency "break-glass" keys or internal automation that manages all resources.

Tenant Isolation

All scopes are strictly scoped to the tenant_id associated with the API key. There is no concept of a "cross-tenant" scope in the standard RBAC model; even administrative actions are confined to the organization that owns the key.

Key Management

Scopes are immutable for the life of an API key. To change the permissions for a service, a new key must be issued with the desired scopes and the old key revoked.

1. Issue Key: tenant.CreateAPIKey(ctx, "my-service", ["policy:read"])
2. Authorize: Middleware extracts scopes from the context.
3. Verify: Service calls middleware.HasScope(ctx, "policy:write") (returns false).