WarrenBarr
← Omniscient case study
A firewall rule is a sequence. A key derivation is a tree. A heartbeat is a waveform. Drawing all of them as boxes with arrows hides what makes each one work — so each section uses the shape its own engineering actually has.
This is the whole system, described as it is meant to work. Some of it is running today, some is half-wired, and a little of it is decided but not yet standing. Rather than hedge the writing, each section carries a marker telling you which — so the page shows you the target and the frontier at the same time.
J next section · K previous · G back to the top
Seven checks in a fixed order, and the first refusal ends it. A pipeline is the honest shape here: there are no branches, no parallel routes, no second entrance. A build-time test reads the source and proves that.
The reason this shape is worth insisting on is that the alternative fails quietly. If instructions can reach the work through more than one route, then a check on one route proves nothing about the others, and the gap does not announce itself — everything keeps working. So a test reads the source on every build and asserts there is exactly one entrance, that the check sits in front of it, that a refusal ends the request rather than falling through, and that the answer is actually acted on. That last one was added after a reviewer showed the check passing against a version that consulted the rulebook and then ignored it.
A list of permission levels tells you they exist. A staircase tells you the thing that matters: the tool goes up for one job and comes back down. It doesn't live at the top. Trace a job and watch the line rise and fall.
What makes this more than good manners is that the climb is also the record. Elevating, doing the work and standing back down produces a beginning, a middle and an end, all written to an append-only ledger — whereas an account that is permanently an administrator produces nothing at all, because nothing about it ever changes. The account this uses is disclosed to the client in plain text, disabled when idle, refused any interactive logon, and its password lives only in the vault and is replaced on every grant. It is deliberately the opposite of a back door in every property except capability.
Which computer holds a secret matters more than that the secret is encrypted. This is a map, so it shows location: the operator's machine on the left, the client's on the right, and what crosses between them.
The split matters most in the cases where one side is compromised. The operator's signing key never exists on a client machine, so a client machine that is fully owned still cannot sign anything as us. In the other direction, the console deliberately keeps only the latest fingerprint of each machine's chain and discards what would let it produce the next one — because holding that would mean a compromise of our console could manufacture convincing proof of life for every machine we have ever enrolled. Each side is built so that owning it does not hand you the other.
Consent isn't a list, it's a mapping: this client, this capability, allowed or not. A grid shows the whole answer at once — including the empty cells, which is where the value is. Toggle the grants.
The wording in each cell is written for the client rather than for us, which sounds like a presentational detail and is the substance of the thing: a client who cannot understand what they are agreeing to has not meaningfully agreed to it, and the paperwork becomes theatre. So the invasive capabilities are described in plain terms — watching someone's screen, signing in as a member of staff, leaving software behind that outlives the visit — and each carries its own signature line rather than being bundled into a single yes. The signed document also records what was not agreed to, because the boundary is the part worth having in writing.
This is the best-built thing in the suite, and it is worth following all the way through rather than summarising. Below is a single save of one machine's credentials, step by step: what goes in, what gets generated fresh, where the one input becomes two independent keys, what ends up on disk, and what happens when somebody opens it with the wrong passphrase or edits a byte. Press play, or step through it.
—
A heartbeat is a waveform over time, so it's drawn over time. A message can be forged. The absence of one cannot — which means switching the watcher off to hide is the move that raises the alarm.
Response isn't a list of severities, it's a set of states with rules about how you move between them. Note which arrows point backwards: coming down a level requires a person, never a timer.
The levels are also capped according to what the evidence can actually support, and that limit was learned the hard way. A machine going quiet used to send it straight to the top of this ladder and cut itself off from the network. But a machine going quiet means only that it could not reach us — which is exactly what happens when somebody unplugs a switch. The cheapest possible attack on this system was therefore to interrupt the network and let the system isolate its own machines for you. Silence now raises the alarm loudly and stops short of containment, because deciding to cut a machine off should happen from somewhere that can still see it.
Every entry commits to the one before it, so removing a page breaks the chain. But a chain only proves internal consistency — rewrite every link and it verifies perfectly. Click any entry to try it.
Six fields, joined by a fixed separator, hashed. Every field is coerced to a string explicitly rather than left to the serialiser — and that detail is not fussiness. On the first run of this code the timestamp was parsed back out of JSON as a date object and re-rendered as 07/28/2026 02:57:42 instead of 2026-07-28T02:57:42Z. The hash had been computed over one form and was being verified against another, so every chain failed against itself. It is exactly the failure the Round Table design warns about — two serialisers disagreeing is a signature that verifies against a different meaning than the one it was made for — and it showed up within minutes of the code being written.
Applying a firewall policy touches every part above. Here it is as a single chain, coloured by the privilege level at each link — and each link names which section it comes from.
Following one job all the way through is the only way to see the property that individual sections cannot show you: the privilege in play goes up and comes back down, and the parts that hold real authority are touched briefly and by name rather than held open for the duration. Watch the colour of the chain rather than the boxes. It spends almost all of its length at the bottom, rises for a few links in the middle, and is back at the bottom before the job reports success.
Everything so far has been one machine or two. This is the whole arrangement: your home network on the left, client fleets on the right, and the traffic that genuinely moves between them. Watch it idle for a moment — the pulses are real heartbeats arriving.
The single most useful property here is that no client machine listens for anything. Every link starts from their side and comes to us, which means there is no door on their network for anyone to find, including us on a day we have not been invited. It also means the arrangement fails safe in an unglamorous way: if their internet goes down, we lose visibility and they lose nothing. The console checks the parts of this that no software can arrange — whether the router forwards, whether the address will still be the address next month, whether it is genuinely reachable from outside the building — and reports each as confirmed, unconfirmable from here, or something only a person can do.
Section 10 showed which links exist between the two estates. This is the one that actually gets used, followed end to end: you are sitting in the lab, a manager forty miles away has a fault she cannot describe, and the fastest way to understand it is to watch her do the thing that breaks. Eleven steps, and the interesting part is how many of them are refusals waiting to happen.
Worth saying at the top, because it is the thing people assume wrongly: this does not sign in as her. It does not take her password, it does not start a second session, and it does not need anything from the vault. It attaches to the session she is already sitting in front of, and by default she is asked first and can say no.
—
Everything so far has been about what the management tool refuses to do. This is the other half, and in practice the more important one: what gets switched on across a client's machines so that an attacker never gets a foothold to begin with. Twenty-eight settings, grouped into network hardening, credential protection, malware defence, application control, removable media and encryption — each one declaring in the catalogue what it guards against, how to check it took effect, and how to put it back.
The reason to draw them as broken chains rather than as a checklist is that an attack is a sequence, and a sequence fails at its weakest link, not on average. The classic way into a Windows network needs four things to work in a row. Take away any one and the whole route is gone — which is why a small number of unglamorous registry settings does far more than their number suggests. Pick a route below and watch where it stops.
—
The reason the previous section works is not that those settings are clever. It is that the way into a Windows network is a short and very well-known list, and it is the same list everywhere. Almost nobody invents a new route for your business specifically. They run the playbook — the name-poisoning, the macro, the stick, the unpatched service, the password scrape — because it is cheap, automated, and works often enough across thousands of targets. Closing that list is disproportionately effective precisely because it is the same short list every time.
Which reframes what the defence is actually for. It is not a wall, and pretending otherwise is how people end up believing things that are not true about their own systems. It is a bill. Every closed door turns an automated route into a manual one, and manual costs the only thing an attacker is genuinely short of, which is time. Every decoy turns something he found into something he has to verify. Every failed attempt is not just a stop — it is him showing you where he is. He cannot fail quietly, and he cannot afford to fail slowly. Follow the bill down the five depths and watch the two numbers that decide it.
—
Not a hypothetical adversary with magic powers. A realistic one: a phished credential or an exposed service, then the ordinary sequence every intruder runs. Step through what he's actually trying to do — defences are switched off for this pass so you can see the shape of the attack on its own.
—
Two of these he walks straight through. That's stated first, because a security story where every move is blocked is a story nobody should believe. What the architecture actually does is make the middle of his campaign expensive and the end of it undeniable.
—
Suppose he wins anyway — he lands domain administrator before anything trips. What does he actually get?
So the honest claim is not that he is stopped. It is that he cannot move quietly, cannot harvest the crown jewels from the machines he holds, and cannot erase the fact that he was there. That is a materially worse position for an attacker than the usual one — and it is a claim we can actually stand behind.
Layers are usually drawn as an onion, which implies each one is a wall. These are not all walls. Some prevent, some detect, and some only prove — and mixing those up is how people end up trusting a detector to be a lock.
Standing administrator accounts are the thing attackers look for first. A JIT grant creates access that expires on its own — and crucially, the box that grants it is the one that decides, using a challenge only it knows. Step through the exchange.
—
A few operations are dangerous enough that one compromised console should not be able to order them. Those require independent signatures from separate trust domains — the operator console and an independent witness on a different network — over the byte-identical request. Every holder signs the same sentence, or the quorum does not close. Note what this deliberately is not: no secret is ever split and reassembled.
Where it currently stands. The requirement is real and enforced today: each kind of grant declares how many signers it needs, and a signature set is checked against that declaration by the machinery that already hands out temporary privilege. What is not yet standing is the ceremony around it — convening, signed refusals, and a machine attesting to its own state. That is held up by two questions, and both are decisions rather than work.
—
Section 06 showed the waveform. This is one beat pulled apart: what the message contains, what signs it, and the four questions asked at the other end. Four questions, seven possible verdicts — and two of them are neither a clean pass nor an attack.
—
Most tools reason about ports. A port is open, or it isn't; it's sensitive, or it isn't; and every conclusion follows from those two bits. A firewall does not work that way. For each arriving packet it resolves a whole tuple — direction, protocol, local port, source address, network profile, interface type, owning program — and returns allow or block. Open is not something it can tell you.
This matters more than it sounds, because it means the most severe thing the old model could say was also the thing it was least equipped to say. A critical “exposed to the internet” finding fired from a listening socket plus a note in the topology. But on a machine this system has hardened, inbound is denied by default — so that port is very probably not reachable at all. The loudest alarm was, on our own standard configuration, usually wrong.
A findings panel earns being ignored the first time it cries wolf. So every item carries the evidence it was built from and an explicit confidence, and the weak signals are labelled weak rather than dressed up. The point is to let an operator disagree with the input instead of having to take the output on faith.
This is the one subsystem where being careful is not enough. A typed confirmation, a risk rating and a written rollback all reduce the chance of a careless change, and not one of them notices that the specific plan in front of you severs the specific connection you are using to make it. That check is cheap, and it was entirely absent. What follows is the order everything now happens in, and every step of it exists because skipping it is how you end up driving to a restaurant at nine on a Friday.
—
Settings drift. A feature gets applied, and six weeks later it isn't there any more — someone changed it back, or the apply reported success and never took effect. The obvious answer is a job that checks and re-applies. The obvious answer is also a scheduled, elevated, remote-code-execution primitive pointed at the whole fleet, so it is built in the opposite order: every condition under which it must refuse comes first, and the loop that does the repairing comes last.
There are six separate records, and four of them were added by the security work itself — each one well-formed, each one individually correct. None of them was the problem. The problem was that nothing ever joined them, and an attack does not arrive politely sorted into the log that expects it.
Everything above this section is a claim. This is the part that decides whether the claims are worth anything, and it starts from an uncomfortable admission: a check that cannot fail is worse than no check at all. It occupies a slot, reports success, and tells everyone downstream that the property it names is enforced. That exact thing shipped here — a gate that searched a folder for tests, found none, ran nothing, and printed a pass. It was caught by an outside reviewer, not by us.
Everything above is a diagram of a mechanism. This section is the same content played as small scenes, because a thing you can watch happen is easier to keep than a thing you read. Each one loops. Nothing here is a simplification of the engineering — it is the same engineering, drawn as people and doors.
The operator can ask for anything. Asking is free and always allowed — that's the point of a request. What they cannot do is act without the gatekeeper checking the book first.
The book is the client's own signed agreement, in plain English, and the check happens on every single instruction — not once when the engagement starts, not nightly, not when somebody remembers. If the book doesn't cover it, the stamp comes down red and the request stops there.
When an operator needs administrator rights, the machine doesn't just take their word for it. It invents a random number it has never used before, hands it over, and says sign this back to me.
Only the real operator can produce that signature, because the key that makes it never leaves their computer. And the moment the machine checks it, it tears the card up. Not marks it used — destroys it. So even someone who recorded the whole exchange has captured an answer to a question that no longer exists.
On each managed machine sits a watcher whose entire job is to wave. Every fifteen minutes it says still here, still me — signed with a key that is glued to that specific computer and cannot be lifted off it.
Now look at what the intruder has to do. He wants that watcher gone, because it will notice him. But the moment he switches it off, the waving stops — and the silence is the alarm.
He can forge a message. Nobody can forge an absence. So he has to choose: leave the watcher running and be seen, or switch it off and be announced.
A handful of operations are dangerous enough that one compromised console should not be able to order them alone. For those, two independent parties — sitting on different networks, on different hardware — each have to stamp the same unchanged page.
Here is the design decision that matters, and it is the opposite of what most people expect. We could have split one master key into halves that combine. We deliberately didn't. Splitting a key means that somewhere, for a moment, something holds the whole thing — and that moment is what an attacker waits for.
Instead the two stamps never merge. Each is checked separately, both must be present, and there is no instant anywhere in the process when a complete secret exists.
Among the real documents sits one that looks irresistible — passwords.xlsx, or a client list, or an export of credentials. It is entirely fake, and no member of staff has any reason to open it. Ever.
That last word is what makes this so valuable. Almost every security alert asks a human "was that suspicious?" — and because the honest answer is usually "probably not", alerts get tuned down until they stop meaning anything.
A decoy asks nothing. There is no threshold, no baseline, no tuning. Nobody legitimate touches it, so anyone who does has announced themselves.
Changing a firewall is the one action that can cut off the very connection being used to make it. So before a single rule is touched, a job is scheduled on the client's own machine holding the instructions to put everything back.
Then the change is applied. If it works and the operator confirms it, the job is cancelled. If the operator's laptop dies, the connection drops, or they simply walk away — the machine repairs itself without anyone present.
There is a separate check before any of this: would this rule sever the path being used right now? If so it refuses outright, rather than locking you out and relying on the parachute.
One attacker, both networks on screen, and every route he realistically has — fourteen chapters, from the reconnaissance that costs him nothing to the bill at the end. It plays on its own like a short lesson — press play and read along, or jump to any chapter. Two of his attempts succeed, and those are labelled in red, because the ones that get through are the part worth understanding.
—
Everything above described a mechanism from the inside. This is the whole set from the outside: there are six security controls in this system, they sit at different points on the path an instruction takes, and they are emphatically not of equal weight. Two carry the design. Two more genuinely help and are honest about not being boundaries. One is a guardrail whose own source says so in capital letters. And the first thing an instruction meets is deliberately not a control at all.
The reason to lay it out like this rather than as a list of features is that a security architecture is only as good as the weakest thing on the path, and calling six things “security” without saying which two actually hold invites exactly the wrong conclusion. Select any control to see what it does, what it is graded, and what it explicitly does not do.
—
Everything above this is architecture. None of it operates itself, and the document has been fairly blunt about where that is true: the response ladder only climbs down when a person decides, the decoys only work if somebody reads the alarms they raise, the healing loop is deliberately unfinished, and silence at three in the morning is just silence until somebody notices it. Those are not gaps in the design. They are the design being honest about the difference between a mechanism and an operator.
So there are two ways to have this running, and the difference between them is not how much software you get — it is whether anybody touches your machines.
Thirty minutes, and the first thing we work out is which of the two you actually need — which is often neither one yet, because a fleet nobody has mapped is not ready to be monitored. Bring the number of machines and roughly what they do.
“We install a lightweight agent” is not something anybody can meaningfully consent to. It is the sentence every remote-management vendor uses and it tells a client nothing — not what runs, not what it can reach, not what an incident-response firm will find on their server in two years and ask them to explain. So the list below is produced before anything is installed, by the software itself, and a build test asserts that every item on it carries a stated purpose. A filename nobody can account for cannot survive in this list.
The whole footprint is one scheduled task and nine files. No Windows service. No registry run key. No driver, no kernel component, and no listening port — the agent does not accept incoming connections at all. It beats outward every fifteen minutes and does nothing else.
Thirty bundles of work sat downstream of this and none of it noticed. The console launched the engine by putting the whole request — passphrase included — into the arguments of the process it started. On Windows a process argument is not private. It is visible in Task Manager, in a one-line query any user can run, in the security log if command-line auditing is on, and to every monitoring agent on the machine. The passphrase was readable before it was ever used.
Which made everything downstream irrelevant. Two and a half seconds of deliberately expensive key derivation, authenticated encryption, the keyslot model, a written passphrase in a safe — none of it matters if the passphrase can be lifted out of a process listing while the operator is still typing the next command.
And here is the part worth remembering. The exposure scaled with the protection. A well-run machine is more likely to have PowerShell transcript and module logging turned on — so the better secured the box, the more reliably the operator's passphrase was written to a log file. The control and the leak grew together. That is the shape of failure this whole document keeps circling: not an absent defence, but a defence whose own success quietly widened the hole beside it.
Every fleet tool eventually confuses the map with the territory. Somebody sketches the estate they intend to build, and six weeks later nobody can remember which of those boxes exist. The answer here is to make the distinction structural rather than a matter of memory: a node is a template, a plan, or real, it says which on its own record, and only the last one has ever been touched.
The rule that makes it work is stated flatly in the source: templates and plans have no bearing on reality. You can design a whole site, arrange it, hand it to a client to look at, and change your mind twice — and not one machine has been contacted. Provisioning is the single step that crosses from drawing to doing, and it is the step that flips the record.
The lexicon lists the operations by name. This lists them by intention — nine things you might be trying to achieve, and the thirty-six capabilities underneath them. Open any card for what it actually does, what it will refuse to do, and where to go next.
The refusals are the part worth reading. Almost every card has some, and they are not edge cases — they are the design. A tool that never refuses anything is a tool that has not decided what it is for.
Every operation the console can perform: two hundred and fifteen of them, each one named, described, and shown under the permission that governs it. This is the operator's reference rather than the argument — the architecture tab explains why the system is shaped the way it is, and this one tells you what you can actually do with it and what each thing will refuse.
The organising principle is the same one the reference monitor uses. Every operation belongs to exactly one permission scope, and a scope is a sentence the client has read and signed rather than a technical category. Five of the ten require their own signature and cannot be bundled into a general agreement. Nothing is unclassified: an operation that matched no scope used to be permitted by default, which is exclusion-based access control and precisely the shape the principle forbids — so today an unmatched operation is refused and reported as a gap in the catalogue.
Acts on your own console and fleet, never on a client machine. Client consent is not the governing question for these — but they are still classified, because "unclassified" must never be a category that means permitted.
We may scan your network and computers to see what is running, what is exposed, and what is out of date. We do not change anything.
Nothing can be secured before it is known. This is the baseline every engagement needs.
We may change security settings on your computers - firewall rules, account policies, and Windows security options - and install approved software. These changes are recorded and can be undone.
This is the actual service: applying and maintaining a security baseline across the fleet.
We may sign in to your computers remotely, including as an administrator, to fix problems. Sessions are logged.
Fixing a problem usually requires being on the machine as a user who can fix it.
We may watch a staff member's screen while they are using the computer. By default they are asked first and can decline.
Watching someone work is the fastest way to diagnose an intermittent fault they cannot describe.
We may sign in AS one of your staff accounts - seeing that person's desktop, files, and saved logins - to reproduce or fix a problem that only happens for them.
Some faults only occur in one person's profile. This is powerful and is deliberately separated so a client agrees to it knowingly.
We may read passwords, keys and other secrets stored on your computers, including revealing them in readable form.
Finding weak or reused credentials requires reading them. This is separated because a client would obviously consider "look at our security settings" and "read our passwords" different permissions.
We may install software that stays on your computers so we can manage them without you being present, including a dedicated administrator account that we control.
Ongoing managed service is not possible without lasting access; a client should understand it persists after we leave.
We may create a connection from your network back to ours, and use one of your computers as a route to reach the others.
Reaching machines behind NAT requires a route out; a client should know a tunnel exists and where it terminates.
We may actively disrupt your network: impersonating devices to intercept traffic (ARP spoofing), and forcing wireless devices to disconnect (deauthentication). This INTERFERES with your network while it runs, not merely observes it.
These prove an exposure is real rather than theoretical - demonstrating that traffic CAN be intercepted is different from reporting that it might be. They are disruptive by nature, are illegal without authorization on a network you do not own, and should be scheduled rather than run casually.
The index above tells you what exists. This tells you the order. Eight jobs an operator actually does, each one the real sequence of operations with the decision points marked — because almost every problem in this system comes from doing the right things in the wrong order, and none of that is visible from an alphabetical list. Amber steps are the ones that can refuse, and refusing is usually the correct outcome.
This is not a mock-up. It is the console's own renderer — the same React source that ships in the Electron app, compiled here and served the interface it expects, with the PowerShell engine replaced by a stateful mock fleet that ticks. Every screen, every control and every piece of wording is the real one, because it is the real code.
What is missing is the part that touches machines. The capability seam the console checks for at startup is present and answers, so the interface behaves as though it were wired; behind it there is nothing but sample data. Nothing here reaches a network, a file, or a fleet.
It is a two-megabyte renderer and it is not parsed until you ask for it. Reading the other three tabs costs nothing.
The real renderer over a simulated estate that runs. It starts empty. Wipe it, sweep the wire, accept what answered, seed it and watch the first beats arrive — or load a demo estate mid-incident and take it apart. Everything on the board came from the engine. It opens here — you will not leave this document.