Your always-on red team.

Our AI agents attack your product continuously and surface attack paths nobody was looking for. An engineer proves each one by hand before you see it.

Talk to the founder →

A 20-minute conversation with a founder. No pitch deck, no SDR.

greywatch-harness — live

$ harness run --target acme-health.com

[08:42:01] mapping surface… 38 endpoints

[08:42:19] probing auth boundaries

[08:43:04] testing /api/patients/:id

[08:43:07] ! IDOR — read any patient record

[08:43:07] ! severity: CRITICAL

[08:43:12] engineer review queued

[09:20:44] ✓ exploit reproduced · fix recommended

The short version

What is continuous offensive security?

A red team attacks your product the way a real adversary would. Ours never stops: AI agents run the attacks around the clock, and an engineer proves every finding before you see it. That is what we mean by continuous offensive security.

The offensive half is what separates it from an audit. An audit checks your controls against a list. Offensive testing tries to break them, and either gets in 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.

The platform

The platform you run it from.

Upload assets, choose what we can touch, and watch every probe. Depth is inferred from what you connect, never a setting.

Greywatch

OverviewFindings1Assets14RulesIntegrationsTeamSettings

Testing paused

First cycle complete · 17 attack paths queued · map still live

Continue testing

acme-health.com / OverviewPaused

Overview

Last tested 2h ago · 14 hosts mapped · 0 new hosts since yesterday

Open critical1GW-001 · open 2h · unassigned

Assets under test1413 active · 1 out of scope

Testing depth2·1·11WGB white · grey · black

Harness statePaused17 paths queued for next cycle

Critical

Any signed-in patient can read any other patient’s record

GW-001 · api.acme-health.com · open 2h · unassigned

Open finding

Open findings by severity

Critical1

High0

Medium0

Low0

Upload assets

Domains, subdomains, repos, APIs. Add what you want tested and mark anything out of scope.

Domains & subdomains · 14

api.acme-health.com1 critical

staging-api.acme-health.comneeds a test user

+ add a domain or subdomain

Provision access

A test user, a read-only repo, an architecture diagram. Connect what you are comfortable with. Depth is inferred from what you share, never a setting.

To go deeper, we still need

A test user for staging-apiadd →

Your architecture diagramupload →

GitLab / Bitbucketconnect →

Set rules

Decide what the agents may touch and when. The harness pauses after each cycle and does nothing you have not authorised.

Scope & rules

Test production hosts

Exclude third-party hosts

Pause after each cycle

View reports

Every finding carries its evidence, reproduction steps, CVSS score and a suggested fix. Download the report, retest on demand.

GW-001 · Critical · Validated

GET /api/patients/<other-id>

← 200 OK · name, dob, insurance_id

Validated by a Greywatch engineer · 1 sample, redacted

Review logs

Every probe we run, timestamped and attributed. Replay it. Export it. Reconcile it against your own telemetry.

Probe log · exportable

[08:43:04] testing /api/patients/:id

[08:43:07] ! IDOR · read any patient record

[08:43:12] engineer review queued

Integrations

Findings land where your team already works. A Jira ticket from a finding, a Slack alert the moment we validate one.

Integrations

Slack · #eng-securityconnected

GitHub · 2 reposread-only

Jira · create ticketsconnect

Also: team roles for who fixes what, retest on demand, shareable findings, Jira tickets straight from a finding, light and dark mode.

The agents

How it actually works.

5 stages, running in a loop. Not a scan - 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 agents chain what they learned and re-probe. They do 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.

A working exploit

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 agents run around the clock; the people who verify their 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.

Read a real teardown →

Engagement models

Start wherever you are.

How much access you give us decides who we play: an outside attacker, a malicious user, or an insider. Start at any level and move between them whenever you like.

Blackbox

No access. We start where an attacker starts.

See Blackbox →

Greybox

Some access: accounts, keys, a sandbox.

See Greybox →

Whitebox

Full access: source, infra, environments.

See Whitebox →

Process and controls

Always-on offense. Never unsupervised.

You are letting something attack a production system. Here is exactly what governs it. Agents attack. The harness keeps them in bounds.

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. You set the scope yourself, in the dashboard.

Human validation

One of our engineers 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. It lives in the dashboard.

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 our agents: more surface patterns, better hypotheses, fewer dead ends. Judgement an engineer supplies today is progressively encoded into the system.

Proof of work

Our AI agents have found real vulnerabilities in growing product companies

Confirmed findings from engagements and responsible disclosures.

Ada Health

Casca

Adra

Empallo

Ada Health

Casca

Adra

Empallo

Freya Voice

Jupid

Freya Voice

Jupid

From our customers

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

Questions

What teams ask before they start.

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. AI agents map the running product, form attack hypotheses, and test 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.

Do I have to give you access to my systems?

No. You choose how much access to share, from none to full. Blackbox needs nothing beyond scope and permission. Greybox adds whatever you are comfortable sharing, such as test accounts or a sandbox. Whitebox adds source and infrastructure. You can start at any level and move between them.

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?

No. Every finding ships with a recommended fix written by the engineer who exploited it - the specific change, not generic remediation guidance. Your team implements it. Even with Whitebox access we only read your code; we never change it.

What does it cost?

3 plans by access level: Blackbox at $1,500 a month, Greybox at $3,000, Whitebox at $6,000. Or try us for 3 months and pay only if we find a Critical or High vulnerability.

Get in touch

Talk to the founder.

Tell us what you're building and what you're worried about. You'll hear back from a founder, not a sales rep.

✓ Thanks for reaching out. We'll be in touch shortly.