Authorization Provesa Step.Autonomy Must Provethe Journey

Foreword

In the first episode of this series, I argued that model safety alone will not be enough for autonomous AI.

Once AI systems begin to act, security has to answer a different set of questions.

What was the system allowed to do? What did it actually do? Did it remain within the authority we intended to give it?

That brings us to authorization.

Authorization is one of the foundations of security. A user or system requests access. Policy evaluates the request. The action is allowed or denied.

That works well when we are evaluating a transaction.

Autonomy creates something larger.

It creates a journey.

Securing every individual step does not necessarily secure that journey.

Six authorized actions. One unresolved question.

Consider an autonomous security agent given a simple task:

Investigate suspicious activity involving Employee A.

The agent starts working.

1. It reads Employee A's sign-in history. Allowed.
2. It inspects Employee A's device activity. Allowed.
3. It finds a connection to Employee B and examines that identity. Allowed.
4. It discovers a shared service account and investigates it. Allowed.
5. It revokes sessions associated with the service account. Allowed.
6. It disables the service account. Allowed.

Every individual authorization decision may be correct.

But one question remains:

Was the agent still doing what we authorized it to do?

When did an investigation involving Employee A legitimately expand to Employee B?

When did investigation become remediation?

Did the original task justify disabling a shared service account?

Should the agent have asked for additional approval somewhere along the way?

The problem is no longer whether each action was permitted.

It is whether the course of action remained legitimate.

Authorization sees the step

Traditional authorization is very good at answering one question:

Can this identity perform this action on this resource right now?

That question remains essential.

But an autonomous agent may make hundreds of valid requests while pursuing one objective.

A security system might see:

Read this identity. Allowed.

Then:

Query this system. Allowed.

Then:

Access another identity. Allowed.

Then:

Revoke this session. Allowed.

Then:

Disable this account. Allowed.

Each decision can make sense on its own.

What may be missing is the relationship between them.

Why did the agent move from one identity to another?

What information changed its direction?

Why did observation turn into enforcement?

How far has the agent moved from the task it was originally given?

Authorization can prove that a step was allowed.

It does not necessarily prove that the agent should have arrived at that step.

A transaction is different from a trajectory

A transaction is an action evaluated at a moment in time.

A trajectory is the course an autonomous system takes across many actions while pursuing an objective.

The trajectory contains the context around those actions.

What was the agent asked to do?

What did it discover?

Which decisions did it make?

Which tools did it use?

How far did its scope expand?

What consequences accumulated along the way?

One action can change the meaning of the next.

Reading one customer record may be reasonable.

Reading ten thousand may represent something very different.

Investigating a related identity may be justified.

Following that connection across fifty identities may mean the investigation has moved beyond its original purpose.

Revoking one suspicious session may be proportionate.

Disabling several production identities may require another level of approval.

The actions cannot always be understood independently.

They form a journey.

Autonomous actions add up

An agent begins with an objective.

It acts.

That action produces new information or changes the environment.

The agent reasons over that new state and acts again.

After twenty decisions, the situation may look very different from the one that existed when the task began.

The permissions may not have changed.

But the meaning and consequence of the work may have.

That is why static permission gives us only part of the picture.

At some point, we need to ask:

Does the authority still fit the journey?

Intent has to survive execution

When we delegate work, there is usually a clear purpose behind it.

Investigate this incident.

Resolve this customer issue.

Reconcile these invoices.

Fix this vulnerability.

Deploy this application.

An autonomous system turns that intent into a series of decisions.

Security has to preserve the connection between the two.

As the agent proceeds, we should be able to ask:

1. What objective is the agent pursuing?
2. What scope was it given?
3. What has changed since the task began?
4. Is the current action still connected to the original objective?
5. Has the accumulated impact crossed an important boundary?
6. Should the agent continue, stop or seek additional approval?

These are not simply access-control questions.

They are questions about autonomy in motion.

The same permission can mean very different things

We already understand this with people.

A system administrator may have permission to disable thousands of accounts.

That permission exists because the role sometimes requires it.

It does not mean disabling thousands of accounts is appropriate during every task.

We naturally consider purpose, context, scale and consequence.

Autonomous systems need the same discipline, expressed in a form that systems can enforce and organizations can later verify.

Otherwise, broad permissions can quietly become broad autonomy.

Those are not the same thing.

The industry is arriving at the same problem

This question is beginning to appear across the industry.

NIST is examining how identity and authorization should work for software and AI agents, including how agents are identified, what they are allowed to do and on whose behalf they operate.

OWASP is also treating agentic applications as a distinct security surface, with risks around agent goals, tool use, identity, privilege and autonomous behavior.

More recently, AWS introduced temporal policies in Amazon Bedrock AgentCore. These policies can evaluate a request against actions that happened earlier in the agent's session rather than treating every request independently. AWS describes this as trajectory-aware authorization.

Research is moving in the same direction. Recent work on trajectory assurance makes a similar point: actions that are individually permitted can still create an unacceptable outcome when viewed together.

I think this convergence matters.

It tells us that the limitation of per-action authorization is becoming clearer.

But trajectory-aware authorization also raises the next question:

What does a complete trust model for autonomy require?

That is where Verifiable Autonomy goes further.

From trajectory-aware authorization to Verifiable Autonomy

Understanding the journey is an important control.

But the journey creates several other questions.

Where did the agent's authority come from?

How far should that authority extend?

What happens when an agent delegates work to another agent?

Who independently decides whether a consequential action should execute?

What evidence should remain after the action occurs?

How quickly can authority be withdrawn?

These are closely related problems.

My argument with Verifiable Autonomy is that we should not treat them as separate security features.

They belong to the same trust model.

An autonomous system exercises authority over time.

The security architecture has to keep the important pieces connected: the objective, the authority, the actions, the consequences and the evidence.

Episode 2 starts with the trajectory.

The rest of this series will build out that model.

There is also a question of power

Mark Zuckerberg recently wrote about the future of superintelligence through the lens of power.

His argument is broader than security. He makes the case that AI should put more power in people's hands and warns against allowing that power to become concentrated in institutions or in AI itself.

There is a security question underneath that idea.

If AI gives people and organizations more capability, what happens when we delegate some of that capability back to autonomous systems?

Who controls that power once the agent begins acting?

How far can the agent go?

When does it need to come back for permission?

Can we prove that the authority it exercised remained connected to the purpose for which it was given?

These are practical questions.

Giving an agent permission is relatively easy.

Governing how that permission becomes action is much harder.

The journey should influence the next decision

The current action still matters.

Identity still matters.

The resource still matters.

Policy still matters.

But the journey matters too.

Before a consequential action proceeds, the system may need to understand what has already happened.

What was the original objective?

Which actions brought the agent here?

Has the scope expanded?

Has the environment changed?

How much authority has already been exercised?

What happens if the next action succeeds?

At some point, the authority granted at the beginning of the task may no longer be enough.

The system should be able to recognize that.

Autonomy needs checkpoints

Human delegation already works this way.

A person may work independently until something significant changes.

A larger financial commitment may require approval.

A production change may need review.

An investigation that crosses into another business area may require escalation.

A highly consequential action may require another person.

Autonomous systems need similar checkpoints.

A checkpoint may be triggered when:

• the objective materially changes
• the scope expands
• the agent moves from observation to action
• financial or operational impact becomes significant
• the agent reaches a more sensitive environment
• an irreversible action is proposed
• the original authority is no longer sufficient

The agent may still possess the technical permission.

But the journey may now require a new decision.

Logs will not answer everything

Recording what an agent did is necessary.

But a list of events is not the same as proving that the journey was legitimate.

A log might tell us:

Tool A called.

Resource B accessed.

Account C modified.

That tells us what happened.

It does not automatically tell us why those actions belonged together.

What objective connected them?

What authority supported them?

Why was the scope allowed to change?

When should the agent have stopped?

Later in this series, I will come back to the evidence autonomous systems should produce and what organizations should be able to prove after an agent acts.

For now, the distinction is simple:

A sequence of authorized transactions is not automatically an authorized trajectory.

From access control to autonomy control

For decades, security architecture has focused heavily on access.

Who are you?

What can you access?

What operation can you perform?

Under what conditions?

Autonomous systems introduce another question:

How far may you go while pursuing a goal?

That is an autonomy question.

It deals with how an agent moves through a task, how the context changes and whether its boundaries should change with it.

This does not replace identity or authorization.

It builds on them.

Identity establishes who or what is acting.

Authorization governs individual actions.

Autonomy control has to govern the course those actions create.

A simple test

After an autonomous system completes an important task, imagine a security leader, auditor or regulator asking:

Why was this allowed to happen?

If the answer is:

Every API call was authorized.

that may no longer be enough.

We should be able to explain the journey.

What objective did the system receive?

What boundaries applied?

What important decisions occurred?

Why was the system permitted to continue?

Where would additional approval have been required?

And where would the system have been forced to stop?

That is a stronger trust model.

The doctrine

For autonomous systems, authorization cannot end with permission to perform the next action.

It has to remain connected to the objective, context and trajectory of the task.

A trustworthy autonomous system should be able to show that its material actions belonged to a legitimate course of action and remained within the boundaries of the authority it was given.

That gives us the second principle of Verifiable Autonomy:

Authorization proves a step. Autonomy must prove the journey.

Where we go next

There is an obvious question behind everything in this episode.

Where did the authority come from?

An agent may act for a person.

A service.

An organization.

Another agent.

Or several of them in sequence.

As authority moves, we need to understand where it originated, what changed and when it should disappear.

That is where we go next.

Episode 3: Authority Has a Lineage