Your infrastructure.
Your users. Your keys.

OIDC with PKCE handles sign-in. SCIM 2.0 can manage user and group lifecycle. Effective OpsKnight permissions still come from the role and scope applied after identity mapping.

• Pilot allowed, denied, deactivated, and existing-account paths.
• Verify effective RBAC after provisioning or group changes.
• Preserve a tested break-glass access path before enforcing SSO-only policy.

Sensitive configuration is stored with authenticated AES-256-GCM encryption. Key rotation and recovery are operational responsibilities: encryption keys must be preserved outside database backups and restored with the data that depends on them.

• Use high-entropy session and encryption keys.
• Rotate through the documented keyring procedure.
• Test restore with the required keys before relying on backup recovery.

Admin, responder, user, and auditor behavior should be validated against the resources each role can actually read or change. Session revocation and audit events provide evidence for access reviews; they do not replace your wider compliance program.

• Test the dedicated Auditor role as read-only evidence access.
• Revoke active sessions when identity or access changes require it.
• Export and retain evidence according to your own policy.

OpsKnight does not require a vendor-hosted incident control plane, but enabled features can call systems outside the application network. Put PostgreSQL behind private network controls, terminate HTTPS at the supported edge, and allow outbound traffic only to providers your deployment actually uses.

• Inventory identity, notification, ChatOps, webhook, and observability destinations.
• Keep platform and PostgreSQL telemetry under operator control; any external observability exporter is an explicit outbound trust boundary.
• Restrict database exposure and review proxy/TLS boundaries.
• Verify provider failures and rate limits without weakening critical-response traffic.