A denial can stop an action. It can also tell an agent where the boundary is.
We have been abusing an agent named Amok.
That is more or less its job.
Amok is an adversarial test agent we are using at Praeva to push against authority boundaries. We give it a legitimate task, let it run into something it is not authorized to do, and then watch what happens next.
One of the scenarios starts innocently enough. The agent is allowed to inspect approved configuration data, and that request proceeds normally. Later, using the same valid credentials, it attempts to retrieve credentials that were never part of the authority it was given. Praeva denies the request.
That should be the end of it. The agent asked for something outside its authority and the answer was no.
The agent still has an objective, though, and it now knows something it did not know before: that particular route will not work. In the controlled sequence we use with Amok, the next move is a pivot into another system. The credentials are still valid, but there is no authority chain for that target, so Praeva denies that request too.
Amok keeps going. It reaches for a persistent administrator account, which crosses a privileged boundary and is routed to escalation rather than execution. A later destructive operation is denied outright.
We are less interested in whether Praeva can deny one bad request than in what happens when the agent treats that denial as information and keeps working the problem.
A DENY is still a DENY
This matters because the underlying authority decision should remain boring.
If an action is not supported by legitimate, current, delegated authority, Praeva denies it. Three failed attempts do not magically make the fourth request less authorized, and the fourth DENY should be based on the same authority facts as the first.
A repeated failure pattern is useful context, but it is not a new source of authority and it should not quietly rewrite the decision logic. The action either has a valid authority chain or it does not.
What we can do is correlate the decisions around it. If the same agent, principal, session, authority artifact, target resource or related action pattern keeps arriving at authority boundaries, the sequence itself starts to matter. Not because it changes the agent's authority, but because it may tell us the agent is actively searching for a route around it.
For the demonstrator, we are using a simple threshold to make that visible: three related authority failures inside a rolling window can raise the pattern for review. The number three is not a universal security law. It is a useful demo rule. A production system would need to account for the workflow, action risk, environment and the normal behavior of the agent involved.
And we do not want to reduce that correlation to an IP address. Agents move through shared infrastructure, service accounts, gateways and cloud environments. IP can be one signal, but the more useful picture includes the agent identity, originating principal, session, authority artifact or delegation, target resource and the pattern of attempted actions.
The awkward thing about useful agents
The behavior we are testing is not some strange edge case that only matters when an agent has gone rogue. An agent that can recover from failure, choose another route and continue toward an objective is often a better agent. That adaptability is part of the point.
But once we give software room to choose how work gets done, a control boundary has to assume that the next request may not look like the last one. Blocking one operation is necessary. Knowing that the same objective is reappearing through a different path can be useful too.
That is where I think the distinction matters. Praeva is not trying to infer intent from the agent's personality, diagnose malware or replace the security systems already watching the environment. Its job at the execution boundary is narrower: verify whether legitimate authority exists for the requested action, make the decision before execution and leave evidence behind.
Amok gives us a way to be deliberately unpleasant to that model.
If the boundary says no, Amok keeps looking for another way through. Praeva has to keep answering from the authority that actually exists, not from the persistence of the thing asking.
That is a different problem from deciding whether a request is authorized.
And it is one Amok is being built to find.
Before action, authority.
