Cerbos and APIM separate authorization from application code

At a glance

What this is: This is a guide to enforcing authorization at the API gateway with Cerbos and Azure API Management, with the key finding that policy decisions can be centralised outside application code.

Why it matters: It matters because IAM teams need consistent authorization across services, clearer separation of duties, and a control point that can support NHI, autonomous, and human access patterns without reimplementing rules in every backend.

By the numbers:

• 11 tests executed [11 OK]

👉 Read Cerbos' guide to gateway-based authorization with APIM and Cerbos

Context

Authorization breaks down when every service reimplements its own rules, because policy drift, inconsistent role handling, and uneven claim checks are almost guaranteed. This article is about moving those decisions to the gateway and a dedicated policy engine, so the access model is defined once and enforced before requests hit backend code.

That matters for NHI and human IAM alike. For non-human workloads, centralised authorization helps separate identity validation from resource access decisions. For human users, it creates a cleaner path to combine role-based and attribute-based controls without scattering enforcement logic across application teams.

Key questions

Q: How should security teams implement gateway-based authorization for APIs?

A: Security teams should place the enforcement decision at the gateway, translate each request into a stable principal and resource model, and keep policy logic in a separate decision engine. That gives consistent enforcement across services and reduces code duplication. The key control is making sure the gateway passes complete identity context into policy evaluation.

Q: When does role-based access control need attribute-based rules at the API edge?

A: Role-based control is usually enough for broad access patterns such as read-only or authenticated access. Attribute-based rules become necessary when a role is too coarse, such as allowing a moderator to delete only specific review resources based on token claims. Use ABAC when the exception depends on identity attributes or request context, not just role membership.

Q: How do you know whether gateway authorization policies are actually working?

A: You know they are working when policy tests cover both allowed and denied scenarios, decision logs are captured, and changes can be released without breaking expected access. A healthy setup produces repeatable results for anonymous, authenticated, and privileged users. If those cases are not tested, the policy layer is effectively ungoverned.

Q: What is the difference between enforcing authorization in the gateway and in application code?

A: Gateway enforcement centralises access decisions before requests reach backend services, while application-code enforcement spreads those decisions across individual services. The gateway model reduces duplication and creates a single policy lifecycle. Application-code enforcement can still be useful for local business rules, but it is a weaker choice for shared authorization policy.

Technical breakdown

Gateway-enforced authorization with a policy decision point

The pattern uses Azure API Management as the policy enforcement point and Cerbos as the policy decision point. APIM receives the HTTP request, validates the token, translates request data into a structured authorization check, and sends that check to Cerbos. Cerbos evaluates YAML policy rules and returns an allow or deny decision. The important architectural shift is that the backend service no longer needs embedded authorization logic, so access policy is versioned and tested separately from application releases.

Practical implication: centralise enforcement at the gateway when you need consistent authorization logic across multiple APIs.

JWT validation, claims, and ABAC at the edge

This integration validates JWTs twice for different purposes. APIM verifies signature and expiry before forwarding the request context, while Cerbos can also inspect claims from the token for attribute-based rules. That lets policy distinguish between authenticated and anonymous users, and between ordinary authenticated users and users in a moderator group. The model combines RBAC and ABAC in one decision path, which is useful when simple role checks are not enough to express operational exceptions.

Practical implication: use claim-based rules only when the gateway can pass trusted identity attributes into the policy engine.

Policy versioning, testing, and runtime reloads

Cerbos supports policy files that can be tested, versioned, and reloaded without restarting the decision engine. In the example, the PDP watches the policy directory, and the test suite exercises eleven access scenarios covering authenticated, anonymous, and moderator cases. That matters because authorization failures often come from policy regressions rather than code defects. A separate policy lifecycle makes those regressions easier to detect before they affect production traffic.

Practical implication: put authorization policies under the same test discipline you already apply to application code.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Centralised authorization only works when identity context is faithfully translated at the gateway. This pattern makes APIM the enforcement layer, but the real control plane is the mapping from HTTP request to principal, resource, and action. If that mapping is incomplete or inconsistent, policy correctness is lost even when the policy engine itself is sound. The practitioner conclusion is that gateway-based authorization is a data quality problem as much as a policy problem.

Role-based access control and attribute-based access control should be treated as complementary, not competing. The example allows broad read and search access by role, then narrows review deletion using a JWT claim. That is a sensible pattern for mixed APIs because roles handle coarse entitlement while claims handle exception logic. The practitioner conclusion is to separate the two deliberately instead of forcing every access decision into a single model.

Policy-as-code changes the failure mode from hidden application logic to visible governance drift. Once authorization is externalised, the main risk becomes policy sprawl, stale versions, and untested edge cases. That is an improvement only if policy files, decision logs, and test fixtures are governed like production code. The practitioner conclusion is to make authorization changes observable, reviewable, and release-controlled.

API gateways are becoming the natural enforcement point for cross-actor identity decisions. The same control point can govern human users, service accounts, and AI-enabled callers if the principal and resource model is expressive enough. That makes gateway authorization a useful bridge between classic IAM, NHI governance, and future agentic access patterns. The practitioner conclusion is to design for actor-neutral policy evaluation rather than separate stacks for each caller type.

From our research:

• Cerbos policy evaluation typically completes in under 1ms, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records.
• That is why policy decisions need to stay separate from exposed credentials and backend code paths, as outlined in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Policy-based authorization is moving closer to the edge of the request path. That shift matters because the control point is no longer a backend library buried in service code, but a visible layer that can be tested, logged, and governed. The next step for practitioners is to treat gateway authorization as a shared platform capability, not an implementation detail hidden inside one team’s API.

Policy drift is the real operational risk once authorization is externalised. If policy files, JWT claim mapping, and deny handling are not governed together, the organisation simply relocates inconsistency from code to configuration. This is where the NIST Cybersecurity Framework 2.0 becomes useful, especially for aligning identify, protect, and detect activities around a single control plane.

Least privilege becomes easier to operationalise when the policy engine sits in front of both human and non-human callers. That creates a cleaner boundary for service accounts, bots, and future AI agents that consume APIs through the same gateway. As organisations expand automation, the access model has to distinguish caller type, request context, and policy version with far more precision than legacy app-level checks ever did.

For practitioners

• Map the gateway identity model carefully Translate each request into a stable principal, resource, and action before the policy engine evaluates it. Preserve the fields needed for role checks and claim checks, and make sure anonymous traffic is represented explicitly rather than implied by missing data.
• Separate validation from authorization decisions Use the gateway to verify token signature and expiry, then send the trusted identity context to the policy decision point for authorization. Do not mix token parsing, access logic, and backend business rules in the same place.
• Test policy paths like code paths Build policy tests for authenticated, anonymous, and claim-based cases, including deny scenarios. Keep a small fixture set that covers the access patterns your APIs actually expose, such as read, search, write, and privileged moderation.

Key takeaways

• Moving authorization to the gateway reduces duplicated access logic, but only if request-to-identity translation is precise and governed.
• Combining RBAC with ABAC at the edge lets teams express broad access rules and narrow exceptions without pushing policy into every service.
• Policy-as-code is only an improvement when policy testing, versioning, and audit logging are treated as production controls.

Key terms

• Policy Decision Point: A policy decision point is the system that evaluates identity, resource, and action data against policy and returns allow or deny. In this pattern, it sits outside the application so access logic can be changed, tested, and audited independently from service code.
• Policy Enforcement Point: A policy enforcement point is the component that intercepts a request, asks for an authorization decision, and blocks or forwards the traffic. In gateway architectures, it is usually the API gateway or proxy that sits in front of backend services and applies the decision immediately.
• Attribute-Based Access Control: Attribute-based access control decides access using attributes such as request path, HTTP method, token claims, or resource metadata. It is useful when roles alone are too broad, because the decision can depend on context, not just a static entitlement label.
• Policy as code: Policy as code means authorization rules are stored, versioned, and tested like software rather than hidden in manual configuration. That approach improves reviewability and rollback, but it only works when policy changes are governed with the same discipline as application releases.

Deepen your knowledge

Authorization policy design, gateway enforcement, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a shared access model for APIs, service accounts, and AI callers, it is worth exploring.

This post draws on content published by Cerbos: decoupling authorization from application code with Cerbos and Azure API Management. Read the original.