One decision authority
UI, API, backend, search, and agent enforcement points share the same logical ABAC authority—through OpenID AuthZEN interfaces to a governed PDP fabric.
Identity Fabric · Decision plane
AvailableGoverned Authorization
One logical ABAC decision authority for applications, data, and AI agents—fed by relationship intelligence, enforced everywhere, explainable to anyone.
Fragmented authorization truth
Roles live in directories. Relationships determine real scope but rarely reach the decision point. Enforcement is scattered across UI code, gateways, backends, database filters, and agent tool gateways—each interpreting access on its own terms. When fragments disagree, decisions diverge, access becomes unexplainable, and revocation becomes unsafe.
One decision authority. Every relevant fact. No parallel authorization truth.
Outcomes
Every relevant fact
Roles, grants, attributes, risk, and relationship intelligence from the graph super PIP assemble at decision time. ReBAC contributes facts—it never issues a competing permit.
Explainable and safely revocable
Present-state explanation stays distinct from change history. Contribution-aware revocation removes one reason while preserving every other legitimate source.
How Governed Authorization works
Meaning, facts, decision, enforcement, and proof—on one spine. PIPs contribute facts. The PDP authorizes. PEPs enforce and may only narrow.
-
1
Applications define meaning
App Authorization Contracts declare features, operations, object requirements, and enforcement locations—before any runtime request.
-
2
Business composes authority
Bundles, personas, and governed assignments establish bounded capability. For agents: bounded delegation—never a copied human role.
-
3
PIPs assemble facts
Roles, grants, attributes, risk—and relationship facts from the graph super PIP. The graph contributes facts; it never issues a permit.
-
4
One logical ABAC authority decides
A PEP sends an AuthZEN request; a serving PDP instance in the governed fabric evaluates policy and returns decision context.
-
5
PEPs enforce; the system explains
UI, gateway, backend, search, and agent PEPs enforce the same decision. Present-state explanation stays distinct from change history.
A governed authority, not another policy engine
| Dimension | Typical authorization platform | EmpowerID Governed Authorization |
|---|---|---|
| Starting point | A runtime request arrives | Applications define what access means—before any request |
| Role of the graph | ReBAC issues its own permit—a second truth to reconcile | Graph super PIP contributes relationship facts to one ABAC authority |
| Decision topology | One central PDP—or divergent local engines | One governed policy model; distributed PDP instances with identical semantics |
| AI agents | Gateway traffic filtering; agents inherit human tokens | Delegation, discovery, and invocation governed as three distinct moments |
Capabilities
Capabilities vary by contract and release. Each item shows its own maturity and evidence status.
App Authorization Contracts
Applications declare features, operations, object requirements, and enforcement locations—engine-neutral semantics projected into policy, grants, and tests.
Graph super PIP
Relationship and delegation facts—ownership, membership, management scope, sharing—feed the ABAC decision without becoming a second authorization truth.
AuthZEN PDP fabric
AvailableStandards-based OpenID AuthZEN between every PEP and PDP. One governed policy model distributed across regions, clusters, and deployment boundaries.
Contribution-aware governance
Grant Contribution Registry records every reason access exists. Remove one contribution; preserve others. Explain what remains.
Evaluation, batch, and authorized search
Single authority for point decisions, UI capability loading, and query predicates—result counts never leak what record-level checks would deny.
Agent authorization moments
Authorization before cognition. Reauthorization before action. Govern delegation creation, policy-scoped discovery, and invocation under the same logical authority.
Built for the agent era
Authorization before cognition. Reauthorization before action.
EmpowerID does not give an AI agent a copy of a human's permissions. Every stage can narrow. No stage can widen.
-
Delegation
May this user delegate this tool to this agent?
Delegatable tools = agent capability ceiling ∩ owner delegation authority.
-
Discovery
Which tools are effective for this user, agent, and active delegation?
Policy-scoped tool surface before the agent plans—not its full registered toolbelt.
-
Invocation
May this agent use this tool on this resource now?
Current delegation, graph, identity, trust, risk, and data-scope facts evaluated again at action time.
Integration patterns
Evaluation
May this subject perform this action on this resource?
API, backend, and object actions
Batch evaluation
Which of these actions or resources are permitted?
UI capability loading and efficient multi-checks
Authorized search
Which records may this subject see?
Query predicates and consistent filtering—counts never leak denied records
Five questions to ask any authorization platform
- Does the graph issue a second permit—or contribute facts to one policy authority?
- Does authorization begin with application-defined semantics, or only with a runtime request?
- Can the platform explain every active contribution—and remove one reason while preserving the others?
- Does agent authorization govern delegation, discovery, and invocation—or only gateway traffic?
- Can UI, API, backend, search, and agent enforcement points share one decision authority?
Market proof
Industry recognition and standards conformance
AuthZEN 1.0 certified
PEP 01/02 and Search PEP 03—interop-tested OpenID Authorization API interfaces.
KuppingerCole Leader
Identity Fabric and authorization leadership recognized across product, innovation, and market dimensions.
Implementation SKU: EmpowerID Authorization Service — available on the Identity Fabric services catalog.
FAQs
Is Governed Authorization the same as the Authorization Service?
Governed Authorization is the architecture—one logical ABAC decision authority with super PIP context, contribution-aware explanation, and AuthZEN interfaces. The EmpowerID Authorization Service is the Fabric implementation SKU customers deploy and embed.
Does ReBAC replace ABAC?
No. The graph is a super PIP—it supplies relationship and delegation facts to the ABAC PDP. It contributes facts; it never issues a competing permit.
How does this relate to Agent Governance?
Governed Authorization decides what may be delegated, discovered, and invoked. Governed Execution corroborates the external effect after authorization. Both run on the same Identity Fabric spine.
What standards does it support?
OpenID AuthZEN between PEPs and PDPs. EmpowerID AuthZEN 1.0 certification covers PEP 01/02 and Search PEP 03. Continuous access integrates via SSF/CAEP on the same fabric.
Get Started
See one authority decide, everywhere
Request Demo See the platform in action
Talk to an Expert Technical consultation
