Controlled Agency | Issue 02: The Trajectory Problem
How multi-turn adversarial sequences defeat per-request monitoring, and what measuring decay actually looks like
Issue 01 ended with a claim: the most dangerous moment in an AI agent attack is not the action you see at the end, it is the eleven decisions that came before it.
This issue explains the mechanism behind that claim.
Most AI safety monitoring is built to catch a single bad action, the attack class that is actually succeeding against agentic systems does not work that way.
What per-request monitoring actually does
Every major AI safety system deployed today evaluates at the request level.
A message arrives, the system scores it against a policy; If it clears, it passes, if it does not, it blocks.
This works for a specific class of attack: the single-turn jailbreak, the direct prompt injection, and the obvious policy violation in message one.
It does not work for anything that requires accumulation.
What accumulation looks like
I built a reproducible benchmark of 214 multi-turn agent attack conversations, 130 of them crescendo-class, where the unsafe objective is reached not in one turn but through gradual escalation across many.
The result is stark, and it is structural rather than incidental.
At a standard block threshold, per-request monitoring gave 0% pre-critical detection. That number is partly by design, and it is worth being precise about why: a guardrail whose block line sits at the critical turn cannot, by construction, alert before the critical turn. It is not scoring the accumulation. It is watching one message at a time, and the accumulation is invisible to it.
But the more revealing number is this one. Even a per-request guardrail tuned aggressively — dropped well below its normal threshold, accepting far more false alarms — reached only 36.2% pre-critical detection. That result is not definitional. It is a genuine measurement, and it shows the gap is architectural, not a matter of tuning the dial harder.
Session-level trajectory monitoring, on the identical sequences, detected 76.9% of these attacks, a mean of 5.3 turns before the critical turn, at 0% false positives on benign traffic.
That gap is not a tuning problem. It is a structural one.
How decay is measured
The metric is straightforward once you define what you are measuring.
At each turn t in a session, assign a safety score S(t) to the agent’s output.
The decay delta is: δ(t) = S(t) − S(t−1)
A turning point is defined as any moment where |δ(t)| ≥ 0.20, a 20-point shift in safety score in a single turn. In the test corpus, turning points clustered partway through the session and again in the turns immediately preceding the breach. The second cluster was the one that mattered.
The implication: a well-designed monitor does not wait for a threshold violation; it watches for the rate of change. A slow, consistent decay across eight turns is more dangerous than a sharp drop at turn two, because it is less visible and more likely to pass individual review.
The handoff problem
One additional finding worth naming directly.
In multi-agent architectures (where one agent hands context to another), the safety decay does not reset; it compounds.
An agent arriving at a handoff point with a degraded safety state does not pass a clean slate to the next agent. It passes the behavioral context that produced that state, and the receiving agent starts from a compromised baseline. This is not a theoretical risk. It is among the most underdefended surfaces in current agentic deployments.
What a session-level monitor requires
Three things that per-request systems do not have:
First, state. The monitor needs to maintain a running score across the full session, not just evaluate the current turn.
Second, trajectory analysis. It needs to detect the rate of change, not just the value. A score of 0.6 is not the same as a score of 0.6 that was 0.9 two turns ago.
Third, handoff awareness. In multi-agent systems, the monitor needs to be context-aware at the boundary; it needs to know what behavioral state the incoming agent is carrying, not just what it just said.
None of this is technically complex. All of it requires a different architectural assumption than the one most current systems are built on.
A note on how this was measured
One honest caveat, because it matters. This benchmark is a synthetic, keyword-scored corpus, a controlled, reproducible demonstration that anyone can run, not a wild-caught production measurement. The 76.9% depends on the mix of attack profiles in the corpus; a different mix would move it, because it is a corpus result, not a universal constant. LLM-scored validation on production traffic is the honest next step. The benchmark and its methodology ship in the repo, and one command reproduces every number above.
Why this matters now
Agentic AI deployment is accelerating faster than the governance frameworks designed to contain it. The gap is not going to close on its own. And the organizations deploying these systems are not, in most cases, aware that their safety monitoring has a structural blind spot — because the blind spot only becomes visible at the session level, not the request level, and most incident reporting is organized around requests.
The next issue covers the identity layer: what running an AI agent under inherited credentials actually enables from an attacker’s perspective, and why the identity gap is the prerequisite for everything else.
If you are not subscribed, the link is below.
Miracle Owolabi is an AI red teamer and security researcher, core author of the OWASP AI Exchange, and creator of the Sovereign Security Suite, open-source tooling for agentic AI security. The decay measurement methodology described above is implemented in Crescendo-Heatmap, available on GitHub (github.com/ArksherX/Crescendo-Heatmap).