Is it safe to run against production systems?

The scope is agreed before the first probe: which hosts, environments, paths and methods are in play, and what is explicitly out of bounds. The harness runs inside those guardrails, every probe is logged and attributed, and the logs are exportable so your team can reconcile activity against their own telemetry.

Does Greywatch access our customer data?

No. Proving a finding means demonstrating that a control fails, not extracting the data behind it. Where a finding involves exposed records, we record the count and a single redacted sample, then stop. We retain the attack path and the attack logs so your team can verify and fix; anything else encountered in the course of testing is discarded.

Do you fix the vulnerabilities you find?

Every finding ships with a recommended fix written by the engineer who exploited it. Whether we implement it is your call: most teams take the fix and apply it themselves, and a forward-deployed engineer can raise the pull request in your codebase if you would rather it was off your plate.

Continuous Offensive Security: How It Works

Q: What is continuous offensive security?

Continuous offensive security is the practice of attacking your own product on an ongoing basis, the way a real adversary would, rather than testing it once a quarter. An AI harness maps the running product, forms attack hypotheses, and tests them continuously; a security engineer reproduces anything it finds before it is reported. The output is a small number of confirmed, exploitable findings with the steps to reproduce them and a recommended fix.

What is continuous offensive security?

Continuous offensive security means attacking your own product on an ongoing basis, the way a real adversary would, instead of testing it once a quarter and hoping nothing moved in between.

The offensive half is what separates it from an audit. Nobody reads your code or walks a checklist. Someone tries to get in from the outside, with no more access than a stranger has, and either succeeds or does not.

The continuous half matters because an attack surface is never static. Every deploy, every new endpoint, every dependency bump changes what is reachable. A test that ran last quarter describes a product that no longer exists.

How it actually works.

5 stages, running in a loop. Not a scan of your codebase - an attack on the product you shipped.

Reconnaissance

Maps what you actually shipped: reachable endpoints, auth boundaries, storage origins, and the subdomains your own inventory forgot.

38 endpoints · 4 auth boundaries · 11 unlisted subdomains

Attack hypotheses

Matches that surface against our hypothesis library and ranks what is most likely to land here, then asks the model for attacks the library has never seen.

240 generated · 17 promoted · 3 novel

Agents test in parallel

Every promoted hypothesis gets its own agent, probing simultaneously inside the agreed scope.

17 agents · concurrent

Iterate

A failed hypothesis is information. The harness chains what it learned and re-probes. It does not stop at 1 pass.

14 failed → re-probe → break

Validate

A candidate is not a finding. An engineer replays the exploit by hand. Anything that cannot be replayed dies here and is never reported.

no replay → no report

Security engineers backed by an AI research team —
not an AI tool pretending to be one.

What 1 loop actually looks like.

A single engagement against a placeholder target, start to finish.

09:002h

Reconnaissance

Certificate transparency logs, DNS records, shipped JS bundles, mobile binaries, storage origins. The asset map is built from what is actually reachable, not from what an inventory says exists.

38 reachable endpoints4 auth boundaries11 subdomains absent from the customer's own inventory

11:009m

Attack hypotheses

The mapped surface is matched against our hypothesis library and ranked by what is most likely to land against this architecture. The model is then asked for hypotheses the library has never seen.

240 candidates generated17 promoted for testing3 novel, outside the library

11:092h 24m

Parallel testing

Agents take a hypothesis each and probe simultaneously inside the agreed scope. 14 fail outright. Each failure narrows the next attempt rather than ending the run.

13:33the moment

Break

IDOR on /api/patients/:id. A record belonging to another account comes back. This one was a library hypothesis, ranked 3rd.

13:332h 39m

Queued for review

The candidate sits in the queue until an engineer is free. The harness runs around the clock; the people who verify its work do not. Nothing leaves the harness during this window.

16:1241m

Human validation

An engineer replays the request by hand and establishes blast radius: which accounts, how many records, what an attacker could do with it. Candidates that cannot be replayed die here.

16:53confirmed

Proved

Confirmed exploitable. Reproducible by hand, with a known blast radius and a severity an engineer will stand behind.

17:40delivered

Report written

The engineer who broke it writes it up: the request that worked, what came back, step-by-step reproduction, blast radius, and the fix that closes it.

Reproduction, as delivered

$ curl -H "Auth: <user-a>" /api/patients/8815

← 200 OK · returns patient 8815

user-a is not patient 8815. Count recorded, 1 sample redacted, nothing extracted.

Every finding you receive has been through all 8 steps.
Nothing skips validation.

Always-on offense. Never unsupervised.

You are letting something attack a production system. Here is exactly what governs it.

Rules of engagement

Scope is agreed before the first probe: hosts, environments, paths, methods. Allow and deny lists are enforced by the harness, so out-of-scope systems are unreachable, not merely discouraged.

Human validation

An engineer is in the loop on every finding. No reproduced exploit, no report. Candidates that cannot be replayed by hand die in review and never reach you.

Audit rights

Every probe is logged, attributed and timestamped. The log is replayable and exportable, so your team can reconcile our activity against their own telemetry.

Data handling

We do not extract your customers' data. Where records are exposed we record the count and 1 redacted sample, then stop. We retain only the attack path and logs.

Model routing

Recon, hypothesis generation and exploitation each go to whichever model performs best at that task, rather than forcing a single general-purpose model to do all of it.

The training loop

Every engagement sharpens the harness: more surface patterns, better hypotheses, fewer dead ends. Judgement an engineer supplies today is progressively encoded into the system.

What it looks like from the other side.

“

We were focussing on our usual product roadmap and didn't think beyond our quarterly VAPT reports. Greywatch proactively found exploitable vulnerabilities our usual vendor never caught, and now we run their continuous security platform on all our assets. Highly recommend working with them!

Adarsh Tadimari

Co-founder & CTO, Plotline

Find out how an attacker will eventually break in.

What is continuous offensive security?

How it actually works.

What 1 loop actually looks like.

Always-on offense. Never unsupervised.

Our harness has found real vulnerabilities in growing product companies

What it looks like from the other side.

Talk to the founder.