Skip to main content
Version: Latest

Security, compliance, and operations

This page addresses the questions that come up during a security review or vendor risk assessment: what you are responsible for, what we are responsible for, how your data is protected, and what standards keep you portable.

Delivery model​

PBAC is delivered as a managed service. Here is what that means in practice.

What you get:

  • A running PBAC instance with your own admin credentials and API keys
  • A managed OPA sidecar that evaluates your policies
  • A managed database for policy rules, policy data, and audit logs
  • Customer-facing documentation and integration guides
  • Admin UI and REST API for managing identity providers, clients, resource servers, resource types, resources, subjects, policies, and audit

What you do not manage:

  • Infrastructure provisioning, scaling, or monitoring
  • OPA deployment, configuration, or upgrades
  • Database administration, backups, or migrations
  • Security patching and version upgrades

Your team focuses on defining policies and integrating applications. We operate the infrastructure that enforces them.

Standards & portability​

Every protocol PBAC implements is an open standard. Every policy you write is portable.

  • OAuth 2.0 and OIDC — Authorization code, client credentials, refresh token, token exchange (RFC 8693), resource indicators (RFC 8707), rich authorization requests (RFC 9396), dynamic client registration (RFC 7591), and OpenID Connect Core 1.0 with Discovery.
  • UMA 2.0 — User-Managed Access for delegated, consent-based authorization across organizational boundaries.
  • AuthZEN — Direct policy evaluation via the /access/v1/evaluation endpoint for applications that need a decision API without an OAuth token flow.
  • OPA Rego — Policies are written in Rego, the policy language for Open Policy Agent. Rego is open source, widely adopted, and not proprietary to PBAC. Your policies are yours.
  • JSON policy data — All policy data is stored as JSON. It is exportable, versionable, and readable by any tool that understands JSON.

No proprietary policy language. No vendor-specific data format. If you leave PBAC, your policies and data come with you.

Security​

PBAC enforces defense in depth across its API surface, credential storage, and external integrations.

  • Admin API protected by API key (X-Admin-API-Key header) — separate from all other credentials
  • Bundle endpoint protected by a separate API key (X-Bundle-API-Key header) — isolated from admin access
  • Client secrets stored with BCrypt hashing — never stored in plaintext
  • Software statement JWT signature verification is supported and configurable for dynamic client registration
  • HTTPS enforced for all external-facing endpoints in production
  • JWKS URI validation requires HTTPS to prevent SSRF attacks against internal networks
  • Token introspection callers must authenticate with a Bearer token carrying the appropriate scope, or with Basic auth
  • OAuth 2.1 hardening applied by default: implicit and ROPC grants removed, PKCE required for public clients, exact redirect URI matching enforced
  • DPoP token binding (RFC 9449) sender-constrains access tokens to the client's private key, preventing replay of stolen tokens. DPoP-bound tokens carry a cnf.jkt claim containing the public key thumbprint; every API call must be accompanied by a fresh proof signed with the matching key. This is especially relevant for agentic workflows where tokens may pass through multiple services or be stored in memory — without the private key, a captured token cannot be replayed.

Compliance & audit​

Every access decision PBAC makes is logged with full context:

  • Subject — who requested access
  • Resource — what they requested access to
  • Action — what they wanted to do
  • Client — which application made the request
  • Policy outcome — allow or deny, and which policy produced the decision
  • Obligations — any conditions attached to the decision (consent requirements, scope restrictions, time bounds)
  • Timestamp — when the decision was made

The audit trail is append-only and queryable via the Admin API. It is not a bolted-on feature — audit is part of the core architecture.

Standards compliance provides regulatory defensibility. When an auditor asks how access decisions are made, the answer is documented in public specifications, not proprietary logic.

SLA, data residency & certifications​

Contact us for details on:

  • Service Level Agreements and uptime commitments
  • Data residency options
  • SOC 2 and other compliance certifications
  • Incident response procedures

These are business commitments that vary by deployment. We will work with your security team to provide the specifics your risk assessment requires.

Request details →

Next steps​

  • Start Here — From sign-in to a live policy decision in five steps