Do we have to replace our identity provider?

No. The fabric reads from the identity provider and HR system you already run. It adds directive-level scoping on top; it does not become your directory.

What happens when someone changes roles mid-execution?

In-flight authority is invalidated at the next gate. Work already verified and committed stays in the ledger with the role that authorized it at the time — which is exactly what an auditor needs to see.

How is agent identity different from directive identity?

Agent identity answers which process acted. Directive identity answers whose authority it acted under. Only the second is defensible when a decision is challenged.

Does this slow execution down?

Credential minting happens once per directive, before the first model call. The gate is measured in milliseconds, and it removes the far more expensive step of reconstructing authorization after the fact.

Orcher · Component 02 of 07

Role Identity Fabric

Binds the directive to a human and a role, cryptographically and revocably.

Layer 1 — sequential, gating

A named human bound by cryptographic filaments to the agents acting on their authority — Binds the directive to a human and a role, cryptographically and revocably.

Human-in-the-Role only means something if the role is enforceable. The Role Identity Fabric binds each directive to a named professional and the authority their role carries, then scopes the agent's permissions to that authority — not to a service account, not to a shared application identity, and not to a registry entry that merely records an agent exists.

Issues per-directive credentials bound to a human and their role.
Scopes permissions to the authority of that role, time-bound and task-bound.
Revokes authority instantly when a role changes, without redeploying agents.
Distinguishes agent identity from directive identity — a registry entry is not authorization.

Without it, agents borrow badges

Agents inherit broad service-account permissions and act with authority nobody granted them for this task. Registry sync tells you an agent exists; it does not stop it from acting outside a role at runtime.

What it emits

A role-bound authorization token attached to the directive for the life of the execution.

Evidence

What the record shows

Figures drawn from the Enterprise Superintelligence Report, Vol. I, August 2026.

144:1

non-human to human identities in the enterprise

up from 92:1 — Vol. I, p.11

92%

of organizations have no visibility into agent identities

Vol. I, p.6

86%

cannot enforce policy against those identities

Vol. I, p.6

14%

median role scope as a share of underlying account permissions

Vol. I, p.22

Vol. I · p.22Role-scoped authority across frontline, department head, and executive tiers

Mechanism

How it works

Four stages, in order. Layer 1 components gate execution; Layer 2 components run continuously and never block.

01
Resolve the human
The directive is matched to an authenticated person in the enterprise identity provider — not to an application, a service principal, or a shared automation account.
02
Resolve the role
The person's role at the moment of the directive determines the authority available: what they may approve, up to what value, over which populations, in which jurisdictions.
03
Mint per-directive credentials
Orcher issues credentials scoped to this directive alone — task-bound, time-bound, and expiring on completion. Median role scope in deployment is about 14% of the underlying account's permissions.
04
Enforce and revoke
Every downstream call presents the role-bound token. A role change, suspension, or revocation invalidates authority instantly, with no agent redeployment and no waiting for a credential to age out.

Operational contract

Input: Signed directive plus enterprise identity assertion
Output: Role-bound authorization token attached to the directive
Mode: Layer 1 — sequential, gating
Scope: Task-bound and time-bound; expires with the execution cycle
Revocation: Immediate on role change; no redeployment required
Integrations: Enterprise IdP, HR system of record, and existing entitlement model

What it is not

It is not an agent registry

A registry records that an agent exists. It does not stop that agent from acting outside a role at runtime. The fabric binds authority, not inventory.

It is not a service account with better naming

Service accounts are static, shared, and over-permissioned by design. Per-directive credentials are none of those things.

Failure behaviour

If the human cannot be resolved, the role does not carry the required authority, or the entitlement is stale, the directive halts before any model call. There is no fallback identity to borrow.

Questions

What enterprises ask first

Do we have to replace our identity provider?: No. The fabric reads from the identity provider and HR system you already run. It adds directive-level scoping on top; it does not become your directory.
What happens when someone changes roles mid-execution?: In-flight authority is invalidated at the next gate. Work already verified and committed stays in the ledger with the role that authorized it at the time — which is exactly what an auditor needs to see.
How is agent identity different from directive identity?: Agent identity answers which process acted. Directive identity answers whose authority it acted under. Only the second is defensible when a decision is challenged.
Does this slow execution down?: Credential minting happens once per directive, before the first model call. The gate is measured in milliseconds, and it removes the far more expensive step of reconstructing authorization after the fact.

Where it shows up