App Authorization Contracts
Applications declare features, operations, object requirements, and enforcement locations—engine-neutral semantics projected into policy, grants, and tests.
Identity Fabric · Decision plane
Governed Authorization
One logical ABAC decision authority for applications, data, and AI agents—fed by relationship intelligence, enforced everywhere, explainable to anyone.
One decision engine. Every relevant fact. No parallel authorization truth.
AuthZEN 1.0 certified · PEP 01/02 and Search PEP 03One authority. Three requesters. Same decision.
Subject
M. Alvarez · AP Manager persona
AuthZEN request
approve_vendor_payment → invoice INV-2041
Facts assembled at decision time
Persona bundle: AP ManagerAttribute: cost center 400Graph fact: manages vendor accountRisk signal: normal
Permitted by the AP Manager persona; the graph super PIP contributes the vendor-scope relationship as a fact — not a second permit.
Same logical ABAC authority · PEPs may only narrowIllustrative product view
The problem
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.
RBAC and ReBAC provide facts. One ABAC engine decides.
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.
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.
Architecture
How Governed Authorization works
Governed Authorization is not a request-in, permit-out chain. Applications declare what access means. PIPs—including the graph as a super PIP—assemble current facts. One logical ABAC authority decides through OpenID AuthZEN. PEPs enforce and may only narrow. Roles and relationships inform the decision. Policy remains authoritative.
- 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.
App Authorization Contracts feed Policy Information Points including the graph super PIP; one ABAC decision authority decides through OpenID AuthZEN; policy enforcement points enforce and may only narrow, with decision, context, and explanation returning to the enforcement point.
One governed policy model.
Distributed decisioning.
Because the decision plane runs on the EmpowerID Identity Fabric, serving PDP instances deploy where enforcement lives—across regions, clusters, and deployment boundaries, as SaaS or a dedicated single-tenant environment in your data center, private cloud, public cloud, or sovereign cloud. “One” means one logical authority and identical decision semantics—not one central server every request must reach.
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
A role may establish the capability to attempt an operation. The ABAC decision determines whether this actor may perform it on this resource under the present conditions.
Application capabilities
Declare capabilities once. Compose personas. Bind with proof.
Each application publishes an App Authorization Contract: business features, operations, standard bundles, and where UI, gateway, and backend must enforce. Persona Profiles assemble bundles across applications for a job function; environment bindings govern who receives them. The same PDP evaluates simple bundle assignment and advanced contextual rules. Revocation removes one contribution at a time—access disappears only when no legitimate reason remains.
Application capability lifecycle: Declare, Compose, Bind, Enrich, Decide (one ABAC PDP), Enforce, Explain, Prove.
Applications declare capabilities. Personas compose them. One PDP decides.
Simple when it should be. Precise when it must be.
Application owners declare capabilities and bundles in terms they already use—and retain visibility into who has access, through which bundle or persona, and why. When higher-risk actions require more precision, EmpowerID adds relationship, delegation, separation-of-duties, risk, device, transaction, and environmental conditions through the same decision authority. Full ABAC power is available where it matters, without turning every application onboarding into a policy-authoring project.
Application owners define the business access model. Security teams add the guardrails. One PDP decides.
Use only as much policy complexity as the decision requires.
Progressive precision · one authority throughout
Invoice Approver
access bundle · declared by the application, assigned in business terms
- +only below the approver's authority limit
- +only within delegated organizational scope
- +only with no separation-of-duties conflict
- +only from a compliant device, while a delegation is active, within the approved window
Conditions are added only when the decision requires them—evaluated by the same PDP as the simple assignment.
Hiding a button is presentation. Governing the action means every enforcement point—experience shell, gateway, backend, search, agent runtime—asks the same decision authority.
Product capabilities
The decision plane, end to end.
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
Standards-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.
Agent era
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
- 1Does relationship context reach the decision point as facts—or as a second authorization truth to reconcile?
- 2Can applications declare what access means before any runtime request arrives?
- 3Do distributed decision points share one governed policy model with identical semantics?
- 4When access is removed, can you remove one reason while preserving every other legitimate source?
- 5Are agent delegation, discovery, and invocation governed as three distinct authorization moments?
Product proof
Remove the reason—not every legitimate right.
The Grant Contribution Registry records every reason access exists—bundle, persona, bootstrap, or governed grant. Revocation removes one contribution while preserving every other legitimate source, and the explanation shows what remains.
Access: M. Alvarez can approve vendor payments
Illustrative product viewGrant Contribution Registry
Persona: AP Manager
Governed business-role assignment · bundle: accounts-payable approval
Direct grant: Q3 vendor migration
Time-bounded project grant · approved by finance controller
Present-state explanation
PermittedAccess is currently permitted by two independent contributions: the AP Manager persona assignment and a time-bounded direct grant for the Q3 vendor migration. Removing either one preserves the other.
Change history · distinct from present state
—Registry state loaded · 2 contributions on record
Know why access exists now—and preserve how it came to be. Live explanation from the authorization graph; change history from the ledger.
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.
Connected on the Fabric
Continuous access→
SSF/CAEP updates the facts the next authorization decision sees.
Agent identity and federation→
Verified identity and trust context authorization consumes—including partner domains.
Credential Control→
Secrets used after authorization permits an operation—without exposing credentials across seams.
Governed Execution→
Corroborates the external effect after authorization—what happened, not only what was allowed.
FAQs
See one authority decide, everywhere
Watch an application capability, a human persona, and a delegated agent resolve to the same governed decision—with the explanation to prove it.
