Organizations, teams, roles, SSO, API keys, and audit logging — how Safeguard handles identity and access.

RBAC, Teams & Organizations

Safeguard's identity and access layer is built for organizations that need clear ownership boundaries, tight least-privilege defaults, and a full audit trail.

Hierarchy

Organization
  └─ Team
     └─ Project
        └─ Asset

Organization — the top-level tenant boundary. Billing, SSO, audit log, compliance configuration live here.
Team — a group of users with shared access. Roles are scoped to a team or to the whole organization.
Project — a unit of ownership inside a team (often one project per service or repository).
Asset — concrete things (repositories, images, SBOMs, vendors, workloads) assigned to a project.

A user can belong to multiple teams and hold different roles in each.

Roles

Built-in roles:

Role	Scope	Permissions
Owner	Organization	Everything, including billing and deletion.
Admin	Organization	Everything except billing and tenant deletion.
Security Lead	Org or Team	Manage policies, exceptions, workflows, integrations.
Security Engineer	Org or Team	Triage and remediate findings; cannot modify policy.
Developer	Team	View findings on assigned assets; run auto-fix against them; request exceptions.
Auditor	Org	Read-only access to all audit records, findings, and compliance evidence.
Viewer	Any	Read-only access within scope.

Custom roles are composed from a permissions matrix:

apiVersion: safeguard.sh/v1
kind: Role
metadata:
  name: production-responder
spec:
  permissions:
    - findings:read
    - findings:triage
    - policies:evaluate
    - workflows:run
  restrictions:
    environments: ["production"]
    severity_max: "critical"

SSO

Safeguard supports:

SAML 2.0 — all major IdPs (Okta, Entra ID, Google Workspace, OneLogin, Duo, JumpCloud, PingID, Authentik, Keycloak).
OpenID Connect — any OIDC 1.0 provider.
SCIM 2.0 — automated user provisioning and deprovisioning.
Just-in-time provisioning — users are created on first SSO login with a default role you configure.

Enterprise tenants can require SSO for every login (no local passwords) and require re-authentication for sensitive actions (policy changes, approving exceptions).

MFA

WebAuthn / passkeys (preferred).
TOTP via authenticator apps.
Hardware security keys (FIDO2).
Phone/SMS MFA is disabled by default and not available in FedRAMP tenancies.

Policies can require a specific MFA level for specific actions (e.g., "promoting a self-heal to production requires a passkey re-auth").

API Keys and Tokens

Three credential types:

User API keys — bound to a user, inherit the user's role. Revoked if the user is deprovisioned.
Service tokens — bound to a service identity, used for CI / automation. Scoped to specific permissions.
Workload identities — OIDC-federated tokens from GitHub, GitLab, AWS, Azure, GCP. No long-lived secrets.

All tokens are short-lived by default (max 1 hour unless explicitly extended), and their usage is auditable.

Generate at Settings → API Keys or with:

safeguard tokens create --name ci-autofix --scope "workflows:run policies:read" --ttl 90d

Audit Log

Every action that mutates state is recorded:

Who (user, service, workload identity).
What (action + before/after where applicable).
When (UTC + timezone).
Where (IP, session ID, client type).
Why (linked ticket / PR / policy exception if provided).

Audit log is append-only, cryptographically chained, and retained for the period your tenancy allows (90 days default; up to 7 years configurable for Enterprise).

Audit streaming

Stream the audit log to your SIEM in real time via:

Webhook (JSON per event).
S3 with scheduled batch export.
OpenTelemetry logs.
Splunk HEC.

Approval Workflows

Sensitive actions can require multi-party approval:

Policy changes.
Large exception grants.
Production-impacting auto-fix merges.
Service-token creation.
Org-level configuration changes.

Configure under Settings → Approvals.

Break-Glass

Emergency access for incident response:

A break-glass role grants elevated permissions for a time-boxed window.
Break-glass invocations require two approvers and notify the entire security team.
Every break-glass action is separately labeled in the audit log and reviewed post-incident.

Per-Asset Permissions

Permissions can be sliced by asset labels:

- role: Security Engineer
  scope:
    labels:
      team: payments
      env: [production, staging]

Useful for consultants and contractors who should only see a specific service.

Deprovisioning

When a user is deprovisioned (SCIM or manual):

All sessions revoked.
All user API keys revoked.
All pending approvals reassigned to their team.
Actions they took remain in the audit log forever.

Web Application — SSO login flow.
Desktop Application — per-user system-access consent.
Organization Management — org-level configuration surface.
Compliance — how RBAC maps to compliance controls.

RBAC, Teams & Organizations

On this page