Authorization Was the Easy Part: Who Is Allowed to Evaluate the Sequence

An enterprise can authorize every single action its agents take and still be breached. Not because authorization failed — because it succeeded, one action at a time, while no one was watching what those actions added up to.

I’ve spent the last stretch arguing a narrow, uncomfortable point: agent risk composes. A run of individually-authorized actions — each one inside policy, each one a legitimate use of a granted permission — can compose across sessions into an outcome no single check would ever have approved. I laid out the mechanism in Authorized but Composed (DOI 10.5281/zenodo.21400261) and the boundary it implies in the Enterprise Agent Architecture note on the evaluation-authority boundary. This piece is about the question those two leave on the table.

If risk is a property of the sequence, and authorization is a property of the action, then authorization — the thing every identity and access program is built to do well — was the easy part. The hard, and largely unclaimed, role is evaluation authority: who holds the pen on whether a composed run is still sound, at execution time, and can that evaluator itself be trusted?

Why per-session authorization structurally can’t answer this

Authorization answers a bounded question: may this action, by this identity, happen now? It is designed to be stateless and fast, and it should be. But that design is exactly why it cannot answer the composition question. To know whether a sequence has drifted into unacceptable territory, you have to hold state across the sessions the sequence spans — and per-session controls, by construction, forget. Each session re-answers “may this happen?” correctly and in isolation. The accumulated shape is nobody’s question.

This isn’t a gap you close by making authorization stricter. A tighter per-action policy still evaluates per action. You can raise every individual bar and the composed sequence still walks underneath it, because the sequence was never the thing being measured.

The role no org chart has assigned

Walk the seats in most enterprises and you’ll find every adjacent responsibility owned — and this one orphaned. Identity and access is owned (IAM). Policy and compliance is owned (GRC). Network and endpoint are owned. But “who evaluates whether this agent’s accumulated behavior, across sessions, is still acceptable — and can stop it if it isn’t” usually has no name next to it. It falls between the seat that governs who may act and the seat that governs how a single action is shaped, and it is neither.

The attacker’s side of this is starting to get formal names before the defender’s side does. The academic literature is beginning to taxonomize cross-session agent threats directly — the CSTM-Bench work (arXiv 2604.21131) enumerates attack classes with categories like compose and launder, which are precisely “make a breach out of individually-benign steps.” When the offense has a vocabulary for composition and the defense still only has per-action authorization, that asymmetry is the whole story.

What an evaluator would actually have to be

I’m wary of answering “who governs the composition layer?” with “buy the composition layer.” So let me keep this to properties, not products. An execution-time evaluator worth trusting has to be at least three things, and most things sold as “governance” are only the first:

1. Stateful across sessions. If it forgets between sessions, it is just another per-action check wearing a longer name. The composition question requires memory of the sequence.
2. Authoritative at execution time. Advice that arrives after the action is an audit log, not a control. To govern composed risk, the evaluator has to be able to stop the next step, not just annotate the last one. “It’s in the dashboard” is not enforcement.
3. Itself governed. This is the part that gives the August series its title. An evaluator that can halt your agents is one of the most privileged actors in your system. If it is ungoverned — if its own rules can be edited silently, if its own signals can go dark without anyone noticing, if it grades on the wrong axis — then you haven’t closed the gap, you’ve moved it somewhere less visible and more powerful. An evaluator you cannot audit is not a control; it’s a new single point of failure with veto power.

An evaluator you cannot audit is not a control; it’s a new single point of failure with veto power.

That third property is where I’ll spend the rest of this series: the ways a monitoring, measurement, and grading layer can quietly become the ungoverned system, even as it’s the thing you installed to govern everything else.

The question to take back to your own stack

None of this requires you to adopt anyone’s framework to act on it. The composition argument is public (the preprint above), and there’s an open-source reference for the why-layer if you want to read code rather than prose — constitutional-agent on PyPI is the open-core version of the idea. But the useful first move costs nothing and buys no software:

If the answer is a name, ask that person the three questions above: can you see across sessions, can you stop a run at execution time, and who governs you? If the answer is a shrug, or four different half-owners, that’s not a tooling gap yet. It’s an accountability gap — and it’s the one worth naming before the next agent you deploy makes it concrete.

This is the first in an August series on governing the layer that governs your agents. It builds on the composition thesis rather than restating it; if you haven’t read Authorized but Composed, start there.