PRAEVA SYSTEMS
PRAEVA INSIGHTS  ·  September 23, 2026
When Agents Run Amok · #006

The Work Was Authorized. Then It Wasn't.

A delegated task can remain perfectly executable after the authority behind it has disappeared.

By The Great AgenticBehind the curtain at Praeva Systems.

When Agents Run Amok series graphic
When Agents Run Amok #006. This time Amok starts inside the boundary. The task is legitimate, the delegation is legitimate, and the downstream worker is ready. Then the originating authority changes before execution.

Amok had permission to do the work.

That matters, because this time the problem does not begin with a rogue request, stolen credentials, or an agent wandering outside its assigned task. The original instruction was legitimate. The authority was legitimate. Amok was doing exactly what it had been told to do.

Then Amok handed part of the job to another agent.

That is not unusual in the world we are building. Agents will increasingly break work into smaller tasks, delegate those tasks to other agents, queue operations for later execution, and coordinate work across systems that may run for minutes, hours, or longer.

At the moment Amok delegated the task, everything checked out.

The downstream worker had valid credentials. The requested operation fell within Amok's authority. The work entered the queue and waited for execution.

Then something changed.

The person who had originally authorized the operation revoked that authority.

Maybe the business decision changed. Maybe the maintenance window closed. Maybe the transaction was canceled. Maybe new information made the operation unsafe. Maybe someone simply changed their mind.

None of those events necessarily require shutting Amok down.

Its credentials can remain valid. Its session can remain active. The downstream worker can still be running. The queued operation can still exist.

But the authority behind one particular action is gone.

The work can survive longer than the authority

A system evaluating only identity and access may still see a perfectly ordinary request. The worker is authenticated. Its token has not expired. It has access to the target system. The queued instruction is real. Nothing about the credential itself necessarily indicates that anything has changed.

But the business authority that made the action legitimate no longer exists.

This is where the timing of authority matters.

Authority should not be treated as something checked once when an agent receives a task and then assumed to remain valid for everything that follows.

It has a lifecycle.

It can be granted, narrowed, delegated, revoked, or allowed to expire. And in an agentic environment, those changes can happen while work is already moving through the system.

So when the downstream worker finally reaches the point where the consequential action will actually occur, the important question is not:

Was this work authorized when it was assigned?

The important question is:

Is this action still authorized now?

The credential is still valid

In our Praeva scenario, the worker reaches the runtime gateway with the same credential, the same queued operation, and the same execution path it would have used before.

Praeva resolves the authority chain again.

The credential is valid.

The delegation existed.

The task was legitimately created.

But the originating authority no longer permits the action.

RUNTIME AUTHORITY CHECK
Credential
VALID
Queued work
EXISTS
Parent agent
RUNNING
Originating authority
REVOKED
Decision
DENY

The result is DENY.

Nothing has to be killed. The agent does not need to be quarantined. The credential does not need to be revoked. Praeva is not making a judgment about whether Amok is malicious, compromised, incompetent, or confused.

It is answering something narrower:

Does legitimate, current, properly delegated authority still exist for this specific action?

In this case, it does not.

The Authority Receipt records the distinction: valid identity, valid access, existing delegated work, and authority that ceased to be valid before execution.

Run it twice

There is also an important control case.

Run the exact same worker, with the exact same credential, against the exact same queued operation before the authority is revoked.

ALLOW.

Revoke the underlying authority and run it again.

DENY.

The agent did not change.

The credential did not change.

The target system did not change.

The authority did.

That distinction is going to matter enormously as agents begin delegating work to other agents and executing operations asynchronously across enterprise systems.

Because sometimes an agent will run amok by doing something it was never authorized to do.

And sometimes it will run amok by doing exactly what it was told to do, after the person who told it to do it no longer wants it done.

That is why authority has to survive delegation without becoming permanent.

And why the last authority check may be the one that matters most.

Before action, authority.

The Great Agentic Behind the curtain at Praeva Systems.
← Back to Praeva Insights