graphs.sgit.aithe vaultsAgentic Browser IsolationAcceptance-gated escalation

Acceptance-gated escalation

Strip the browsers out of this vault and one mechanism is left that would work on almost any decision anywhere. It is four rules, and each one removes a specific way that organisational decisions normally rot.

  1. Every altitude has one named owner. L1 IT, L2 CISO, L3 DPO, CFO and COO, L4 CEO, L5 Board. Not a team, not a function: a person at that altitude.
  2. Each owner holds the risk in their own language. The same exposure is restated at every level rather than passed upward verbatim. A board does not receive a sentence about session cookies; it receives what that exposure means at its altitude.
  3. Nothing is assigned automatically. A risk sits pending until its owner accepts it personally, and only an accepted risk escalates to the altitude above.
  4. There is no deny button. The available moves are accept, mitigate, or ask for more data. You cannot make a risk go away by disagreeing with it.
Seven stakeholder altitudes, each with its own pending and accepted counts.
Seven stakeholder altitudes, each with its own pending and accepted counts. · the vault's own published figure, sgit.ai/demos/vaults/agentic-browser-isolation/, fetched 22 August 2026, CC BY 4.0

Read the counts, not the diagram

The picture above is a status report and most readers walk past it. IT has five risks pending; every altitude above it is waiting, with nothing arrived. That is not a rendering artefact and it is not a backlog: it is the mechanism working. Nothing has been passed up because nothing has been accepted yet, and the system refuses to let an unaccepted risk appear on a board's plate as though somebody had taken it.

Compare the failure mode this replaces. In the ordinary arrangement, a risk is escalated — which usually means forwarded — and arrives at a higher altitude with nobody having taken responsibility at the lower one. The higher owner then either accepts something they cannot evaluate, or sends it back, and either way the record shows movement where none happened. Requiring personal acceptance before escalation makes the ownership legible as data rather than implied by an email thread.

Why this is a graph mechanism and not a workflow

A workflow would model this as states and transitions. What the vault models instead is edges with named owners on them, which buys three things a state machine does not.

This site has borrowed it

The decisions page published alongside this analysis runs the same four rules over the open decisions of the book's reviews: one named owner, options rather than a yes-or-no, nothing moves until it is taken personally, and no deny button — a decision can be answered, deferred with a reason, or sent back for more data, but it cannot be silently dropped. Borrowing a mechanism from an artefact you are analysing is the strongest form of citation available: it either works or it visibly does not.

What the book will cite from this