Autonomous red team and blue team — running every day

We break in.
Then we ship the fix.

Most security vendors hand you a report and an invoice. We attack your systems continuously, prove what we actually found, and hand back the patch, the detection that catches it, and the test that stops it coming back.

Free scan of your repository or deployment within 48 hours. Engagements from $500. No account, no sales call.

01 ATTACK Adversary emulation Chained techniques against a real target, not a checklist.
02 VERIFY Reproduced end to end If we cannot execute the attack path, it is not a finding.
03 PATCH The fix, as a diff Landed in your repository, passing your own test suite.
04 DETECT The rule that catches it Detection engineering, tested before we call it done.
05 PROVE Regression test Fails before the patch, passes after. The fix is closed.
379
Security assertions on our own code
automated gate, every commit
24/7
Continuous adversary emulation
not a quarterly window
<48h
Free scan, request to report
no account required
100%
Findings shipped with a fix
plus detection and test

Verified, not asserted

A claim you cannot check is a slogan. Every promise on this page points at something you can open, run, or hold us to.

The gate that screens your code screens ours Our own engineering runs through an automated security gate: hundreds of assertions over every diff, a blocked and rolled-back change if one trips, and a published check that the gate still passes. We sell the gate because we run it on ourselves first. See the live operations log →
Our rules of engagement are written down Every target we touch is registered with its scope class before a single request is sent. What we may test, what we will not touch, and how a third party is off-limits are all fixed in advance — in writing, before the engagement starts, not after something goes wrong. Read the disclosure policy →
You can reproduce every claim yourself Findings ship with the exact request and response, the command output, and the reproduction steps. If our evidence does not convince you, it is not evidence — so we give you all of it and let you run it. See the evidence format →
Our tooling is public The validator, the gates and the research tooling we use on ourselves are open source. You can read the controls before you trust us with anything, and you can hold them to the same standard you hold your own suppliers to. Open the GitHub organisation →
✓ Free — no account, no sales call

Point the scanner at your repository.
Get something real back.

Send us a public repository or a deployment URL. You get a verified report — attack paths we actually executed, the evidence, the patch, and the detection — at no cost, with nobody asking you to book a meeting.

We only use what you send to test the target you named. It is never used to train a model and never shared. Read the privacy policy.

  • ✓
    A verified finding, not a scanner guess Every issue we report was reproduced against the running target. If we could not execute it, it is not in the report.
  • ✓
    The exact request that reproduced it The request, the response, the status code and the bytes — copy-pasteable, so you can confirm it in one command.
  • ✓
    A patch, not a paragraph about a patch The fix as a diff against your code, tested against your own suite before we send it.
  • ✓
    The detection that would have caught it The rule your SIEM needs, plus the test proving the rule fires on the activity you actually generate.

Why not just point an LLM at your repo?

You are right to ask, and we should answer it before you ask it. A good model can read your code and describe a vulnerability. That is genuinely useful, it is fast, and it is not nothing.

A model on its own

  • Describes a plausible vulnerability in code it has read, without a running system to prove it against.
  • Cannot execute the attack path, so a theoretical issue and a live breach look identical in the output.
  • Cannot run your suite, so the fix it proposes is unproven against the code you actually ship.
  • Leaves you with prose. A paragraph about the fix is not a fix, and no detection is written to catch the next attempt.
  • Has no memory between runs, so the same regression is re-discovered every quarter at full price.

An autonomous team, with a gate

  • Executes the attack against your running system and keeps the raw request and response as evidence.
  • Refuses to report anything it could not reproduce — a finding is a proven path, not a suspicion.
  • Lands the patch in your repository as a diff, and runs your own test suite before it reaches you.
  • Writes the detection and proves it fires, because a fix without a detection is a fix that silently regresses.
  • Remembers. Every fix we ship is re-tested on a clock, so a regression is caught by us before an attacker catches it again.
We are an LLM shop. We are just not an LLM only. The models do the reading, the writing and the reasoning. What makes the difference is everything around them: the scope registry, the evidence requirement, the gate that blocks a bad diff, and the refusal to call something a finding until it has been proven. That machinery is the product, and it is the part you are buying.

One finding, end to end

A redacted example from a real engagement class: a cross-tenant read in a multi-tenant API. This is the shape of every finding we ship. The report is one page — the other four artefacts are what make it worth paying for.

01 — ATTACK

We reach it

The object identifier is ours to change. We change it and watch what the service says.

# tenant A requests tenant B's order GET /api/v1/orders/9812 Authorization: Bearer <token_A> 200 OK { "id": 9812, "customer": "Beta Holdings", "total": 41200, "status": "shipped" }
02 — VERIFY

We prove it

One request, no retries, no race condition, no fluke. It returns another customer's data, every time.

# same token, foreign id, 10/10 200 foreign_id=9812 200 foreign_id=9813 ... 200 foreign_id=9821 # tenant check on the id: missing # /api/v1/orders/{id} never compares # owner_id against the session
03 — PATCH

We fix it

A diff against your code, in your repository, passing your own test suite. Not a paragraph about a diff.

- order = Order.objects.get(id=id) + order = get_object_or_404( + Order, + id=id, + tenant_id=request.tenant.id, + )
04 — DETECT

We make it visible

A fix without a detection is a fix that silently regresses. We ship the rule and prove it fires.

# detection: cross-tenant read attempt when (route == "/api/v1/orders/*" and status == 200 and order.tenant_id != session.tenant_id) alert("precog.idor.cross_tenant_read") block(response)
05 — PROVE

We close it

The regression test fails before the patch and passes after. Then we re-test it on every future cycle.

def test_cannot_read_other_tenant_order(client): r = client.get("/api/v1/orders/9812", headers={"Authorization": "Bearer A"}) assert r.status_code == 404 # before patch: 200 -> test fails # after patch: 404 -> test passes
That is the whole product. Not a dashboard, not a monthly PDF, not a severity score. A proven path, a fix, a detection and a test — and the evidence for all four, in your repository, where your team owns it.

BlueHound security assistant

Download the free 3D digital security assistant. Runs locally, talks to your repo, scans IPs, looks up CVEs, and maps attack paths. Upgrade to Pro ($19 / month) for unlimited scans, PDF reports, attack-path mapping, and the premium 3D avatar.

Security services

Every service below runs the same loop: attack, verify, patch, detect, prove. The difference is the scope and the depth.

🔍

Penetration Testing

Adversary emulation against a scoped target — web, API, cloud, network or mobile. Chained techniques, not a checklist scan, with every finding reproduced before it is reported.

From $500
🛡

Continuous Red Teaming

The same attacks, on a clock, against the surface you actually run. A fix that regresses is caught by us before an attacker catches it again.

24/7
🔒

Blue Team & Detection Engineering

The other half of the loop. We write the rules that catch the activity, test that they fire, and tune them against your real telemetry instead of a generic rule pack.

Detection as code
📦

Supply Chain Auditing

Static and dynamic analysis of dependency graphs, build pipelines and package registries. Compromised packages, typosquatting and insecure build configuration — found before they reach production.

CI/CD integrated
💻

Code Review as a Service

AI-assisted pull request review that catches security anti-patterns, injection risks, authentication flaws and cryptographic misconfiguration — before the merge, not after the incident.

GitHub integration
⚙

Security Tooling Development

Custom fuzzers, static analysers and CI security gates tailored to your stack. The components we build for clients are published under our GitHub organisation.

Open source

Priced in the open

No discovery invoice, no hourly billing surprise, no retainer you cannot cancel. Fixed scopes, published rates, and a free first scan so you know what you are buying before you buy it.

Free Automated Scan

$0 / first scan

One repository or deployment, scanned and attacked by our own agents, with everything we find verified.

  • Verified findings with the exact reproduction
  • The patch as a diff
  • A detection rule for what you find
  • No account, no call, no obligation
Delivered within 48 hours
Start with the free scan →

Focused Audit

$500 / audit

One repository or one application, attacked to a defined depth, with the fixes and a ranked backlog.

  • Everything in the free scan, plus full attack-path mapping
  • Dependency and secret exposure analysis
  • A ranked fix backlog you can schedule
  • A walkthrough with the engineer who did the work
3–5 working days · 1 application
Book an audit →

Continuous Monitoring

$1,200 / month

Autonomous scanning and retesting on a clock, so a fix that regresses is caught before an attacker finds it again.

  • Everything in the penetration test, on a clock
  • Automated re-testing of every fix
  • New attack surface triaged daily
  • A monthly detection backlog
Rolling · cancel any time
Set up monitoring →

Also available: supply chain and CI/CD audit, cloud and container posture review, blue team detection engineering, dirty room malware analysis, and clean room reimplementation. Full rate card →

You have three realistic options

A consultancy, a scanner, or an autonomous team that does both and ships the fix. Here is the honest comparison, including where the other two are the better answer.

  Classic consultancy Point scanner PreCog Security
First report delivered in Weeks, after scoping Minutes, unverified 48 hours, every finding reproduced
Who does the work One consultant, in a time window A rule engine An autonomous team, every day
Proves the attack path works Yes No Yes — or we do not report it
Fix included in the work No No Yes — as a diff in your repo
Detection shipped Sometimes, untested No Yes — and proven to fire
Regression test included No No Yes
Re-tested later Another engagement Another scan Every cycle, automatically
Cost for one application Quoted per engagement Subscription or free tier $500, published
Where the output lands A PDF A dashboard Your repository, yours to keep

Where the other two are the better answer: if you need a specific compliance attestation with a certificate behind it, or you need a named human to sign off for your board, book a consultancy. We do not issue those. Where you need an attack that is actually proven, a fix that is actually applied, and a detection that is actually tested, this table is the shortlist.

We do sell a scanner. The API behind it is free and open source, and it is the on-ramp, not the product: it finds candidates. It cannot prove the attack path, apply the fix, leave a detection behind, or remember what it fixed last quarter — which is the rest of this table.

Six steps, and none of them is "write a report"

The same pipeline every time, whether the engagement is a $500 audit or a continuous engagement. You always know which step you are in.

01 — SCOPE

Written rules of engagement

What we may touch, what we will not, and how we contact you if something unexpected happens. Agreed in writing before a single request is sent.

02 — ATTACK

Adversary emulation

Chained techniques executed against your running system, using the paths a real attacker would take — not a signature checklist against a copy.

03 — VERIFY

Reproduce or discard

Every candidate finding is executed end to end. If the path does not work, it is not a finding — it is discarded, and it does not reach your dashboard.

04 — FIX

The patch, in your repository

The fix lands as a diff against your code, in a branch you control, and is run against your own test suite before you ever see it.

05 — DETECT

The rule that catches it

For every technique that landed, a detection is written and tested against real activity. We do not close a finding until the rule fires.

06 — PROVE

Regression test and retest

A test that fails before the fix and passes after it, plus a re-test of every fix we have shipped, so nothing quietly comes back.

Our machine publishes its own work

Most security vendors show you case studies written by a marketing team. We publish the operations log of the autonomous team that does the work — what it found, what it shipped, and what it changed this month.

Live operations

The swarm's public operations log

Every agent, every target class, every finding and every shipped fix — published as it happens, not case-studied six months later.

Open the operations log →
Method

How we decide what to attack

The triage rules, the evidence bar, the scope classes and the promotion criteria we use on ourselves — written down so you can audit them before you trust them.

Read the method →
Article

Why security scanning matters in 2026 — and what it still cannot do

Scanning is the cheapest control you will ever buy and it is worth having. It is also the control that finds things and leaves them there. The gap, in plain terms.

Read the article →
Programme

Coordinated disclosure

How we handle a vulnerability in someone else's code: triage, severity, timelines, and the rule that we do not publish before the responsible party has had a fair chance to fix it.

Read the disclosure policy →
OCT 2026 Model health probe now samples the rotation It was probing all 367 models on every fifth pass, which burned eighteen minutes of blocking work to answer a question the head of the list could answer.
OCT 2026 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, with the same gate every change gets.
OCT 2026 A rate limit is no longer read as a dead model Our own traffic was getting a healthy model cooled and the rotation drained. A busy model now stays in rotation.
OCT 2026 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.

Straight answers

Do you need access to our source code?

No. Black box testing against the running application is the default, and it is the more honest test. If white box access would produce a materially better result we will say so and scope it separately — we do not quietly ask for credentials we do not need.

Will you disrupt our production?

No. Availability is treated as a production dependency, not a test resource. No denial of service, no destructive action, no wiping. Where an engagement needs a destructive effect we simulate it instead, and we agree the rules of engagement with you in writing first.

What do we get at the end?

A report a CTO can act on: an executive summary, the findings with exact paths and working exploits, the fixes as diffs with regression tests, and the detections that would have caught the activity. Plus the raw evidence, so anyone on your side can reproduce every claim.

Why not just point an LLM at our codebase?

Because a model can describe a vulnerability but cannot prove the attack path works, cannot run your test suite, cannot write the detection, and cannot remember what it fixed last quarter. The full answer is here.

What happens if you find nothing?

You get a clean report that says exactly what was tested, how it was tested, and what was out of scope. That document is evidence of coverage, it is yours to keep, and it is more useful than a long list of theoretical issues.

How fast can you start?

The free scan is scoped within 48 hours of your request. Engagement start dates depend on scope, and we will tell you the real date rather than a hopeful one.

Do you train models on our code or our data?

No. What you send is used only to test the target you named, for your engagement. It is never used to train a model and never shared with a third party. We will put that in the engagement letter.

Can you keep our findings confidential?

Yes. Disclosing to the vendor is the default because it is what actually gets you fixed, but confidentiality is the norm and coordinated disclosure is standard practice — we do not publish a finding before the responsible party has had a fair chance to fix it.

Request an engagement

Tell us about the target and the deadline. We will scope it, price it against the published rate card, and tell you the real start date.

☎
Phone / WhatsApp +263 774 917 252 · WhatsApp
💰
Payment rails PayPal, EcoCash, bank transfer, BTC and ETH. Details are on the invoice — never sent by email.
🌐
⏱
Response time Within 48 hours for scoping requests, free scan included
🔒
Discretion Under NDA on request. Coordinated disclosure is standard practice, and we never publish before you have had a fair chance to fix.