Platform
One service of ours, one small agent of yours
You do not operate a server for us. You run an agent that dials out, holds no part of our knowledge graph, and can only execute the exact tools your engagement authorises.
The shape of a deployment
Our side
The knowledge graph of techniques, the walker that traverses it, the customer API, and the record of every engagement. This is where the intellectual property lives and it never moves.
We bind and listen. The tunnel server is ours to run and ours to be accountable for.
Your side
One container per network segment. It dials out to us — you open no inbound ports — and it is deliberately unimpressive: a handful of Python files importing the standard library and one YAML parser.
It contains no graph client, and the protocol between us has no field that could carry one. What crosses is a rendered command and its result.
What the agent can and cannot do
Four properties, each enforced by the code rather than promised by the documentation.
- It runs a fixed set of programs, verified by hash
- Every tool's SHA-256 is re-checked before every command, not once at boot. A binary swapped underneath the agent is refused the next time it is used. The toolchain is derived from your engagement's own scope, so an assessment that only reads gets an image with no exploitation tooling in it at all.
- It has no self-update path
- The container cannot fetch a new tool, a new version, or a new instruction set mid-run. Changing what it can run means building and shipping a new image.
- It re-validates every command it is handed
- The agent does not trust our side. It checks each command against its own frozen rules and its own copy of what the engagement permits, and refuses anything outside them — including if the instruction came from us.
- It leaves you your own audit
- Every command — executed, refused, or gated — is recorded on both sides of the connection: our record and one written on your own hosts, with credentials redacted from both. You do not have to ask us what we did.
The engagement is the grant
Nothing runs that a manifest does not authorise. It names the scope, the specific permissions granted, a time window, and a switch that stops everything.
The manifest is a file you approve, out of band. We are deliberately precise about what that does and does not mean: nothing in this system attests who wrote it or that anyone signed off on it. The approval is yours and it happens outside the software.
What the platform does prove is integrity. The manifest's bytes are hashed onto every audit record, so a completed run can show exactly which text governed it — and an evidence pack that shows you a manifest can prove it is the one the commands actually ran under, rather than one edited afterwards.
- Scope is checked twice — when a value is bound to a command, and again on the rendered command before it executes.
- Permissions are exact-match and do not persist between engagements.
- Anything lateral or destructive needs a second sign-off, beyond merely being listed.
- The kill switch is checked before every command and can be flipped mid-run without editing the manifest the run is audited against.
- Teardown revokes the agent's certificate, scrubs harvested credentials, and leaves nothing behind. The findings are the deliverable.
What is signed, and what is not
The agent image is signed with cosign and pinned by digest, and its bill of materials is readable off the image itself. Three limits travel with that and we would rather state them than be asked:
- The signature binds to one registry path.
- There is no transparency log entry, so nobody can independently check when it was signed.
- The base operating system layer is pinned by tag rather than digest, so a rebuild is not guaranteed to be byte-identical.
The engagement manifest is not signed, and we do not describe it as though it were. An image signature attests the runner. It says nothing about the authority the runner acts under, and conflating the two would tell you your consent was attested when nobody attested it.