Permit Capabilities Checklist

Work through this checklist when you compare Permit.io with a homegrown authorization service or with another authorization vendor. Each row names the capability, what a homegrown service has to build for it, and the mechanism Permit uses. This page is for technical decision makers and architects who evaluate Permit.

Two terms appear throughout. A policy decision point (PDP) is the service that answers a permission check. An Edge PDP is a PDP you run yourself, as the container image permitio/pdp-v2 or as Permit Nexus PDP. The managed Cloud PDP is the PDP that Permit hosts. Some capabilities in this checklist require an Edge PDP, and the rows below say which. See PDP overview.

Checklist: Permit.io against a homegrown authorization service

Capability	What a homegrown service has to build	How Permit provides it
Policy modeling	A UI or config format, plus the code that turns it into enforcement logic	Policy Editor, API, SDKs, and Terraform, which generate Rego or Cedar. See Policy modeling.
RBAC, ReBAC, ABAC in one model	Three separate implementations, and the code that combines them per check	One policy model that covers all three. See Authorization models.
Policy rollout without a deployment	A config service, a cache invalidation path, and a reload mechanism in every service	OPAL pushes policy changes to every PDP. See Dynamic policy updates.
Authorization data sync	An ETL job or a shared database read on every check	OPAL pushes data updates to every PDP. See Event-driven data updates.
Decisions that survive a control-plane outage	A local cache per service and a fallback policy	PDPs hold policy and data locally. See Control plane and data plane.
Read-your-own-writes on a permission change	A write-through path from the permission write to every check path	Send Consistent Updates through an Edge PDP. See Data consistency and latency.
Queries beyond allow and deny	A query per question, written against your own schema	Endpoints for user permissions, authorized users, bulk check, and data filtering. See Authorization queries.
Decision and configuration audit trail	A log schema, a writer on every decision path, and a retention policy	Decision logs, activity logs, and API logs. See Compliance and audit.
Control over who may change policy	A second authorization model for your own admin tooling	Workspace roles scoped to a workspace, project, or environment. See Policy administration control.
An exit path	A rewrite	Open-source PDP, SDKs, and OPAL, with policy in your Git repository. See Open source and licensing.

The sections below give the mechanism behind each row.

Policy modeling in the UI, API, SDKs, and infrastructure as code

You define authorization rules in the Permit Policy Editor, the Permit API, an SDK, or the Terraform provider. Permit generates policy code from that configuration, in Rego for Open Policy Agent (OPA) or in Cedar for Cedar-agent. See Policy engines in Permit for the two engines and their agents, and policy code generated by Permit for an example of the generated Rego.

With GitOps, the generated policy lives in your Git repository, so you can version, review, and automate policy changes.

Support for multiple authorization models

Model	How Permit grants access
Role-based access control (RBAC)	Through the roles assigned to a user
Relationship-based access control (ReBAC)	Through relationships between users and resource instances
Attribute-based access control (ABAC)	Through user, resource, and environment attributes. Requires an Edge PDP, because the managed Cloud PDP doesn't evaluate ABAC. See Build an ABAC policy and Cloud PDP capabilities.
Custom policy as code	Through Rego or Cedar code you write and manage in Git. See Write custom policy with GitOps.

Dynamic policy updates

Permit pushes policy updates to your PDPs through the Open Policy Administration Layer (OPAL), an open-source project maintained by Permit. OPAL is event-driven: a policy change reaches every PDP without an application restart or a manual step.

Event-driven data updates

OPAL also syncs the data your policies need. You define data sources centrally, and OPAL pushes updates to every PDP. Each PDP then evaluates checks locally against that data.

Stateful or stateless data

Choose how your PDPs get authorization data:

• Stateless: pass the data as part of the permission check input.
• Stateful: sync data into Permit ahead of time, so the PDP evaluates checks against preloaded data. See Load data into Permit.

Data plane separated from the control plane

Permit separates the control plane, where you manage policy in Permit's cloud, from the data plane, where PDPs make decisions inside your network. Your data can stay in your network, and you scale PDPs with your services. See Control & Data planes.

Custom data model and schema

Define your own authorization data model:

• Resources, roles, and custom attributes, including resource hierarchies.
• Data synced from identity providers and databases.

See Load data into Permit and Build an ABAC policy.

Data consistency and low latency

The hybrid architecture gives you local decisions and a choice of consistency guarantees:

• Local decisions: PDPs run next to your services and evaluate checks without a round trip to Permit's cloud. A sidecar Edge PDP on the same host receives checks over the loopback interface, so there is no network latency. A PDP handles thousands of checks per second at sub-millisecond latency, and responds in under 10 ms at p95 from your application.
• Eventual consistency: OPAL pushes data updates to every Edge PDP as events occur.
• Read-your-own-writes: Send Consistent Updates through an Edge PDP, and the PDP waits for the update to apply before it responds.
• Data update callbacks: an Edge PDP calls your endpoints when its data changes. See PDP_DATA_UPDATE_CALLBACKS.

Advanced authorization queries

Permit answers more than yes or no:

Question	Page
Can this user perform this action on this resource?	Check permissions
Which features can this user see in the frontend?	Feature flagging with CASL
Which resources can this user access?	Get user permissions
Which of several actions can this user perform?	Bulk check
Which records should a query return for this user?	Data filtering

Open source and licensing

• The PDP, the Permit SDKs, and OPAL are open-source projects you can inspect and self-host.
• With GitOps, your policy lives in your own Git repository.
• See Open-source fallback for how to move to a self-managed stack.

Compliance, audit, and security

Permit records who changed what, and why each decision was made:

• Decision logs: a log entry for every authorization decision, with the data that explains the decision. See Audit log types and filtering.
• Activity logs: changes to your authorization configuration. See Permit logs.
• API logs: calls to the Permit API. See Permit logs.
• SOC 2 Type II attested: Permit.io holds a SOC 2 Type II attestation covering security, availability, and confidentiality. The report is available under NDA.
• HIPAA compliant: Permit.io meets HIPAA requirements. You can also keep protected health information out of the control plane by running PDPs in your own network and passing opaque identifiers.

Authorization for authorization

Changing a policy is itself a privileged action, so Permit applies authorization to policy administration. Each member of your Permit workspace holds a workspace role (Workspace Owner, Workspace Editor, or Workspace Viewer), or a role scoped to one project or one environment, which decides whether that member can read or change policy there. See Member management.

To delegate a narrower slice of policy administration to people outside your Permit workspace, such as your customers' own admins, embed Permit Elements instead of granting workspace roles.

Telemetry and observability

• Datadog APM tracing for the Edge PDP: set PDP_ENABLE_MONITORING.
• PDP monitoring: see Monitoring PDPs.

Backup and versioning

• Git-backed policies: with GitOps, every policy change is a commit in your Git repository, so you can audit and roll back policy.

Next steps

• PDP overview to choose between the managed Cloud PDP, an Edge PDP, and Nexus PDP
• Control & Data planes for the architecture behind local decisions
• Open-source fallback for the exit path to a self-managed stack