Every Boundary Allowed It. The Data Still Leaked.

A class of data breach is becoming easier to produce and awkward to name. The shape is this. Twelve thousand individual reads from a customer database, each one within delegation scope, each one returning a small result set, each one producing an approval receipt, taken together reconstruct a substantial part of the customer database in a different surface, typically a business-intelligence dashboard or a downstream report. The aggregate is a breach in the meaningful sense of that word. In any individual log entry, nothing looks wrong. There is no escalation, no anomaly, no unauthorised access in the conventional sense. There are twelve thousand fully authorised reads.

I keep coming back to this shape because it is the one that current per-action governance does not see. The evidence chain contains only approvals. Each individual decision was correct. The data boundary eroded through twelve thousand authorised actions that no one examined as a sequence.

Boundary Erosion Does Not Need An Attack

Data boundary erosion of this kind does not require injection, confusion or escalation. It requires legitimate access, a delegation that permits repetition, and a governance model that never looks at the sequence. An agent authorised to read customer records is authorised to read customer records; it is not authorised to rebuild the customer database. That distinction exists in the organisation’s intent but not in the delegation’s scope. The delegation says the agent may read customer records. It does not say how many, to what cumulative effect, or for what eventual audience.

Data-loss-prevention systems look for sensitive patterns in outbound traffic, and access-control systems check whether the requester is authorised to read each record. Neither of them asks whether the hundredth read, or the thousandth, should still be allowed given what the first ninety-nine or nine-hundred-and-ninety-nine have already exposed in aggregate. The agent had scope for each individual action. No one had scope over the sequence the actions formed.

The Sequence Is A Different Object

I have considered whether per-action enforcement can be made to handle this on its own, and the answer keeps coming out the same: per-action enforcement, evaluated in isolation, cannot deny a data flow made entirely of individually authorised actions. The violation is a property of the sequence, not of any single evaluation. The single action and the sequence are different objects, and treating them as the same object is how the architecture becomes confused.

The tempting response is to put sequence awareness directly into authority: let the evaluator query history, compute cumulative exposure, decide whether the next read is still acceptable, and deny when the pattern looks dangerous. That sounds tidy until the determinism requirement is taken seriously. If the evaluation function reaches into mutable history while it is deciding, two evaluations of the same action can produce different answers depending on what state happened to be visible at that moment. The decision becomes harder to replay, and the receipt stops standing on its own.

The better architecture is to keep the sequence work outside the evaluation function while making its output available to policy when policy requires it. The evidence chain is what makes that possible. Each read, each tool call, each memory write and each output produces a receipt. A separate sequence-analysis plane can inspect those receipts, compute bounded facts about cumulative exposure, and issue its own assertion: this actor has read this many records in this window; this flow has crossed from restricted source to broad destination; this next action would exceed a declared sequence bound.

Authority then remains narrow. It does not discover the sequence by itself, and it does not make probabilistic claims about whether the pattern is dangerous. It checks whether the required sequence assertion is present, recent, in scope and verifiable. If policy says the next customer-record read requires a sequence assertion and that assertion is missing or stale, the action is denied. The denial is still a deterministic authority decision. The sequence claim comes from a different plane with different proof obligations.

The Evidence Has To Compose

The important architectural move is composition rather than absorption. The sequence plane needs its own evidence. It has to say which receipts it examined, what window it used, what bound it applied, and what assertion it produced. Authority needs its own evidence too: which action was evaluated, which policy required the sequence assertion, whether the assertion verified, and what decision followed.

Those two records answer different questions. The sequence record says what pattern was observed across past actions. The authority record says whether this next action was permitted to execute under the policy and delegation in force at the boundary. Neither record is enough on its own. A sequence signal without enforcement is an alert. An authority decision without sequence evidence cannot see aggregate leakage. Together they make a compound breach visible without forcing authority to become an observability system.

This distinction matters because otherwise the cure breaks the thing it is meant to protect. If every unusual pattern can mutate the authority decision after the fact, receipts stop being stable evidence. If authority ignores sequences entirely, twelve thousand individually correct decisions can still rebuild the database somewhere else. The stack needs both properties: a deterministic authority boundary and a sequence-aware plane whose claims are explicit enough for that boundary to require.

The test for this class of failure is simple. Can the system deny action N using a bounded, verifiable assertion derived from actions one through N minus one, before action N executes, without making the authority function reach into mutable history itself? If it cannot, the twelve-thousand-approval breach is a live failure mode in the deployment.