We work on what ships.

That focus comes from an unglamorous observation. By the time software matters enough to attack, it has usually been reviewed already — audits happened, scanners ran, a competent internal team looked. What remains is not found by looking again the same way. It is found by looking at a different artifact, with different tools, and being rigorous about knowing where you actually looked.

Who

We are a security research firm specializing in binary exploitation — memory corruption, privilege escalation, sandbox escape — and in network and protocol research across firmware, low-level systems and, more recently, AI agent deployments.

The practice is deliberately small. When you hire us, the person who reads your code is the person you talked to. There is no bench, no handoff to a junior, and no name on the report that did not do the work.

How we run an engagement

Most security consultancies sell an expert’s intuition. It genuinely works, it is unaccountable, and every competitor claims it. We would rather sell something you can check.

1. Scope becomes a ledger

Before any code is read, the engagement is enumerated as a matrix: every surface on one axis, every vulnerability class that could apply on the other. Each cell gets a weight — how novel the code is, how much value is reachable through it, how well prior review already covered it.

This happens before hunting starts, and it is built from the complete scope rather than from whatever changed recently. Novelty is the best signal for what to look at first; it is a terrible way to decide what to look at at all. A ledger seeded from a diff produces a confident “we covered everything” over a fraction of the target.

2. Breadth before depth

Every cell gets a first pass before any cell gets a deep one. This is the discipline that prevents the most common failure in security work: latching onto the first interesting thing and leaving the rest of the scope thin — while the engagement feels productive throughout.

Depth is then allocated in expected-value order, time-boxed per lead, with unresolved leads requeued rather than quietly abandoned.

3. Every zero is controlled

This is the part that matters most and gets discussed least.

A scanner that finds nothing and a scanner that is silently broken produce identical output. We have seen a static analyzer exit successfully having analysed a quarter of the codebase because it could not resolve imports; a live-state query return “no privileged accounts” because the request was being rejected; and a shell quoting quirk turn twenty-seven differing files into “zero differing files”.

Every one of those looked exactly like good news. Every one of them ended an investigation instead of starting one.

So before any “nothing found” is written down, we run a positive control — a probe we know must return something through the same code path. If the control comes back empty, the tool is broken, not the target clean. Controls are recorded next to the verdict, so you can check the reasoning rather than only the conclusion.

4. Findings are validated before you see them

Every candidate passes a fixed set of gates: is the trigger actually reachable by an untrusted party, does anyone actually profit, is the impact real against current state, is it already known. A finding that fails a gate is either reframed honestly or dropped — it does not get inflated to fill a report.

If we find nothing, we will say so, and show you where we looked.

5. You get the ledger

The deliverable is the findings and the completed matrix: every surface, every class, every verdict, with the evidence — including the cells that came back clean.

That is the part clients tell us they cannot get elsewhere, and it is the part that is actually load-bearing for a ship decision.

On our tooling

We build and operate a multi-agent research pipeline: automated discovery and triage, a coverage ledger enforced as a script rather than a paragraph, and a positive control behind every empty result.

It is not a magic oracle and we do not treat its output as ground truth. Its value is coverage and consistency — it does not get bored on the fortieth surface, and it cannot quietly skip a cell. Judgement about what a finding means stays with the researcher.

Building it is also why we assess agent deployments for other people. The dominant failure mode in agent systems is not the dramatic jailbreak — it is the silent one, where a tool returns nothing because it was misconfigured and the agent proceeds confidently on an absence. We have hit every version of that in our own systems. What that assessment covers →

What we will not do

• Overstate a finding. If exploitability was not demonstrated, the report says so. A severity we cannot defend is worse for you than an accurate lower one.
• Publish your name without permission. Research is anonymized to target class by default.
• Publish during embargo. Ever, for any reason.
• Release working exploits for unpatched issues.
• Take an engagement we are not the right people for. We will say so and, where we can, point you at someone better suited.

Disclosure policy

We publish research. It is how the practice stays sharp and how clients find us. It is also a risk you are entitled to control, so the rules are fixed and written down:

• Client work is anonymized by default — target class, never target name, unless you approve otherwise in writing.
• Nothing publishes during embargo. Embargoed work is published only as a stub: target class, date reported, status, no technical detail.
• Coordinated disclosure, following your policy where you have one.
• PoCs publish only after a fix ships, redacted where warranted.
• Credit to you only with permission. Credit to other researchers always.

If your requirements are stricter than this, say so at scoping and we will write it into the engagement.