3366 Members
Join Permit's SlackQuick answer: The four pillars (enforcement, granularity, realtime, audit) are a checklist for production application authorization: every sensitive action asks for a decision, rules fit real tenants and resources, revocation takes effect fast, and decisions are explainable. Use them for multi-tenant SaaS and AI agents. Skip the full stack for small internal tools with one or two static roles.
Production application authorization requires four things: enforcement at every sensitive action, fine-grained decisions over tenants/resources/actions/relationships/attributes, realtime policy and data sync for fast revocation, and audit logs that explain who was allowed or denied, on what, by which policy, and why.
Most teams do not fail at authorization because they forgot to create roles. They fail because authorization becomes implicit, scattered, stale, or impossible to prove.
A role check in one controller is not production AuthZ. A feature flag pretending to be entitlement logic is not production AuthZ. A permissions table that updates eventually, but not before a terminated user exports data, is not production AuthZ. And a log line that says "403" without the evaluated policy is not evidence.
Modern SaaS authorization is no longer "can this user enter the app?" It is "can this principal perform this action, on this resource, in this tenant, under these conditions, right now, and can we explain the decision later?"
That is why I frame production-grade application authorization through four pillars:
If any one is missing, the system may look secure in a diagram but fail in production. This is also why teams should stop rebuilding permissions separately inside every service and product surface.
Authorization enforcement means placing a Policy Enforcement Point, or PEP, anywhere sensitive impact can happen. The PEP asks: "Is this subject allowed to perform this action on this resource right now?" It should not contain all policy logic. Its job is to ask. The Policy Decision Point, or PDP, decides.
Authentication answers "who are you?" Authorization answers "what can you do?" A valid session proves identity. It does not prove permission. An authenticated user may still be blocked from inviting users, exporting reports, updating billing, approving a workflow, reading a shared document, calling an internal API, or triggering an AI agent tool.
"We checked at login" is not enough. Permissions change during a session. Users switch tenants. Resources change state. Support windows expire. Relationships are added or removed. Policies are updated. If enforcement happens only once, your authorization state is frozen at the wrong point in time.
APIs are the obvious surface. Every endpoint that reads, writes, deletes, exports, approves, invites, impersonates, or administers should have a PEP, and that PEP should pass enough context: subject, action, resource, tenant, attributes, and relationships.
A weak check looks like this:
if user.role == "admin" allow
A production authorization question looks like this:
Can subject U perform action A on resource R in tenant T with context C?
That difference matters. Route-level roles often ignore tenant scope, ownership, support access, delegation, data residency, and resource state.
The UI is also an enforcement surface (not as the final security boundary, but as an entitlement layer). Hiding "Export" does not secure the API, but the UI should still ask the same authorization system so users see the actions they are actually allowed to take.
Data queries need enforcement too. Many AuthZ bugs happen after the route handler: a list endpoint checks "can read projects" but forgets tenant filtering; a report joins across customers; a search index returns resources the caller cannot access. For multi-tenant SaaS, every query touching tenant-scoped data is sensitive.
AI agents add another surface. Each tool call is an action with impact. "The user can access the agent" is not enough. The agent must ask before executing sensitive tools.
For the deeper pattern, see PEP/PDP architecture.
Your model must express what the business actually needs to secure. Too coarse, and you over-permit. Too complex, and nobody understands the policy. The goal is the simplest model that correctly represents your product's access boundaries.
In multi-tenant SaaS, the first serious boundary is usually tenant scope. A user can be an owner in Tenant A, a viewer in Tenant B, and have no access to Tenant C. If role assignment is global when the product is tenant-scoped, you will eventually leak privilege.
Actions matter just as much. "Admin" is often too broad. Break access into verbs that map to product impact: project.read, report.export, billing.manage, user.invite, workflow.approve. You do not need thousands of permissions on day one. You do need enough separation that dangerous actions are not bundled casually with harmless ones.
Resource scope becomes important when access differs inside a tenant: one project but not another, one document shared with a group, one workflow step assigned to a reviewer. Then the question is no longer "is this user an admin?" It is "can this subject take this action on this resource?"
There is no single authorization model that is always correct.
RBAC works well when permissions map to job function or tenant role: owner, admin, member, viewer. It is understandable and often the right starting point.
ABAC is useful when decisions depend on properties: tenant plan, region, classification, environment, session state, or time window (for example, support access only during an approved support session).
ReBAC is needed when access follows relationships: owner of, assigned to, member of, shared with, parent folder contains document.
Most production systems combine these. A tenant role may grant broad permissions. Document sharing may need ReBAC. Data residency may need ABAC. Billing entitlements may depend on plan attributes.
Permit supports RBAC, ABAC, and ReBAC, with policy engines including OPA and Cedar. The architectural point is not the acronym, but that your authorization layer should support the product you are becoming, not only the MVP you started with.
For model selection, see FGA models: RBAC, ABAC, and ReBAC and Models to least privilege evidence. Policy basics: Policy basics.
Authorization depends on policy and data. Both change. Policies change when you modify roles, permissions, conditions, or relationship rules. Authorization data changes when users are added to tenants, removed from groups, assigned to projects, granted temporary access, or offboarded.
If those changes do not reach the decision point quickly, you have stale authorization, and stale authorization is a security bug.
Revocation is the clearest test. An employee leaves. A contractor's project ends. A customer admin removes a user. A support session expires. A compromised service account is disabled. A sensitive document is unshared. How long can the old permission continue to work?
If the answer is "until the cache expires in 30 minutes," decide whether that is acceptable for the action. For a low-risk UI hint, maybe. For exporting data, deleting records, changing billing, or calling admin APIs, probably not.
Caching is not the enemy. Local decisions often require it for latency and resilience. The problem is unmanaged staleness. Production AuthZ needs a way to keep local decision points current.
OPAL (Open Policy Administration Layer) distributes policy and authorization data updates to PDPs in near real time. Instead of every service polling a database and hoping its cache is fresh, updates propagate to local decision points.
Permit uses this pattern. The control plane manages policy and configuration. The data plane, including local PDPs, makes decisions close to the application. See Control plane and data plane and How Permit works.
Externalizing authorization should not mean every API request depends on a remote SaaS call. The better pattern is hybrid: manage policy centrally, distribute policy and data, run a PDP near the app, have PEPs call the local PDP, and log decisions. That gives low latency, resilience, and data minimization while keeping policy centrally governed.
Realtime does not remove the need for review, testing, environment separation, or staged rollout. It means approved changes and revocations propagate fast enough to trust.
If authorization is a security control, you need evidence that the control worked: decision records, not just "a request failed" or "a user clicked something."
A useful decision log answers who made the request (user, service account, agent, workload); what action was attempted; which resource and scope applied; allow or deny; which policy contributed; why the decision was made; and where enforcement happened.
Without this, incident response becomes archaeology. A customer asks why a user could not access a report. Security asks why a terminated user still had access. Engineering asks which policy change caused denials. "HTTP 403" does not answer those questions.
Basic audit logs record administrative and configuration activity: policy changes, user management, role assignments, environment changes. They tell you what changed.
Decision logs record runtime authorization outcomes. They tell you what happened when the application asked for permission.
Both matter. If access was unexpectedly allowed, reconstruct the chain: Was a role assigned? Was a relationship created? Did a policy change? Which runtime decision allowed the action? What reason did the PDP return?
Permit provides both, including human-readable decision reasons. See Audit log types and filtering.
Audit is not only for compliance. Support uses logs to resolve access tickets. Engineering uses them to debug policies. Security uses them to investigate suspicious behavior. Good logs reduce risky shortcuts: if the reason says "denied because user lacks report.export in tenant acme," the fix can be precise.
For more on explainable denials and authorization logs, see SOC 2 and explainable deny and Why was this allowed? Authorization logs.
The four pillars come together in one architecture:
control plane → OPAL → PDP → PEP → logs
Control plane manages authorization state: policies, roles, permissions, ABAC conditions, ReBAC relationship models, tenants, environments, and configuration. It should not sit in the hot path of every production request.
OPAL distributes policy and authorization data updates to the PDPs that need them. When a policy, assignment, relationship, or attribute changes, OPAL propagates that state in near real time, bridging centralized governance and distributed enforcement.
PDP evaluates:
Can subject U perform action A on resource R in context C?
It returns allow/deny, a reason, and metadata. In a hybrid PDP model, this happens near the application, with low latency, resilience, and privacy benefits while preserving central policy management.
PEP enforces the result in API middleware, route handlers, service methods, GraphQL resolvers, background jobs, data access layers, frontend entitlement checks, or AI agent tool routers. If allowed, the action proceeds. If denied, it stops or follows a controlled path such as request-access or approval.
Logs close the loop. Administrative logs show what changed. Decision logs show what happened at runtime. Together they answer what policy was active, what decision was made, why, and whether enforcement existed at the sensitive action.
PDP setup context: Connecting your app.
Two forces are making authorization architecture more important: AI agents and regulatory pressure.
AI agents introduce new execution paths. A traditional UI exposes buttons and forms. An agent exposes intent, and behind each instruction may be multiple tool calls. That stresses every pillar. Enforcement must happen per tool call, not only when the user opens the agent. Granularity must distinguish read from export, draft from send, suggest from approve. Realtime matters because agent sessions can be long-running; revoked access should affect future tool calls. Audit matters because you need to reconstruct what the agent did, on whose behalf, with which decision, and why.
Regulators and auditors stress the same pillars from another direction. DORA, NIST-oriented controls, and SOC 2-style evidence do not care that your diagram has a box labeled "authorization." They care whether access is controlled, least privilege is enforced, changes are governed, and evidence exists. More on that in DORA, NIST, and access control.
NIST's control catalog states the enforcement pillar in one sentence (control AC-3, Access Enforcement):
Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
The other three pillars are how you keep that sentence true over time: fine-grained rules, fast revocation, and logs that show which policy decided.
Buying a tool does not automatically make a company compliant. Permit holds a SOC 2 Type II attestation covering Security, Availability, and Confidentiality (see the Trust Center), and we build for teams in regulated environments, but compliance depends on your implementation, governance, and controls. The architecture gives you an evidence layer; your organization still owns the program.
Upcoming posts will go deeper on agent authorization patterns and evidence-driven access control; both trends push application AuthZ out of "permissions table" territory and into core platform architecture.
Permit is built around this production model: policy models, local decisions, realtime sync, enforcement patterns, and auditability.
Useful docs: How Permit works, Control plane and data plane, Audit log types and filtering.
If you are building multi-tenant SaaS, start with one real flow (invite user, export report, share document, approve workflow, or agent tool call) and trace it through control plane → OPAL → PDP → PEP → logs. Ask: Is enforcement present? Is the decision granular enough? Can revocation reach the PDP quickly? Can we explain the allow or deny later?
If the answer is yes, you are designing authorization like a production system. If not, tighten the model, move decisions into a real PDP, sync policy and data in realtime, and make every decision auditable.
Start in the docs, try Permit in a small service, or talk to us about your authorization model. Bring one real use case. The architecture will reveal the gaps quickly.
Co-Founder / CEO at Permit.io
