Permission / policy engine

One service that answers 'may this user do this to that resource?' so every API follows the same permission rules.

one place that decides who can do whatcentral permissions serviceask whether this user may edit this recordstop copying access checks into every endpointwho is allowed to press this buttoncan user do action APIpolicy decision pointpermision engine

See it

Live demo coming soon

What it is

A permission or policy engine is the centralized decision-maker for authorization. Code sends it a subject, action, resource, and context, and gets back allow or deny, sometimes with a reason. Open Policy Agent, Amazon Verified Permissions, and SpiceDB cover different policy models, but all separate the decision from the endpoint enforcing it.

Reach for one when several APIs, workers, and products must obey the same rules, or when RBAC conditionals have spread through the codebase. Keep enforcement at every data boundary: the engine answers the question, but the API still has to ask before reading or mutating the resource.

The gotcha is moving a critical check behind a slow or unavailable network call. Define fail-closed behavior, cache only decisions whose inputs and policy version are part of the key, and support batch or list authorization so pages do not make one remote call per row. Central policy without complete enforcement is only centralized hope.

Ask AI for it

Build a centralized permission engine with Open Policy Agent running as a sidecar. Expose one authorize(subject, action, resource, context) adapter in the application, send structured JSON input to versioned Rego policies, deny by default, and return allow, reason code, policy version, and OPA decision ID. Enforce the adapter before every protected read and write, add a batch authorization method for list pages, and fail closed when OPA is unavailable. Cache only decisions keyed by all inputs plus policy version, emit decision logs with sensitive fields redacted, and add contract tests proving the REST API and background worker reach the same answer for RBAC and attribute-based rules.

You might have meant

role based access controlattribute based access controlrelationship based access controlauth guard protected routeauthentication vs authorization