Authorization Management Platforms: what they do, how they work, and where they fit

Every few years the IAM industry names a category it's been quietly building toward for a decade, and the name suddenly starts showing up on every roadmap. IGA was one of those. ITDR was another. The latest is the Authorization Management Platform, or AMP, and it sits in the space that IGA and access management have never quite filled.

If you've ever watched a team try to answer "can this user do this thing on this resource right now" by grepping through three microservices, two YAML configs, and an access request ticket from 2022, you've seen why this category exists. Authorization has been sprawled across application code, identity provider role claims, database grants, and OAuth scopes for years. AMPs are the answer the industry has converged on for cleaning that up.

I will be covering what an Authorization Management Platform actually is, the PAP/PDP/PEP/PIP/POP architecture that sits underneath it, the three integration modes AMPs typically support, where they fit alongside IGA and PAM, and what separates the ones that work from the ones that become shelfware.

 

The problem AMPs were created to solve

Authorization inside most enterprises is in a rough state. OWASP's 2025 Top 10 still lists broken access control as the number one web application risk, and has since 2021. It's also the failure mode that turns a bad day into a breach, because once an attacker or a misconfigured service gets past authentication, the blast radius is defined by how tightly authorization holds.

The underlying issue is that authorization logic has never had a natural owner. IGA handles the provisioning side, deciding who is granted what at admin time through workflows, certifications, and role management. Access management owns authentication, session rules, and coarse-grained app-level access. Neither of them gets near the fine-grained, context-aware decisions that services have to make at runtime.

So runtime authorization gets written into the applications themselves. Every team ends up with its own if user.role == "admin" logic, its own policy YAML, its own database of permissions, its own audit log format, and its own way of saying "the product team owns that." When the business grows, so does the mess. When compliance asks "who can see customer X's data and why," the answer requires a code review across services.

This is the gap the AMP category addresses. IGA handles the static grants. Access management handles the login layer. AMPs handle the runtime decision.

 

What an Authorization Management Platform is

An Authorization Management Platform is the system that centralises how authorization policies are authored, versioned, distributed, orchestrated and evaluated across every application and service in your stack. Industry analysts covering the IAM market describe it as the platform that manages authorization across diverse systems and applications, filling the gap between coarse access management and static identity governance.

The category is young enough that the vendor landscape is still sorting itself out, but the architectural pattern is well-defined. An AMP centralises intent (the policy) and externalises execution (the decision), so every service in your stack asks the same component the same question in the same way, and gets a consistent, auditable answer.

That centralisation is not about funnelling every request through one machine. A modern AMP is centralised at the control plane (where policies live and are managed) and decentralised at the data plane (where decisions actually happen and orchestrated across systems), so that authorization latency stays sub-millisecond even when a policy applies to millions of requests per second.

 

The AMP architecture: PAP, PDP, PEP, PIP, POP

The shape of the platform comes from four component types that have been part of access control reference architecture for over a decade, originating in XACML and formalised across modern frameworks. If you've seen a Gartner IAM deck in the last two years, you've seen these four letters.

Policy Administration Point (PAP). This is where policies are authored, tested, versioned, reviewed, and deployed. In a working AMP, the PAP looks more like a developer tool than a GUI. Policies are treated as code, stored in Git, reviewed in pull requests, tested in CI, and released through controlled promotion pipelines. The PAP is what gives security and engineering teams a shared language for access rules without dragging both into a wiki page.

Policy Decision Point (PDP). This is the runtime engine. The PDP takes a request (who, what, on which resource, under what context) and returns a decision in milliseconds. It's where authorization actually happens. Modern PDPs are stateless, horizontally scalable, and deployed close to the workloads that call them, which is how authorization scales without becoming a latency tax.

Policy Enforcement Point (PEP). This is the component inside the calling system that actually enforces the decision. In a web app, it's the middleware that blocks the request. In an API gateway, it's the filter that rejects the call. In a data platform, it's the row-level filter that strips unauthorised rows. The PEP asks the PDP the question. The PDP returns the answer. The PEP does what the answer says.

Policy Information Point (PIP). This is where live context comes from. Policies rarely reduce to "does this user have this role." They ask "is this user in a team that owns this resource, during business hours, from a managed device, with the transaction amount under their approved limit." The PIP is where those attributes and relationships get pulled from, in real time, from identity providers, databases, or application state.

Policy Orchestration Point (POP). This is where decisions can be federated out to other replying systems - such as plugging a PDP into an existing authorization layer inside of an API Gateway, IdP, databases or even into cloud environments - augmenting existing capabilities. The key here is when the PAP changes the policies, the changes are orchestrated out into systems other than those with a native PEP calling the PDP.

A working AMP ties all four together so that policy authors don't hand-wire context lookups, security teams don't audit application code, and engineering teams don't build their own authorization plumbing for every new service.

 

Three integration modes

AMPs show up in an enterprise in one of three ways, and serious platforms support more than one.

The first is full externalized authorization. The AMP evaluates policies, the relying system enforces the decision, and the application itself contains no authorization logic beyond the call to the PDP. This is the mode most greenfield services adopt, because it keeps the application clean and gives the security team a single place to review and change access rules.

The second is policy orchestration. The AMP owns policy authoring and distribution, then pushes those policies out to enforcement components that live inside existing systems (database access control, API gateway rules, workload mesh filters). This mode is common when you need to govern systems you don't own or can't easily change.

The third is token-facilitated authorization, where the AMP enriches tokens issued by the identity provider with authorization claims that downstream services can honour. This is typically the right mode for federated and partner scenarios, less useful for fine-grained in-app decisions.

Most real deployments blend the three. Greenfield services go straight to externalized authorization, legacy and infrastructure systems get policy orchestration, and partner federation uses token-facilitated flows.

 

Where AMPs fit alongside IGA, PAM, ITDR, and AM

The clearest way to think about AMPs is as a peer category to IGA, PAM, access management, and ITDR, not a replacement for any of them. They solve different parts of the identity problem, and a mature 2026 IAM program uses all of them together.

IGA handles the admin-time picture. Who is provisioned, who gets approved, who gets certified. PAM handles the accounts with the most blast radius, pushing toward zero standing privilege and just-in-time access. Access management handles authentication and session-level rules. ITDR watches the whole stack for signs of identity compromise.

AMPs handle the runtime question. Given everything the rest of the stack has decided about this principal, can this specific action on this specific resource go ahead right now, with this current context. They take inputs from IGA (what roles and entitlements exist), access management (who is authenticated), PAM (whether this session has elevated privilege), and PIPs (live context), and turn all of that into a real-time decision.

The identity fabric architecture most teams are building toward needs each of these layers, with open standards tying them together.

 

Why AMPs are getting attention now

The timing is not an accident. Three shifts converged in the last eighteen months and pushed authorization from "someone's problem" to "everyone's priority."

The first is AI agents. Enterprise agent adoption is moving fast. Gartner forecasts that 40% of enterprise applications will feature task-specific AI agents by 2026, up from less than 5% in 2025, and the same analyst firm expects that over 40% of agentic AI projects will be canceled by the end of 2027, largely due to unresolved identity and authorization problems. Agents act on behalf of humans, call tools that call other tools, and create delegation chains that role-based access can't express. They need policy evaluation, not role claims.

The second is the shape of modern attacks. The Verizon 2025 Data Breach Investigations Report found that 88% of basic web application attacks involved stolen credentials, and credential abuse has been the top initial access pattern five years in a row. Once an attacker is authenticated as a legitimate user, the only thing standing between them and the data is authorization. If authorization is coarse-grained and overprovisioned, there's nothing standing there at all. Gartner has said more than 95% of identities use less than 3% of their granted entitlements, which is a long way of saying standing authorization is the real attack surface.

The third is workload identity. Service accounts, workloads, and non-human identities now outnumber human identities in most enterprises by a wide margin, and most of them are granted permissions that are too broad and never reviewed. Authorization for non-human identities is not a role problem, it's a policy problem, and it needs a PDP to evaluate it.

All three point at the same gap, which is why the AMP category has gone from theoretical to urgent.

 

What good looks like

Not every platform that claims to be an AMP is one. A few characteristics separate the ones that actually work from the ones that turn into yet another shelfware layer.

Open standards, not proprietary lock-in. The AuthZEN specification, ratified by the OpenID Foundation in 2026, is becoming the lingua franca between PDPs and PEPs. An AMP that commits to AuthZEN is an AMP you can integrate with, without tying every service in your stack to a single vendor.

Policies as code. Authorization rules belong in version control, reviewed in pull requests, tested in CI, and deployed through the same pipelines as application code. A platform that requires a GUI admin to author policies is a platform that will end up out of sync with the services it governs.

Fine-grained, not just role-based. RBAC is a starting point, not a finished model. A working AMP supports attribute-based and policy-based access control, relationship-based rules for resource hierarchies, and the ability to express conditions over live data, not just static group memberships.

Data integration that doesn't require adapters. The PIP is only useful if it can pull from the identity providers, databases, and APIs you already run. A modern AMP ships with connectors to the big IdPs (Okta, Entra ID, Auth0, Keycloak, AWS Cognito) and speaks the languages of the infrastructure that actually needs authorization (API gateways, service meshes, data platforms, Kubernetes).

Observability built in. Every decision the PDP makes is a security event. If the platform isn't producing structured, queryable, compliance-ready audit logs by default, it's not a security tool, it's a function call. Audit trails are how AMPs feed ITDR, satisfy regulators, and let incident response actually do its job.

Deployment that matches your architecture. Self-hosted PDPs for teams that need data residency. Managed control planes for teams that don't want to run the PAP themselves. Stateless decision engines that sit next to the workloads they govern. A platform that insists on calling home for every decision is a platform that will fail your latency SLOs on day one.

 

Build vs buy

Most teams consider building their own authorization layer before they buy. A few actually try it. Industry analysts have written about the risks enough times that the list is by now standard.

Development and maintenance costs run higher than expected, because authorization logic interacts with every other part of the system and changes as the business changes. Coding bugs in homegrown authorization are directly exploitable by attackers, which is why broken access control has stayed at the top of the OWASP list. Regulatory requirements (SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR) all expect auditable access control, and producing that out of custom code is an ongoing tax. There's no community support, no shared body of patterns, and no easy way to hire for the expertise. Time to market on every new feature goes up, because every new service needs its own authorization plumbing before it ships.

The build case makes sense for a small number of organisations. For most, the maths has shifted.

For a full breakdown of the build vs. buy question, refer to this blog.

 

Where Cerbos fits

The AMP category is still crystallising, but the reference architecture is now clear enough that you can evaluate any platform against it. Cerbos is built directly to this pattern.

Cerbos PDP is an open-source, stateless, horizontally scalable decision engine. It runs wherever the workloads that call it run. Containers, Kubernetes, edge, on-prem. It handles millions of authorization checks per second with sub-millisecond decision latency, and it evaluates policies written in YAML with CEL for conditions. Policies live in Git, go through code review, run in CI with coverage reports, and deploy through controlled pipelines.

Cerbos Hub is the PAP. It handles policy authoring, testing, versioning, distribution to every PDP instance (without restarts), and compliance-ready audit logs that meet SOC 2, ISO 27001, HIPAA, PCI DSS, and GDPR requirements. Engineering teams get a policy playground with coverage reports and breaking-change detection. Security teams get a single pane for reviewing and auditing every rule.

Cerbos Synapse is the PIP layer plus protocol translation for orchestration (POP). It pulls identity attributes and relationship data from Okta, Entra ID, Auth0, Keycloak, AWS Cognito, LDAP, and custom databases at decision time, so policies evaluate against live context. It also translates native protocols for Envoy, Kafka, Trino, and Kubernetes into policy checks, which means the same policies govern both application-level and infrastructure-level authorization. For AI agents, Cerbos evaluates both the agent and the delegating human in a single policy call, and ships a Claude Code hook handler that intercepts agent tool calls before execution.

Every Cerbos PDP is AuthZEN-compliant, which keeps PEP integrations portable across the stack. The audit log from every decision is structured, queryable, and ready to feed into ITDR and compliance workflows.

Cerbos slots into an existing identity fabric as the runtime authorization layer, without asking you to rip out your IdP, your IGA tool, or your PAM solution. IGA still handles provisioning. PAM still handles privileged accounts. Access management still handles authentication. Cerbos handles the allow-or-deny decision that all of them ultimately depend on.

 

The takeaway

Authorization Management Platforms exist because IGA, access management, and PAM don't cover the runtime decision layer, and the gap has become too expensive to keep patching with hand-rolled code. The category is now well-defined, the PAP/PDP/PEP/PIP architecture is the reference shape, and the integration modes are settled. What's left is picking the platform that fits your stack and your compliance requirements, and migrating to it incrementally.

If you're building or rethinking authorization this year, AMPs are the layer worth architecting around first, because every other part of identity security (ITDR, ISPM, compliance, agent governance) depends on the decision it produces.

---

 

Try Cerbos to see how an AMP works in practice against your own policies, or book a call to talk through how it fits into your identity stack.

Go deeper:

• How to adopt externalized authorization (eBook) for a step-by-step playbook on decoupling authorization from application code.
• Guide to layered security that holds up under pressure (Webinar) for a walkthrough of the six layers of Zero Trust defense, and a practical way to implement them in your organization.