Authority Governance Is Not a Workflow
What Authority Governance Actually Is — and Why It Changes Everything.
The identity industry calls governance forms, workflows, and quarterly certifications. Authority Governance is not that. It is the operating model that defines who can act, where, under what constraints, enforced at the moment of action.
"IGA asks was this appropriate after the fact. Authority Governance defines what is possible, for whom, at the moment of action — and makes everything else invisible. This is not a faster version of IGA. It is a different category."
— Martin Gee, Founder & CEO, IdentityRM
The word “governance” in identity management means one thing to most people.
It means IGA — Identity Governance and Administration. Quarterly access certification campaigns. A form that asks your manager whether Sarah should still have the Developer role, three months after the question mattered. An approval workflow that takes four days to process a role assignment that should take four seconds. Governance, in the industry vocabulary, is a compliance process that runs alongside operations. It is periodic, form-driven, and disconnected from the moment of action.
Authority Governance is not that. (If you want the full category definition, start with What Is Authority Governance? — this post focuses on what it looks like in practice.)
What Governance Looks Like Today
Here is the IGA model that every enterprise runs:
| Step | What Happens |
|---|---|
| 1 | Operator needs to assign a role — store manager wants to make Jamie a Cashier |
| 2 | Operator submits a request form — fills out fields, selects dropdowns, attaches justification |
| 3 | Request enters an approval workflow — manager approves, IT approves, compliance reviews. Days pass. |
| 4 | Role is eventually assigned — Jamie can work the register. Four days after they were hired. |
| 5 | Quarterly certification asks: is this still appropriate? Manager rubber-stamps 200 reviews in 90 seconds. |
This is what the industry calls governance. A process disconnected from the operation it governs.
The store manager who hires Jamie on Monday cannot make them a Cashier on Monday. Not because they lack the judgment — they hired Jamie, they manage the store, they know exactly what role Jamie needs. They cannot do it because the platform has no way to express their authority. The only options are god-mode administrator (full access to everything, a security nightmare) or locked-out business user (no ability to manage their own team).
So they submit a request. An approval chain processes it. Someone in IT — who has never met Jamie and does not know what Store 42 needs — clicks “approve” on Thursday. The store manager is dependent on IT for their own team. Every role change, every onboarding, every scope adjustment requires a ticket to someone who lacks the business context to make the decision.
This is not a speed problem. It is a capability problem. The store manager has the authority in the org chart but not in the platform. The business capability — managing your own team — is locked behind an IT ticket queue because the governance model does not understand delegation.
That is not governance. That is paperwork. And it is blocking your business.
Authority Governance Is an Operating Model
Authority Governance starts from a different premise entirely.
The store manager does not submit a form. They do not wait for an approval workflow. They open IdentityRM — whether through its dashboard or via a natural-language prompt through MCP — and the system already knows, based on who they are, where they sit in the organization, and what delegation they have been granted, exactly what they can do. Right now. At the moment of action.
The Cashier role at Store 42? They can assign it. They can see it, because their persona grants visibility over that role type. They have authority over it, because they have been designated as the role assigner for Cashier at their store. The Manager role? They cannot assign it — they were never delegated that authority. The Administrator role? It does not exist in their world. It is invisible. Not denied. Not greyed out. Not behind a “request access” button. Invisible.
| Store Manager / Store 42 — Authority computed at runtime | |
|---|---|
| Assign | Cashier at Store 42 — designated assigner |
| Assign | Stock Clerk at Store 42 — designated assigner |
| ~~Assign~~ | ~~Manager at Store 42~~ — no authority |
| Administrator, Identity Architect, Auditor — invisible | |
No form. No workflow. No waiting. The model defines the authority. The runtime enforces it.
Jamie gets the Cashier role on Monday. The store manager exercised their delegated authority — authority that was defined in the delegation model, enforced by a three-layer gate at runtime, and audited with a full decision trace. No form. No approval chain. No waiting for someone in IT who does not know your store.
This is not a faster version of IGA. It is a different category. IGA asks “was this appropriate?” after the fact. Authority Governance defines what is possible, for whom, at the moment of action — and makes everything else invisible.
What This Unlocks
The shift from IGA to Authority Governance is not a governance improvement. It is a business capability unlock:
- The store manager who was filing IT tickets to manage their own team? They manage their own team directly — via dashboard or prompt.
- The regional manager who needed approvals to delegate authority? They designate who can assign which roles at which locations, without escalating to IT.
- The franchise owner who built a custom portal to work around broken delegation? The capability the portal was compensating for is a platform capability now.
- The AI agent handling overnight onboarding at 2 AM? It operates within the same delegated scope as the human operator who owns it — no over-permissioned service account, no ticket queue.
Every one of these was blocked by IGA. Not because the operator — human or AI — lacked the judgment. Because the platform had no delegation model, and without one, the only safe option was to route everything through IT.
Authority Governance removes the bottleneck — not by removing governance, but by replacing forms with a model the platform actually understands. The same model governs operators acting within it and changes to the model itself. (How that works is a post of its own.)
The Category
Authority Governance is not IGA. It is not a faster version of IGA. IGA is a compliance process bolted onto operations that have no governance model underneath — periodic certification with little operational ROI. Authority Governance is the operating model. For the full category breakdown, see What Is Authority Governance?.
It applies identically whether the operator is a store manager using a dashboard, an IT admin working through a natural-language prompt, an AI agent executing autonomously, or an API integration. Same governance model. Same delegation boundaries. Same decision trace. One model that works for the operator you have today and the agent you will have tomorrow.
The delegation model defines who can do what, where, under what constraints — and the runtime enforces it at the moment of action. There is no gap between the operation and the governance, because the governance is the operation.
IGA will continue to matter for compliance certification. But the operating model — who can act, what they can do, and who can change those rules — is what Authority Governance solves. And no other platform has it.
IdentityRM is the only identity platform where the delegation model governs operators in real time and governs changes to itself. See the platform or request a demo.
