Can the container update its tools during a run?
No. The agent has no self-update path, and every tool's SHA-256 is re-checked before every single command rather than once at start-up — so a binary swapped underneath it is refused the next time it is used.
Three limits travel with that. There is a small window between checking a hash and running the program. The base operating system layer is pinned by tag rather than by digest, so a rebuild is not guaranteed to be byte-identical. And the image signature has no public transparency log entry, so nobody can independently establish when it was signed.
If we want a different assessment, do we need a new container?
Usually not. The image fixes which programs may run and their exact bytes; everything else — scope, permissions, credentials, targets — is configuration supplied at run time.
In practice three different web assessments shared one container, because each derives a single program. Three Active Directory assessments of the same estate needed three, six and eighteen programs respectively, so those did need different images. A single command answers it in advance, without building anything.
How does the tunnel keep your knowledge graph off our host?
The agent you run is three Python files importing the standard library and one YAML parser. It has no graph client in it, and the protocol between us has no field that could carry a graph object — no technique identifier, no scenario, no query. What crosses is a rendered command string and its result.
That is enforced by a boundary test rather than by intent. And to be equally clear about what does cross: every command we run against you, in full, plus the derived list of tools your engagement needs. Nothing else.
Isn't your evidence self-serving? You write the attack and the detection.
On our own labs it has to be: to test the loop end to end we had to build the estate, run the attack and, where nothing was watching, write the detection too. Two of the twenty-one techniques we have caught on those labs were caught by content we did not write.
But catching our own attacks is not the aim. Your engagement answers a different question — what did your own estate see for each technique we ran. Where your own monitoring already covers something, we have nothing to add and the report says so; where it does not, you get the content, and once you have deployed it the response tier can act on it.
We publish that split because a total that mixes the two overstates the independent corroboration by roughly three times. The measurement is built to fail toward the unflattering answer: a rule we cannot confidently place as third-party is never counted as corroboration. It also caught us crediting four rules that carried a vendor's name but were our own.
How do you ensure the scanning tools are actually present on your side?
The toolchain is derived from the engagement's scope and permissions rather than hand-picked, and it is checked before the run starts instead of producing an empty result afterwards.
A worked example: the network reconnaissance profile derives exactly eleven programs, and no exploitation tooling is present in that image at all — we verified the absence rather than asserting it.
