Applications · Identity
Identity and delegated authority

Verified identity is not authority to create organizational consequence.

Identity systems establish who or what is acting. Access systems govern what that identity can reach. Authority Control determines what the verified identity may do on the organization’s behalf, under whose authority, and within what current scope.

The identity-consequence gap

The credential can be valid while the consequence exceeds authority.

A human, service account, workload, device, integration, or agent may be authenticated and permitted to reach a system. That still leaves a different question: what organizational consequences may this actor create through that access?

IdentityWho or what is acting?

Proofing, authentication, federation, claims, credentials, and accountable actor context.

AccessWhat may it reach?

Applications, APIs, data, workflows, systems, and technical operations.

Authority ControlWhat organizational consequences may it create?

Payments, deployments, exports, deletions, approvals, transfers, filings, and other organizational consequences.

Security after compromise

Narrow authority without erasing identity or stopping every operation.

After compromise or uncertainty, the same identity can remain attributable while its authorized consequence scope contracts. Lower-risk activity can continue while payments, production changes, sensitive exports, or other high-consequence commitments require stronger authority.

Verified identitySame accountable actor
Normal authorityRoutine and high-consequence commitments within approved scope
Narrowed authorityRoutine activity may continue. High-consequence commitments Defer or Block.
Actors Authority Control can evaluate

Authority follows the accountable source, not technical capability.

Human identities

Employees, contractors, officers, approvers, and operators.

Service and workload identities

Service accounts, integrations, workloads, devices, and automated pipelines.

AI agents

Agents and sub-agents acting under client-approved policy, delegation, or a governed charter.

Delegated actors

Actors whose authority derives from a responsible human principal, role, policy, or approved organizational source.

The identity stays attributable. The authority applied to each commitment can vary by role, purpose, amount, domain, time, conditions, and prior activity.

How identity enters the Authority Check

Attribute the actor. Resolve the authority path. Evaluate the commitment.

01Establish identity attribution

Identify the human, service, workload, integration, device, or agent responsible for the action.

02Resolve accountable authority

Identify the client-approved policy, role, delegation, or responsible principal supporting the commitment.

03Evaluate current scope

Test the commitment class, parameters, conditions, evidence, timing, and configured limits.

04Determine and record

Return Permit, Defer, or Block and preserve the authority basis and outcome in a durable record.

Relationship to IAM and Zero Trust

Identity systems are evidence inputs, not substitutes for the authority decision.

IAM and Zero Trust establish

Identity assurance, credential state, authentication, device or workload posture, token validity, access result, and session context.

Authority Control establishes

Whether the resulting commitment is within current organizational authority, and creates the record required for that determination.

Authority Control does not replace identity proofing, authentication, federation, access policy, endpoint security, or behavioral detection. It consumes their signals where configured and evaluates a distinct property: authority to create consequence.

Design partners

Begin with one identity path and one commitment class.

Observe how a defined human, service account, workload, integration, or agent uses valid access to create organizational consequence.