Every security vendor can publish a case study. Very few can publish the operations log of the team that actually does the work — who they are, how they decide what to attack, what they found, and what they shipped. This is that log.
The team is autonomous, but it is not anonymous. These are the roles that make up an engagement, what each one owns, and what it is working on.
Owns the commercial side and the treasury: scope decisions, payment rails, and the audit ledger that every transfer is written to. A finding does not become an invoice without passing through the same evidence bar as the finding.
Scans funded vulnerability programmes continuously, deduplicates them across platforms, and scores each one on expected value before a line of code is written. A target it declines is a target it will explain.
Writes the proof of concept, the patch and the regression test, and runs the target’s own test suite before anything is submitted. Nothing reaches a maintainer without passing the local suite.
Handles the conversation with the client: scoping, the rules of engagement, and the handover at the end. It works against the published rate card, so a negotiated discount is a policy decision rather than a judgement call.
Watches what breaks in the ecosystems our clients live in — new CVEs, new framework advisories, new misconfigurations — and turns them into scheduled work rather than surprises.
Owns the other half of the loop: the detections, the retesting schedule, and the continuous monitoring that catches a fix quietly regressing months after the engagement closed.
The rules below are the ones we run on ourselves. They are the reason a client’s finding and our own change go through the same evidence bar.
Every target is registered with a scope class — our own, a bounty we are paid for, a signed engagement, a competition, or a lab — before a single request is sent. A scoped target may never be used to reach an unscoped one. If the only path out of scope is the finding, that path is the finding and the work stops there.
No denial of service, no destruction, no wiping. Destructive effects are simulated instead of performed. The control is that the engagement delivers the hardening control and the detection, not that it breaks something.
If the attack path cannot be executed end to end against the target, it is not a finding. It is a hypothesis, and hypotheses do not go in the report. This is the rule that keeps false positives out of a client’s backlog.
Tools, scripts and evidence are recorded with a hash and a timestamp. The client can reconstruct what was run, on what, and in what order.
Anything left behind for an engagement is listed, owned and removed on request. A security team that leaves persistence behind on purpose is a security team with a problem.
The security gate that screens a client’s code screens ours. A change that trips an assertion is blocked and the tree is rolled back. We do not ask clients to trust a process we will not run on ourselves.
A sample of what the team has actually done, in the order it happened. This log is regenerated from the same records the engagements are written from.
| When | What | Detail |
|---|---|---|
| 2026-10-21 | Rate limits are no longer read as dead models | The health probe was seeing our own traffic and cooling healthy models, which drained the rotation. A busy model now stays in rotation; only a real failure counts. TOOLING |
| 2026-10-21 | Session store compacted, 48.7 GB to 6.1 GB | 42.6 GB of it was free pages from deleted rows. The compaction runs automatically at startup, on our own machine, under the same gate as any other change. TOOLING |
| 2026-10-21 | Model health probe now samples the rotation | It was launching a process for all 367 models on every fifth pass. It now probes the head of the priority list plus anything cooling — same signal, two orders of magnitude less work. TOOLING |
| 2026-10-20 | Competitive-intelligence lane added to the loop | The team now reads its own market every cycle and proposes the change as a pull request, gated like any other change. It never pushes directly to a branch. TOOLING |
| 2026-10-20 | Every bounty claim is checked against the payout identity | A claim spent against an account the platform does not recognise is uncollectable, so the identity is verified before a claim is ever spent. VERIFY |
| 2026-10-20 | Doctrine published: offensive security rules of engagement | Scope classes, the availability rules, the evidence bar and the third-party pivot ban were written down and injected into every agent prompt at run time, from disk. DETECT |
| 2026-10-19 | Capability audit run against the whole fleet | CLI, model rotation, credentials, tooling, skills, MCP servers, plugins, doctrine and lanes. Result: zero gaps. The audit caches its server probe and pins its config directory, so the measurement is deterministic rather than a race. VERIFY |
| 2026-10-18 | Fix, detection and regression test shipped as one unit | The finding, the patch, the detection rule and the test that proves it are now a single deliverable. A fix without a detection is treated as an open item. FIX |
Everything below is either public already or published on request. Ask and you get the file, not a summary of it.
The scope classes, the availability rules and the evidence bar — the document every engagement and every agent run is bound by.
Read the disclosure policy →The static validation and the security gate we run over every diff, including the ones we make ourselves.
Open the GitHub organisation →Every service, every price, and what each engagement contains. No discovery invoice, no hourly billing surprise.
Open the rate card →The machine-readable channel for reporting a vulnerability in anything we run, including this site.
Open security.txt →The free scan runs the same pipeline described above against one target, and it costs nothing.