Boulevard of Broken Dreams

Every enterprise has a boulevard of broken dreams.

You know the one. It is the graveyard of custom admin portals your organization has built, half-maintained, and quietly abandoned over the past two decades. The HR self-service tool from 2018. The partner provisioning dashboard from 2020. The regional admin screen that only Dave understood — and Dave left in 2023. The ERP role manager that three contractors built and nobody documented.

Each one started the same way: a business team needed to manage something — users, roles, permissions, access — and the identity platform could not give them the tools to do it. So IT built a portal. Six to twelve months of development. Custom RBAC logic. Custom audit pipelines. Custom scope handling. Hardcoded to the org chart at the time of construction. Wired to one system’s APIs.

Every custom admin portal is a confession. It says: our identity platform cannot delegate authority to the people who need it.

And the confession is not limited to IdP admin tools. The boulevard is littered with portals that span the full enterprise — database permission screens, ERP role managers, CRM access tools, internal app admin panels. Systems that your IdP never governed and your IGA product never reached. Each one a hand-built delegation workaround for a platform that was never designed to delegate.

The Pattern That Never Breaks

Twenty years. Three generations of IAM. The pattern is always the same.

Active Directory (2000s) had delegated control on OU subtrees. Fragile ACL inheritance, but at least the directory had a tree. The problem: only AD architects could configure it. So enterprises built admin portals on top of AD’s APIs to give non-IT people a usable interface.

IGA platforms (2010s) — SailPoint, Saviynt, One Identity — solved a different problem: access certification. They review who has access today, route approvals, and produce audit evidence for the access review. What they do not do is determine, at the moment of action, who is allowed to grant or change access in the first place. That delegation gap stayed open. So enterprises built admin portals on top of IGA APIs to bridge it.

Cloud IdPs (early 2010s onward) — Okta, Entra ID — threw away the tree entirely. LDAP was hierarchical by design. Cloud IdPs are flat groups with admin roles. Entra Administrative Units do not nest, do not restrict browsing, and do not prevent members from seeing resources outside their unit. So enterprises built admin portals on top of cloud IdP APIs to fake the hierarchy they lost.

The technology changed. The pattern did not. Every identity platform of the last twenty years has claimed delegated administration as a feature — in the product roadmap, in the sales deck, in the analyst brief. None has ever shipped it in a form a non-IT operator could actually use. Twenty years of lip service to a capability the industry never delivered. So enterprises built portals to bridge the gap. And every portal became technical debt.

Filed for the record:

The Four Ways Every Portal Dies

They all fail the same way. Not immediately — that would be honest. They fail slowly, expensively, and usually after the people who understood them have left.

The Non-IdP Graveyard

Here is the part most IAM vendors do not talk about: the majority of custom admin portals are not IdP admin tools.

They are the admin screens for systems your IdP has never governed. The database permissions UI that manages who can query what tables. The ERP role manager that controls SAP module access. The CRM admin tool that handles Salesforce record-level visibility. The internal application admin panel for the LOB app that finance depends on.

None of these live inside Okta or Entra. IGA products might govern the application-level entitlement — “does this user have access to SAP?” — but they do not govern who is allowed to grant or change permissions within those systems at the moment of action. Who can assign roles inside SAP? Who can change permissions in the database? That delegation gap exists in every non-IdP system your business runs on.

Custom portals. That is who. Built by developers who left. Documented by… nobody.

And this is where the “just add AI governance to your IdP” story falls apart entirely. Your IdP can register an AI agent and give it an identity badge. But it cannot govern what that agent does inside Salesforce, inside your database, inside your ERP system, inside the 50 internal applications that make your business run. That governance is either in a custom admin portal or it does not exist.

The Boulevard Reaches the AI Builders Too

Here is the part the enterprise IT teams did not see coming: they are not the only ones on this boulevard now.

Every team shipping production AI agents in 2026 is reaching the same dead end. The startup building an autonomous SDR. The systems integrator building a procurement agent for a Fortune 500 client. The platform team inside the bank trying to ship a customer-service agent that can actually do things instead of just answering questions. They all hit the same wall, in roughly the same week of development.

The wall has two layers.

The delegation problem. What scope is this agent allowed to operate in? Whose authority is it acting under? Can it see records outside its scope — and what does “see” even mean? Who delegated this authority, and can it be revoked at the per-agent level without taking down the service account that ten other agents share? Every team writes this from scratch, in TypeScript, and it does not survive contact with compliance. It is the same delegation problem twenty years of IAM platforms failed to solve — except now there is no team building a portal next to it. There is just a // TODO: scope enforcement comment and a Jira ticket waiting on it.

The runtime problem. Once an agent has a notion of scope, what does it actually call to enforce it? Every agent platform reinvents the same primitives: resolve an ambiguous identity from a prompt, check whether the caller is authorized for that operation, enumerate only what is in scope (without leaking what is not), emit a decision trace structured enough that a compliance officer can query it three months later, route a self-correction back through the same enforcement boundary. Every team rebuilds this badly, with no shared semantics, and six months in the agent works in the demo and fails in prod.

The graveyard is not just IT’s anymore. There is an agent-shaped wing being built right next to the portal wing. Different language, same architecture, same outcome: bespoke delegation logic that nobody wants to own a year later. (We named the same recurrence pattern at the protocol layer in Not All MCPs Are Created Equal — slapping MCP on top of APIs is the same shape of debt, one layer up.)

The Category That Should Have Existed Twenty Years Ago

Here is what twenty years of building admin portals should have taught us: the portal is not the problem. The portal is a symptom.

The real problem is that no runtime layer in the market answers the question “who is allowed to grant or change access right now?” IGA platforms answer “who has access today, and should they?” — a review question, asked on a quarterly cadence. ServiceNow answers “how do we route this access request through the right approvers?” — an orchestration question. Veza answers “who has access to what, and where is the risk?” — a visibility question. All three matter. None of them determine, at the moment of action, whether the operator standing in front of the system is allowed to perform this operation, at this scope, against this resource type. The same gap is what every agent team hits in their second sprint.

That missing layer has a name now: Authority Governance.

Not another platform promising what the last twenty years promised and never delivered. The runtime layer those platforms were paying lip service to.

Authority Governance is the runtime layer that computes, enforces, and audits delegated authority at the moment of action — for humans and AI agents alike. It is not IGA (which reviews access after the fact). It is not orchestration (which routes workflows, but does not decide whether the workflow is allowed). It is not visibility (which shows you what risk exists, but does not prevent it from happening). It is not a policy engine either — OPA, Cerbos, and Cedar evaluate stateless rules. Authority Governance is the stateful delegation runtime that knows what scope exists, who delegated what to whom, and when authority expires.

It is the layer beneath all four — the one every portal in your graveyard was hand-built to fake, and the one every agent framework is currently rebuilding badly in code. It is built on US Patent 12,549,558.

When you cannot delegate generically at runtime, you build portals. When you cannot delegate generically at runtime for agents, you build bespoke kernel logic inside every agent product. Either way, you accumulate technical debt, you need specialists to maintain it, and when those specialists leave the boulevard gets longer and the dreams get more broken.

What Replacing the Entire Class Looks Like

IdentityRM does not replace admin portals with a better portal. It replaces the need for them by shipping Authority Governance as a runtime layer — a product to call, not a platform to configure. The same runtime works for agent builders: instead of writing scope enforcement in TypeScript, they call it.

The MCP prompt becomes the admin tool. Here is the same task — onboarding a user — done both ways. The example below shows a human operator. The agent-builder version is the same shape — same tool chain, same scope enforcement, same decision trace — just called from agent code rather than from a chat prompt:

That is not a mockup. That is the architecture. The MCP prompt is the delegated admin tool — the one enterprises have been trying to build for twenty years. And the governance underneath is not in a custom portal’s hardcoded logic. It is in the relationship model, enforced structurally, with a catalogued-factor decision trace for every operation.

The governance is not in the operator’s expertise. It is in the architecture. A helpdesk worker using ChatGPT exercises delegated authority with the same structural enforcement as an Okta-certified admin — because the boundaries are in the relationship model, not in the operator’s knowledge of the platform.

Here is why this changes the economics:

Resource-agnostic. The same MCP tools govern IdP users, database permissions, Salesforce records, ERP modules, internal applications. One prompt, one tool chain, one audit trail — regardless of what system the resource lives in. The portals that governed non-IdP systems? Replaced by the same product.

Org-structure independent. Scope is derived from position in the relationship model, not hardcoded in application logic. The company reorganizes. The model adapts. No portal breaks because no portal exists.

Agents and humans, same governance. An AI agent and a helpdesk operator exercising delegated authority hit the same Authority Governance runtime — same scope enforcement, same decision trace, same accountability. One runtime layer governs both. That is the unified delegation model existing platforms have never produced — and the one every agent team is currently rebuilding, badly, in framework-specific code.

The boulevard of broken dreams does not need another portal. It does not need every agent framework to rebuild scope enforcement in TypeScript. It needs the runtime layer that should have existed since the early 2000s — the one that makes both portals and bespoke agent-side delegation logic unnecessary. That is Authority Governance. IdentityRM ships it as a product.

IdentityRM ships Authority Governance as the runtime layer for both human operators and AI agents — for IdP and non-IdP systems alike. Read what Authority Governance actually is, or see the custom admin portals use case.