Platform

The Runtime Authority Layer for Governed Operators

Authority Governance at the moment of action: principal model, hierarchy, persona context, temporal state, decision traces, learning loops, and governed MCP tools.

When an operator — human or AI — asks to act, the runtime needs:

Where the operator can act. Corporate → Region → District → Store. Their scope. Their manager's scope. What is visible vs. what is structurally invisible.

Which persona is active right now. Store Manager, Regional Trainer, helpdesk operator, onboarding agent — each persona gets a different authority context.

Which tools and resources are allowed. The visible MCP tool universe is generated from persona, scope, resources, and runtime authority — not handed to the model as a full catalog.

What proof exists after the action. Authority context fingerprints, permission checks, decision factors, confirmation state, and the full event chain.

This is identity context. Without it, agents would need 5-10 API calls across multiple systems. IdentityRM answers in sub-10ms—one call, complete context.

The authority runtime for human and AI operators.

Personas. Scope. Runtime-scoped tools. Resource-aware permission checks. Authority context fingerprints. Decision traces. Humans authenticate through your IdP; agents operate inside the same governed authority model.

System Architecture

Five Engines

Purpose-Built Architecture #

00 Identity Engine 01 Hierarchy Engine 02 Temporal Engine 03 Decision Trace Engine 04 Learning Loop Engine

00

Identity Engine

The Problem

Traditional IdPs treat users and AI agents as separate concepts. Users get lifecycle management; agents get API keys. When auditors ask about agent governance, you have nothing.

What We Built

One principal model for humans and agents. Same registration, same lifecycle states, same temporal bounds, same audit trail. Agents aren't second-class citizens—they're managed identities.

Capability	Traditional IdP	Identity Engine
Principal types	Users only	Users, API accounts, AI agents
Agent governance	API keys + spreadsheets	Same model as users
Lifecycle states	Active/Inactive	Formal state machine with semantic transitions
State change audit	Log 'user.updated'	Semantic transition history
Temporal bounds	Bolt-on or manual	Built-in: starts_at, expires_at
Ownership	Unclear or none	home_node + created_by

Agent Identity, Managed Here

Complete lifecycle for AI agents

Create agent accounts with the same governance as human users. Assign personas, set guardrails, issue tokens, track decisions. Two operation modes: human delegation (agent acts within a user's context via IdP) and headless operation (agent authenticates directly via IdentityRM).

No IdP Sprawl

No agent accounts in your IdP

No per-agent service principals or app registrations

No credential sync between systems

No IdP admin involvement for agent lifecycle

Headless agents don't need an IdP. Human delegation uses yours. Either way—agent identity lives here.

Why It Matters

Your human employees have lifecycle governance. Your AI agents deserve the same. One engine. One audit trail. Complete history of every state change. One answer when the auditor asks.

01

Hierarchy Engine

The Problem

Real organizations have structure. Corporate → Region → District → Store. Traditional IdPs have flat groups and 1-2 levels of "Admin Units."

What We Built

N-level node trees with automatic inheritance, scoped delegation, and invisible boundaries.

Capability	Traditional IdP	IdentityRM
Hierarchy depth	1-2 levels	Unlimited
Permission inheritance	Manual replication	Automatic cascade
Delegated admin	Global or nothing	Scoped to subtree
Query latency	200-500ms	Sub-10ms

Set Once, Override Where Needed

Template → Override → Inherit. One pattern for everything.

Define defaults at the organizational level. Override at specific nodes when needed. Settings cascade through the hierarchy automatically—identity services, support settings, domains, and more.

500 stores don't need 500 configurations. Template it once, override only where different.

Why It Matters

Franchise owners manage their own users. Partners see only their scope. Delegated admin without god-mode access.

02

Temporal Engine

The Problem

Access is permanent by default. "Temporary" contractor access is still active two years later. 26% of enterprise accounts are stale (Varonis).

What We Built

Every access grant has temporal bounds. Time-bound access is the default, not a feature you bolt on.

Scenario	Traditional IAM	IdentityRM
Contractor joins	Grant access, set calendar reminder	Grant access with expiry tied to contract end
Contractor leaves	Hope someone remembers to revoke	Access auto-expires
Quarterly review	Export to spreadsheet, email managers	Query expiring access programmatically
Audit question	"Let me check the tickets..."	Query temporal state at any timestamp

Why It Matters

Point-in-time reconstruction: When the auditor asks "What access did Sarah have on March 15th at 3pm?"—you can answer. Not from log archaeology. From queryable temporal state.

03

Decision Trace Engine

The Problem

AI agents act on your systems. You can log what they did. When the auditor asks "Why did the AI make that decision?"—you have nothing.

What We Built

Structured decision metadata on every AI action. Not just what happened—why it was decided, what was checked, and who approved it.

Catalogued standardized decision factors

Every AI decision is evaluated against catalogued standardized factors spanning entity validation, authorization, temporal checks, and approval workflows. Queryable after the fact.

Auditor queries that actually work

Question	Query
All autonomous AI grants	`Filter by decision mode`
Grants that skipped quota checks	`Filter by missing factor`
High-risk decisions	`Filter by factor count`
Decisions by specific agent	`Filter by agent identity`

Why It Matters

"The AI did it" is not an audit response. Decision traces make AI reasoning queryable.

04

Learning Loop Engine

The Problem

AI makes mistakes. Humans correct them. Those corrections vanish into ticket systems. The AI never learns from its own errors.

What We Built

Every correction is linked to the original decision. When a human overrides an AI grant, that becomes a training signal. Four correction types tracked across human-AI and AI-AI interactions.

AI-native event architecture

Every event has dual encoding—natural language for compliance dashboards, structured format for ML systems. Same stream feeds auditors AND trains models. The system detects patterns across corrections and suggests operational improvements.

Why It Matters

Your IAM generates its own training data. Every human correction makes the AI smarter.

Governed Runtime

Designed for Governed Operator Consumption #

The five engines do more than expose data. They lower the reasoning burden on LLMs by supplying authority, context, guidance, and proof at runtime.

Tool Guidance at Runtime

MCP tools carry AI hints, self-diagnostics, resource expectations, examples, and recovery guidance in context. Agents learn identity domain concepts, disambiguation strategies, and operational best practices without carrying the full enterprise policy model in every prompt.

Less prompt burden. Fewer retries. Lower model cost. The runtime teaches the allowed path.

Event-Backed Authority Proof

Every governed action emits proof in two forms:

Consumer	Format	Example
Compliance / Human	Natural language	`"Sarah Chen granted Developer role at Seattle Office under Engineering onboarding persona"`
AI / ML Systems	Structured, parseable	`Typed event with authority context fingerprint, entity references, tool set, and timestamps`

Same event stream. Auditors read one format, models train on the other, and the system can prove what was visible and allowed.

Contextual Agent Navigation

Every MCP response carries domain intelligence about what should happen next. Success paths, recovery hints, and security boundaries guide agents through multi-step authority workflows without external orchestration.

Surface	Trigger	Agent Behavior
Success path	Agent completes an operation	Recommends logical follow-ups based on IAM best practices
Recovery path	Agent encounters an error	Provides permission-checked recovery options
Security boundary	Agent queries outside its scope	Zero candidates returned — invisible, not denied

The response itself carries the operating model: what worked, what is next, and what is not in scope.

The Philosophy

Traditional IAM treats governance as workflow and logs the result. IdentityRM governs the operation itself:

Layer	Human Use	AI Use
Hierarchy	Delegation UI	Scope boundaries for agents
Temporal	Access reports	Auto-expiring grants, point-in-time queries
Decision Traces	Audit responses	Authority proof, queryable reasoning, factor analysis
Learning Loop	Correction workflows	Training pairs from corrections
Events	Compliance dashboards	Pattern detection, ML training
Errors	Support tickets	Self-correction hints
Documentation	Developer docs	Runtime guidance and AI patterns

Same governance model. Different operators. Humans, agents, APIs, and clients all act inside runtime authority.

AGENT GUARDRAILS

Agents Can't See What They Can't Access

Delegated authority means delegated boundaries. Out-of-scope entities are invisible—not just inaccessible.

Agent Persona: Engineering/Seattle

Why This Matters

No Over-Privileged Agents

Agent managing Engineering/Seattle can't accidentally touch Finance or London. They don't exist in its world.

Zero Enumeration Attacks

A compromised agent can't probe for what exists. "User not found" ≠ "Access denied." It's truly invisible.

Delegation Scope Enforcement

Each agent's delegated authority defines its universe. Regional agents govern their region. Not yours. Not corporate. Just their subtree.

Persona Switching

Same agent, different contexts. Switch from "Store A" to "Store B" mode—permissions adjust instantly.

Authority Designer

Describe How You Operate. Deploy a Governed Authority Model. #

The Authority Designer turns a plain-language description of your organization into a governed, explainable, deployable authority model. Powered by the Authority Design Engine and an executable corpus of 10+ proven authority patterns — MSP, SaaS, franchise, contractor, partner, vendor, small business, ASP, and more.

Governed Agent Operations

Agent Fleets + Operating Personas

Default governance nodes give every agent a home; agents act under operating personas; one node to review, rotate, or kill the fleet

Automotive Franchise

OEM Dealership Networks

Franchise vs company-owned dealerships, multi-IdP for franchise independence

B2B SaaS

Multi-tenant Customers

Customer isolation, project tracking, per-customer IdP support

Contractor Management

Agency Delegation

Staffing agency delegation, time-limited access, contractor lifecycle

Managed Service Provider

Client Isolation + NOC

Client personas, delegated client admins, and per-client operational boundaries

ASP Multi-Tenant

SMB + Enterprise

SMB flat vs Enterprise complex hierarchy, customer segmentation

Partner Network

Channel Programs

Partner tiers (Gold/Silver/Bronze), partner self-service portals

Vendor Network

Supplier Governance

External supplier boundaries, vendor operators, and governed access

Small Business

Simple Authority Model

A clean authority baseline that can grow as the organization matures

Quick Start

Get Started Fast

Minimal setup, expand later as your organization grows

Pattern spotlight

Governed Agent Operations

The pattern the agentic era needs: agents are an organizational design problem, not an account type. Ships in the corpus today.

Default nodes

The pattern ships its own governance anchors — Agent Governance and a Managed Agent Fleet — so the control home exists before the first agent does.

A home for every agent

Agents are node-scoped subjects with generated credentials and an MCP session bound to their home node. No borrowed human tokens, no overpowered service accounts.

Operating personas

The same agent acts as a support agent in one customer boundary, an analyst in another, and nowhere else — permissions follow the persona in use.

One place to kill it

The fleet node is the single point for review, rotation, expiry, and revocation. Contain at the home without touching the business scope.

See the Governed Agent Operations use cases →

Example: Automotive Franchise Authority Pattern

Dual ownership model with franchise independence via separate IdP

Not an org-chart generator, not a setup wizard. Describe how your organization operates; the Authority Design Engine finds the closest operating model in the pattern corpus, asks only the questions that materially affect the design, and assembles a live model that explains its choices. The design becomes a versioned pattern and seed configuration, preflighted before anything changes. Five minutes from operating intent to executable governance — for human delegation and agent-control boundaries alike.

Natural Language

Semantic Identity Resolution #

AI agents don't think in database IDs. They think in names, relationships, and context. IdentityRM speaks their language.

What agents can resolve naturally

Users

Resolve by email, username, name + organizational context, or hierarchical scoping. Fuzzy matching handles typos and partial names.

Nodes

Resolve by name, domain, or organizational level. Semantic shortcuts for common queries like tenant root or hierarchy levels.

Roles

Resolve by role name, partial match, or natural language reference. Scoped to roles the actor can actually assign.

Proximity Scoring

When multiple candidates match, they're ranked by organizational distance from the actor. Closer relationships score higher confidence.

Out-of-scope users, nodes, and roles don't appear in resolution candidates—they're invisible, not denied. No enumeration attacks via fuzzy matching.

Self-Healing

Self-Healing Infrastructure #

When AI agents fail, they need to understand why—and fix it themselves.

AI Agents That Debug Themselves

Every error includes structured context with recovery classification, actionable hints, and deep forensics. Agents determine whether an error is recoverable, read the suggested fix, and self-correct—without tickets, escalation, or human intervention.

Structured error context with recovery classification on every failure

Machine-readable recovery hints that agents act on autonomously

Deep forensics that trace failures through the full execution pipeline

Correlation IDs that link all diagnostic layers per request

No tickets. No escalation. No waiting for humans. AI agents that debug themselves with full traceability.

Governed MCP Runtime

MCP That Governs Operators, Not Just Tools #

A static MCP catalog gives the model buttons. IdentityRM assembles the allowed operating surface from persona, scope, resources, and authority context.

The visible tool universe is generated at runtime, checked before mutation, and fingerprinted so every event can prove what was allowed.

70+

Governed MCP tools

Opinionated authority operations, not generic CRUD wrappers

1

Scoped tool universe

Generated from persona, scope, resources, and runtime context

Proof

Authority fingerprint

Events prove which tools and authority context existed

Opinionated Tool Governance

Every MCP tool declares its governance requirements upfront — operation type, required permission, risk level, resource requirements, confirmation behavior, and recovery guidance. The agent sees a domain-aware operating surface, not a grab bag of API verbs.

Tool guidance, permission preflight, resource-aware checks, and event proof are part of the runtime contract.

Risk-Based Classification

Risk Level	Examples	Governance
READ	`Query users, check permissions, view hierarchy`	Persona-scoped, audited
WRITE	`Grant roles, create users, update nodes`	Decision trace required
ADMIN	`Create organizational nodes, bulk operations`	Elevated permissions
DANGEROUS	`Delete users, destructive operations`	Human confirmation required

Delegated MCP Administration

The same delegation model that governs users governs tool visibility, tool assignment, and custom MCP extensions:

Developer Platform

Your MCP Tools, Our Infrastructure #

The engine is completely embeddable—open to any IdP, any repository, any business problem.

Build custom MCP tools with Python. Authority governance is inherited — you write business logic, IdentityRM handles persona context, permissions, resources, audit trails, and decision proof.

Permission enforcement declared, not coded

Identity resolution with scope boundaries

Resource-aware check_permissions support

Decision traces with authority context fingerprints

Human-in-the-loop for dangerous operations

Tool guidance and AI-readable recovery hints

Training data generated when corrections occur

You write Python. Your tools inherit the governed operator layer.

Security

Security Litmus Test #

The questions security professionals actually ask:

Q

Who had access to System X on March 15th?

Queryable temporal state. Point-in-time reconstruction from immutable snapshots—not log archaeology.

Q

Can you prove access was authorized?

Decision traces capture: who requested, what factors were checked, whether human approved. Queryable via MCP with full scope and context.

Q

What if the user is deleted?

Audit events contain snapshots. Actor context survives deletion indefinitely.

Q

How do we delegate without giving away keys?

Scoped to subtree. Delegated admins see only their scope—other nodes are invisible, not denied.

Q

How do we govern AI agents?

Same authority model as humans. Persona-scoped tools, resource-aware permission checks, delegated authority, confirmation gates, and event-backed proof.

Q

What about contractors who never expire?

Temporal bounds on every grant. Time-bound access is the default.

Q

How do we audit AI decisions?

Catalogued standardized factors. Decision mode (autonomous vs human-approved). Full tool chain.

Q

What if AI makes mistakes?

Corrections linked to original decisions. Exportable as training data. AI improves from errors.

Integration Layer

Works With Your Stack #

IdentityRM is the runtime authority layer your IdP, IGA, ITSM, and MCP clients do not provide. We complement — not replace — your existing investments.

Works with your IdP

Your IdP Investment, Finally Realized

Layer	Your IdP	IdentityRM
Core question	Can Sarah authenticate?	What can Sarah do in this context?
Hierarchy	Flat groups, Admin Units	N-level node trees with inheritance
Temporal state	Current snapshot only	Full history + time-travel queries
AI integration	Bolt-on copilots	70+ governed MCP tools
Decision audit	Login events	Catalogued-factor decision traces + authority proof
Scope boundaries	Role-based (can probe)	Invisible (never existed)

They authenticate users. IdentityRM computes what the active operator can do in this persona, scope, and moment.

Works with your IGA

Compliance workflows still matter. Runtime authority answers the operational question before action.

Layer	Your IGA	IdentityRM
Who's deciding?	Humans (managers, reviewers)	Governed operators: humans, agents, APIs
How fast?	Workflow (days/weeks)	Runtime (milliseconds)
Question answered	Should Sarah have access?	What authority exists right now?
Trigger	Campaign, request, review cycle	Every governed action
Decision record	Approval chain	Catalogued-factor trace + authority context fingerprint
Use together?	Yes	Yes

IGA certifies access. IdentityRM governs the action itself.

IdP Orchestration

What We Manage In Each IdP #

Typed integration handlers for Auth0, PingOne, Okta, Entra ID, and IdentityRM Native. Same delegation model, same audit trail, regardless of where the permission lives.

Auth0 PingOne Okta Entra ID IdentityRM Native

Role and group synchronization

Container and organizational unit management

User lifecycle (create, update, suspend, terminate)

JIT self-healing on login

Agent permission sync

Your IdP Investments, Protected

We don't replace your identity provider—we make it delegatable. Typed handlers give you push-button integration with Auth0, PingOne, Okta, and Entra ID. Your existing groups, roles, and organizations stay where they are, managed through a unified delegation model with full audit trails.

For customers: the easy button for IdP delegation.

A Delegation Engine for Anything

The handler framework isn't limited to identity providers. Any system with an API—HR platforms, ERPs, SaaS apps, internal tools—can be wrapped in a typed handler and governed under the same delegation model.

Purpose-built IP that solves any delegation problem, for any system.

Same delegation model, same audit trail—regardless of whether the permission lives in Auth0, PingOne, Okta, Entra ID, or IdentityRM itself.

Protected IP

Patent-Protected Architecture #

The architectural IP behind runtime Authority Governance: scoped delegation, invisible boundaries, persona context, and multi-system administration.

1

Hierarchical relationship model

Nodes mirror business relationships — N-level trees can't be retrofitted onto flat groups

2

Scoped delegation of authority

Delegated admins see only what the tree permits — out-of-scope is invisible, not denied

3

Handler-based multi-IdP provisioning

Typed handler processes sync across heterogeneous IdPs and repositories from a single model

4

Persona-based identity contexts

One identity, multiple roles and contexts — seamless switching without re-authentication

This is not a feature list competitors can copy. It is the authority model that makes governed operators practical.

"Governance is not a workflow. It is the runtime authority model."

The Runtime Authority Layer for Governed Operators

The authority runtime for human and AI operators.

System Architecture

Purpose-Built Architecture #

Identity Engine

Agent Identity, Managed Here

No IdP Sprawl

Hierarchy Engine

Set Once, Override Where Needed

Temporal Engine

Decision Trace Engine

Catalogued standardized decision factors

Auditor queries that actually work

Learning Loop Engine

AI-native event architecture

Designed for Governed Operator Consumption #

Tool Guidance at Runtime

Event-Backed Authority Proof

Contextual Agent Navigation

The Philosophy

Agents Can't See What They Can't Access

No Over-Privileged Agents

Zero Enumeration Attacks

Delegation Scope Enforcement

Persona Switching

Describe How You Operate. Deploy a Governed Authority Model. #

Governed Agent Operations

Automotive Franchise

B2B SaaS

Contractor Management

Managed Service Provider

ASP Multi-Tenant

Partner Network

Vendor Network

Small Business

Quick Start

Governed Agent Operations

Example: Automotive Franchise Authority Pattern

Semantic Identity Resolution #

What agents can resolve naturally

Proximity Scoring

Self-Healing Infrastructure #

AI Agents That Debug Themselves

MCP That Governs Operators, Not Just Tools #

Opinionated Tool Governance

Risk-Based Classification

Delegated MCP Administration

Your MCP Tools, Our Infrastructure #

Security Litmus Test #

Who had access to System X on March 15th?

Can you prove access was authorized?

What if the user is deleted?

How do we delegate without giving away keys?

How do we govern AI agents?

What about contractors who never expire?

How do we audit AI decisions?

What if AI makes mistakes?

Works With Your Stack #

Works with your IdP

Works with your IGA

What We Manage In Each IdP #

Your IdP Investments, Protected

A Delegation Engine for Anything

Patent-Protected Architecture #

Hierarchical relationship model

Scoped delegation of authority

Handler-based multi-IdP provisioning

Persona-based identity contexts

Next Steps #

See the Context Engine in action

Evaluate for your IdP landscape

Technical deep-dive

Request a Demo