AI-Native Continuous Adversarial Defense
Your attackers stopped scanning. They started reasoning.
An automated attack used to be fast and dumb. It is still fast. An agent can now infer your framework from an error message, guess how your auth probably works, form a theory about where that leaves you exposed, test it, and adjust — across many attempts at once. MergeWatch Adversarial Defense gives the defender the same kind of reasoning, from the inside, where the information is better.
Or see how it works firstPull request review is live today and free for qualifying open-source projects. Everything else on this page is what the waitlist is for.
One vulnerability rarely gets anyone in. A chain of five does.
Most security tooling is organized around findings: this package has a CVE, this endpoint lacks a check, this bucket is readable. Each one gets a severity and a ticket. Individually, most are unremarkable, and teams reasonably deprioritize them.
Real compromises are seldom one dramatic hole. They are an ordinary information leak, plus a permission that is slightly too broad, plus a dependency that behaves surprisingly under a specific input, plus a service that trusts a header it should not — assembled in an order nobody anticipated. Every link looked acceptable in isolation. Nothing in the toolchain was responsible for noticing the combination.
That assembly step is exactly what a reasoning attacker is good at, and it is the step no scanner performs.
The attacker is guessing. You are not.
An outside attacker reconstructs your system from scraps — response timings, error strings, header quirks, whatever a changelog gave away. They are inferring the architecture.
You already have it. The source. The dependency graph. The infrastructure definitions. The API surface. The authentication logic. Who can reach what. What changed last Tuesday and why. The defender has always held more information than the attacker and has rarely had a way to reason over all of it at once.
If something intelligent understood this entire system — not one file, all of it — what would it try first?
Adversarial Defense makes that a question your stack answers continuously, rather than one a consultant asks twice a year.
From a list of findings to a model of the system
Six things happen continuously. The point of connecting them is that a finding only becomes interesting in the context of the others.
Map the stack
Code, dependencies, frameworks, APIs, infrastructure, data stores, third-party integrations — kept current rather than captured once in a diagram nobody has opened since.
Watch what changes
Pull requests, commits, dependency bumps, configuration edits, deployment topology. New risk is judged against the system it is landing in, not in isolation.
Form attack hypotheses
Ask how observable behavior, implementation detail, privilege and known weakness could be combined into something that actually works.
Rank by consequence
Likelihood, blast radius, reachability, privilege escalation, business impact. A ranked shortlist you can act on beats an exhaustive list you cannot.
Test only where authorized
Selected hypotheses validated in staging or explicitly approved environments, inside boundaries you define. Never a surprise.
Return it to the pull request
Findings surface where the change is being made, while it is still cheap to change — not in a report that arrives three sprints later.
Why this starts at the pull request
Not because review is the whole answer — because it is where new risk enters, and because it is the one place a system is explained while it changes. A pull request carries the intent, the diff, and the context in one artifact.
Reviewing there has a second effect that matters more over time: the model accumulates an understanding of the codebase as a by-product of doing something useful today. Each subsequent capability needs that foundation.
Where this goes
- 1
Pull request review
Live todaySecurity, correctness and reliability review on every change. Free for qualifying open-source projects.
- 2
Repository understanding
PilotPersistent knowledge of the codebase, its architecture and its history, instead of judging each pull request from scratch.
- 3
Stack-aware model
PilotRepository knowledge joined to infrastructure, APIs, cloud configuration, data stores, authentication and external services.
- 4
Attack-path generation
PilotSpecialized agents propose plausible chains across the real architecture, and rank them by what they would actually cost you.
- 5
Controlled defensive testing
PilotSelected hypotheses validated where you have authorized it, under policy and guardrails.
- 6
Continuous adversarial defense
PilotA standing internal model that re-reasons whenever the code, the infrastructure, the dependencies or the behavior move.
Specialists, with something coordinating them
Each agent understands one dimension properly. An orchestration layer decides which hypotheses are worth pursuing — the useful work is in choosing, not in scanning everything indiscriminately.
Stack Discovery
Builds and maintains the technology and dependency map
Code Security
Reads code, commits and pull requests for exploitable behavior
Dependency
Tracks vulnerable versions and dangerous combinations of them
Infrastructure
Cloud configuration, permissions, exposure, secrets, topology
API Attack
Models how exposed interfaces get abused or chained together
Attack Chain
Assembles findings across components into multi-stage paths
Adversarial Simulation
Asks what a capable external attacker would infer and try next
Behavioral Testing
PilotValidates selected hypotheses in authorized environments
Policy & Guardrail
PilotKeeps every test inside the boundaries you set
Open source is in the critical path
Core review is free for qualifying open-source projects, because a great deal of the world runs on libraries maintained by people with no security budget and not enough weekends.
It is also, candidly, how the models learn. Open-source work exposes MergeWatch to a far wider range of real architectures, dependency habits and failure modes than any private customer base would. That breadth is what stack-aware defense needs. Saying so seems better than pretending it is purely altruism.
Reasonable questions
Is this a vulnerability scanner?
No. Scanners are genuinely useful and you should keep yours. What they mostly do is inspect one slice of a system at a time — this dependency, that endpoint, this configuration file. Adversarial Defense is aimed at the other problem: maintaining a model of how the pieces fit together, so it can reason about a chain that no single slice looks dangerous on its own.
Does this replace penetration testing?
No, and we would not claim otherwise. A pen test is a skilled human adversary with judgment we cannot replicate. The gap we are trying to close is the months between tests, when the architecture keeps changing and nobody is asking adversarial questions of it.
Will it run attacks against my production systems?
Only where you have explicitly authorized it, inside boundaries you set. The design assumes staging and test environments by default. Controlled testing is a pilot capability, not something that ships switched on, and it is gated by a policy layer rather than by our good intentions.
Why start with pull request review?
Because that is where new risk enters. A pull request is the moment a system changes, and it comes with the context you need to judge the change — what it touches, what it depends on, what it used to do. Reviewing there also means the model accumulates an understanding of the codebase as a side effect of doing something useful today.
What actually works today, and what am I joining a waitlist for?
PR review is live, in production, and free for qualifying open-source projects. Everything described on this page beyond that — stack modeling, attack-path generation, authorized testing — is what the waitlist is for. We would rather tell you that plainly than let a landing page imply otherwise.
How does this relate to the open-source program?
The open-source program is the live product and, honestly, part of how the models learn. Maintainers get frontier-model review on code the ecosystem depends on; we get exposure to a far wider range of real architectures than a private-only customer base would ever show us. Adversarial Defense is where that understanding is heading.
Join the Adversarial Defense waitlist
We are looking for teams who already suspect that periodic scanning is not keeping pace: security-conscious startups, regulated engineering teams, platform and DevSecOps groups, and maintainers carrying infrastructure a lot of people depend on.
Early conversations shape what gets built first. If you have a specific fear about your own stack, that is the most useful thing you can bring.