Identity Is Not Authorization

Knowing who acted does not determine whether the action should be allowed.

Share
Identity Is Not Authorization

Knowing who acted does not determine whether the action should be allowed.

Identity matters.

It establishes who a system believes is acting.

It supports accountability, access, attribution, and recordkeeping.

Without identity, governance loses one of its most important anchors.

But identity is not authorization.

A verified actor is not automatically permitted to act.

A known user is not automatically authorized to execute.

A credentialed participant is not automatically entitled to create consequence.

This distinction is often blurred in digital systems.

Once identity is established, systems frequently treat the next question as mostly administrative:

Does this user have access?
Does this role permit the function?
Does the account meet the requirement?
Does the credential appear valid?
Does the policy allow the category of action?

These questions matter.

But they do not fully answer the governance question.

The deeper question is not merely:

Who is acting?

The deeper question is:

Should this action be allowed under these conditions?

That question belongs to authorization.

Not authorization as a static permission flag.

Not authorization as a role attached to a user account.

Not authorization as a one-time approval captured in a record.

Authorization, in consequential systems, must be understood as a governed determination at the point of execution.

It must account for identity.

But it must also account for state, context, authority, evidence, constraints, timing, and consequence.

A physician may be fully licensed and still not be admissible for a specific clinical privilege in a specific facility at a specific time.

A financial officer may be known and credentialed, but still not authorized to release a transaction that exceeds threshold, violates controls, or depends on stale information.

A system administrator may have verified identity, but still should not be permitted to execute a change outside an approved state.

An AI-enabled workflow may operate under a valid service account, but still should not advance an action whose downstream consequence has not been evaluated.

In each case, identity answers one question.

Authorization answers another.

Identity asks:

Who is this?

Authorization asks:

What is this actor allowed to do now?

The word “now” matters.

Authorization is not only about standing permission.

It is about permission under current conditions.

Conditions change.

Credentials expire.
Policies update.
Risk thresholds move.
System state changes.
Authority is delegated, limited, suspended, or revoked.
A previously acceptable pathway becomes inadmissible.

If authorization does not respond to state change, it becomes brittle.

If it relies only on identity, it becomes dangerous.

This is especially important as systems become more automated.

In human-centered environments, identity often served as a proxy for trust.

A person was known.
Their role was understood.
Their judgment was expected.
Their conduct could be reviewed later.

But automated systems do not rely on judgment in the same way.

They execute pathways.

They apply rules.

They inherit permissions.

They transform information into action at machine speed.

When these systems treat identity as sufficient authorization, they move too quickly from recognition to consequence.

That creates a governance gap.

The system may know exactly who acted.

It may preserve a complete record.

It may show that the actor held a valid role.

And still fail to determine whether the specific action should have been allowed to occur.

A mature trust architecture must therefore separate identity from authorization.

Identity should establish the actor.

Authorization should determine whether the proposed action is admissible.

That determination should be current, contextual, constrained, and verifiable.

It should be made before execution.

It should be capable of being replayed and independently evaluated.

It should not depend solely on the fact that the actor was known.

Because in consequential systems, trust does not end at identification.

It begins there.

The future of digital governance will require systems that can answer more than who acted.

They must answer whether action was permitted.

Under what authority.

Against what state.

Subject to what constraints.

And before what consequence.

Identity establishes who is present.

Authorization determines whether action may proceed.

They are connected.

But they are not the same layer.

— Scott Stockdale


About the Author
Scott Stockdale is founder of VTI Foundation and Creda Systems. He writes on trust infrastructure, execution admissibility, and governance systems for consequential decision environments.


Trust-State Standard
The normative specification for deterministic evaluation, replay-equivalent verification, and governed execution integrity.

VTI Foundation
Steward of the Trust-State Standard and related governance frameworks.

Creda Systems
Reference implementation of trust infrastructure principles for regulated and consequential environments.