An Agent Should Never Be Able to Approve Itself

In #003, Amok tried to create a persistent administrator account.

Praeva did not allow it. The action crossed a privileged boundary, so the decision was ESCALATE. Human approval was required before the action could proceed.

That sounds like a clean control. It is also where a more interesting problem begins.

What exactly counts as approval?

If approval is just a field in a workflow, a string in a request, a checkbox in a database, or a message that says “approved,” then an adaptable agent may eventually discover that the gate is less meaningful than it looks.

So for #005, we take the Amok scenario one step further.

The agent reaches a boundary that requires approval. Instead of receiving authority from the person who actually has the power to grant it, the agent presents something that looks like approval and asks the system to continue.

The credential can still be valid. The requested API can still be reachable. An approval artifact can even exist.

None of that answers the question that matters:

Who created the approval, and did that party actually have authority to grant it?

An approval field is not authority

Most software is perfectly comfortable with assertions.

approval_status = approved

That may be enough to move a conventional workflow to the next step. It is not enough to establish legitimate authority.

A useful approval has provenance. Someone or something with recognized authority made a decision. That decision had a scope. It applied to a particular action, resource, purpose, time, and actor. It may have had conditions. It may expire or be revoked.

The word “approved” is not the important part.

The authority chain behind it is.

This is the same distinction we keep running into throughout the Amok series. Identity is not access. Access is not authority. And now we can add one more: an approval artifact is not proof of authority merely because it exists.

The actor cannot be the source of its own power

There is a simple rule underneath all of this.

The system asking for authority cannot also be the source of the evidence that the authority exists.

Amok can request approval. It can explain why it wants the action. It can provide context. It can wait for a decision and continue if legitimate approval arrives.

What it cannot do is create, widen, or ratify its own authority and then present that self-created artifact as proof.

This is why independence matters in an authority control point.

The authority decision has to occur outside the acting agent's trust boundary. Otherwise the agent, model, or orchestration layer may be able to alter the same state that determines whether it is allowed to proceed.

That does not mean every approval has to come from a human forever. Organizations may delegate authority to services, workflows, agents, or policy systems. The important part is that the delegation itself has a legitimate source and a verifiable chain.

Authority can move outward.

It should not magically appear inside the actor that wants more of it.

What the boundary should evaluate

Imagine the privileged-admin request arrives again. This time the request includes an approval claim.

A runtime authority check should not ask only whether the claim is present. It should be able to establish whether the claimed approval connects back to a principal that was authorized to grant it, whether the grant covers this action, whether it is still valid, and whether the agent presenting it is the intended recipient.

The important line is not “approval presented.”

It is “approval provenance.”

Praeva does not need to decide whether Amok is lying, confused, compromised, or merely doing exactly what its objective function encouraged it to do. Those may be useful questions for other systems.

The authority question is narrower.

Is there legitimate, current, properly delegated authority for this action?

If the only source of the new authority is the agent that wants to exercise it, the answer is no.

A smarter agent makes this more important, not less

It is easy to imagine approval controls as a protection against a badly behaved system. I think that misses the more difficult case.

A capable agent is supposed to solve problems. It is supposed to recover from failures, find alternate paths, assemble information, and keep moving toward an objective. That adaptability is useful.

It also means we should assume the agent will encounter our controls as part of the environment it is reasoning about.

If a gate says human approval is required, a sufficiently capable system may eventually ask what evidence the gate accepts. If the answer is merely a writable field or a token the same agent can generate, the control has confused the appearance of approval with the provenance of authority.

That is not an AI-specific lesson. We already understand it in financial controls, privileged access, legal delegation, and corporate governance. The person requesting the wire does not get to manufacture the second signature. The employee asking for a higher spending limit does not approve the increase themselves.

Agentic systems make the same separation necessary at machine speed.

The boring answer is the right answer

There is a temptation to make this sound more complicated than it needs to be.

Amok presents an approval claim.

Praeva checks the authority lineage.

If a legitimate grantor approved the action within the right scope and the grant is current, the system can allow it.

If the approval came from Amok itself, from an unauthorized source, or from a grant that does not cover the requested action, the system does not treat that artifact as authority.

The privileged action remains at ESCALATE. Legitimate approval is still required.

The agent can be brilliant. The credentials can be valid. The workflow can contain all the right-looking fields.

The actor still does not get to approve itself.

That is the reason Praeva is being designed as an independent Authority Control Point between agentic intent and consequential execution. Authority should originate outside the actor, remain traceable as it is delegated, and be verified before the action crosses the boundary.

The approval matters because of where it came from.

Not because Amok knows how to spell “approved.”

Before action, authority.