Autonomy earns its scope by proving itself
The industry says attack is automating, so defence must match it on speed. We think speed is the less important half of that answer — and that what actually limits an autonomous security system is how much of its output you can trust without checking.
RedStrike's position is that the constraint on autonomous security is not machine speed — it is trust. An engine that finds faster without verifying produces noise faster, and a queue of unverified findings is work transferred to the customer, not work done for them. So the platform is built so that autonomy earns scope by proving itself: findings carry evidence rather than inference, active testing runs only inside recorded authorization, and exploit tooling sits behind an approval gate. This page states what ships today, what is being built, and what we will not do.
Starting point
The part everyone agrees on
Attack tooling is automating. Reconnaissance, credential stuffing, exploitation of newly disclosed vulnerabilities — the work that used to take a skilled person days is increasingly a pipeline someone runs, and the interval between a vulnerability becoming public and being exploited at scale keeps compressing.
Defensive testing has not moved at the same rate. The dominant model is still an engagement: a firm is scoped, a team tests for a week, a report arrives, and the system it describes has already changed. For a team shipping weekly, that is roughly one week of coverage in fifty-two.
None of this is a contested claim, and we are not going to dress it up with a statistic we cannot source. It is the starting point, not the argument.
The argument
Where we think the usual conclusion is wrong
The standard conclusion is that defence must match attack on speed — that the answer to automated offence is autonomous defence operating at machine pace, with humans moved out of the loop because they are too slow to stay in it.
Speed is half the answer, and the less important half. An engine that finds faster produces findings faster; if those findings are unverified, it produces noise faster. Anyone who has inherited a scanner queue of four hundred unverified results knows what that costs: the triage is skilled work, it never finishes, and the real finding sits somewhere inside the part nobody reached.
The binding constraint on an autonomous security system is not how quickly it can act. It is how much of what it produces you can act on without checking. Every increment of autonomy is only worth having if the output can be trusted without re-doing the work — and trust is not a property you can add at the end. It has to be the thing the system is built around.
So our position is narrower than the industry's and, we think, more useful: autonomy earns scope by proving itself. A system should be granted more independence exactly as fast as it can demonstrate its output is real, and not one step faster.
What follows from it
Four constraints we design against
Each one states a principle, then names what implements it today. If a principle has no implementation yet, it does not appear here.
Evidence, not inference
Most security tooling reports possibility. A scanner sees a version string associated with a CVE and reports the CVE, without establishing that the vulnerable path is reachable or the feature enabled. That report is true about a version and frequently false about your system, and the difference is paid for in engineering hours.
In the product today
Findings that come from inference are marked tentative and actively re-tested. The re-test returns confirmed, refuted, or unknown — and unknown stays unknown rather than being rounded to either side. Results from multiple tools are correlated into one issue, and severity is normalized to CVSS then weighted by CISA KEV membership and EPSS probability.
What a verified finding means →Consent, not access
An autonomous system pointed at infrastructure is only defensible if the boundary it operates inside was set deliberately, by someone entitled to set it. Rules of engagement are an attestation a customer makes about themselves — fine for an invoiced account a human vetted, and not sufficient on its own for self-serve, where a throwaway signup could otherwise aim active scanners at anything.
In the product today
Scope and rules of engagement are recorded before any test runs. Free-plan targets additionally prove domain ownership by DNS TXT record — control of the domain, not merely of one HTTP server on it. Cloud access is scoped, read-only role delegation with short-lived credentials; long-lived keys never leave the customer's environment.
How we constrain testing →A gate in front of the sharp tools
There is a real difference between confirming a door is unlocked and walking through it. Verification has to be non-destructive by default, and the tooling that is not — the exploitation frameworks, the injection tools — should not be something an autonomous agent reaches for on its own initiative.
In the product today
In agentic mode the engine can be run human-in-the-loop, pausing before any write or exploit tool and waiting for an explicit approve or reject. The run is checkpointed so the decision resumes the same graph rather than restarting it, and exploit tooling sits behind that gate specifically.
How testing runs →Accountability by construction
A consolidated list of an organisation's weaknesses is an attacker's roadmap. Who can read it, who ran what, and what an engine actually did have to be answerable from the system itself — not reconstructed afterwards from logs nobody kept.
In the product today
Tenancy is enforced with PostgreSQL row-level security, so isolation holds at the storage layer rather than depending on every query being written correctly. Stored cloud credentials are encrypted at rest, organisation-modifying actions are recorded in an audit log, and multi-stage findings carry a written narrative of the steps that were verified.
Isolation in practice →Where this goes
Three chapters, one of which exists
Chapter one is evaluable today. Two and three are direction, and carry no dates on purpose — a dated roadmap on a marketing page is a promise made to someone who cannot hold us to it.
Findings you do not have to check
Shipping todayThe first problem worth solving is not autonomy, it is trust in a single finding. Until a result can be acted on without being re-derived, nothing built on top of it compounds.
- Continuous testing across applications, APIs, networks, containers, mobile builds, and AWS, Azure, and GCP accounts.
- Tentative findings actively re-tested; results correlated and de-duplicated across tools into one issue.
- Severity normalized to CVSS, weighted by CISA KEV membership and EPSS exploitation probability.
- Findings mapped to ten compliance frameworks, with the edition pinnable to the one an assessment runs against.
- Evidence exported as PDF, HTML, Markdown, JSON, CSV, SARIF, OpenVEX, and OSCAL.
Reasoning about chains, not just findings
In progressA list of individually-scored weaknesses is not a description of risk. What matters is reach: which combination of small things, taken in order, gets someone to the thing that would actually hurt. That means representing a path — its stages, which of them were verified, and what it reaches — rather than ranking findings in isolation. The agentic engine and multi-stage attack-path modelling are where this work sits today. Treat it as direction, not as a feature list.
Autonomy that earns its scope
Where this goesThe end state we are aiming at is not an engine that acts without people. It is one whose independence is bounded by what it can prove. An engine that proposes an action, demonstrates the finding behind it is real, and operates inside a boundary a person set — with human judgement spent on where the boundary goes rather than on approving each step inside it. We are describing a direction, not announcing a product, and there are no dates attached to this deliberately.
Commitments
Five things we will not do
A vision is cheap. These are the constraints it costs us something to keep, and most of them are already enforced in the codebase rather than by good intentions.
We will not claim zero false positives
Verification removes the large class of results inferred from a version string. It does not remove judgement about whether a confirmed weakness matters in your context, and any vendor promising zero is overstating. Our own marketing copy is checked against a list of claims we have decided not to make.
We will not test anything without recorded authorization
Scope and rules of engagement are recorded before a scan runs, and free-plan targets prove domain ownership by DNS record first. Active testing without recorded permission is a liability we are not going to make convenient.
We will not describe a roadmap item as a shipped feature
Chapters two and three on this page are labelled as direction because that is what they are. If you are evaluating us, evaluate chapter one — and ask us directly about anything in the other two rather than assuming it exists.
We will not round our coverage up
Framework-labelled cloud rulesets run on AWS; Azure and GCP are graded against CIS Foundations benchmarks. That asymmetry is stated on every page that touches compliance rather than being smoothed into 'multi-cloud ready', and the pages render it from the same source the product does so the two cannot drift apart.
We will not hand an exploit tool to an unattended agent
Exploitation tooling sits behind an approval gate. An agent can reach the point of proposing it; a person decides whether it runs. We do not think that constraint is a limitation to be engineered away — it is the thing that makes the rest defensible.
FAQ
Frequently asked questions
Questions about where RedStrike is going, and what exists now.
Is this a product roadmap?
No. Chapter one describes what ships today and can be evaluated now. Chapters two and three describe direction, deliberately without dates, because a dated roadmap on a marketing page is a commitment made to people who cannot hold us to it. If a specific capability matters to your decision, ask us and we will tell you plainly where it actually is.
How is this different from other autonomous pentesting vendors?
Most of the category argues that attack is automating so defence must match it on speed. We think the binding constraint is trust rather than speed: an engine that finds faster without verifying produces noise faster. That leads to different design choices — active re-testing of inferred findings, approval gates in front of exploit tooling, and coverage limits stated rather than smoothed over.
Does 'autonomy' mean the system attacks without permission?
No, and that is a deliberate design constraint rather than a current limitation. Testing runs inside a scope and rules of engagement recorded beforehand, free-plan targets prove domain ownership by DNS record, and the agentic engine can be run human-in-the-loop so it pauses before any write or exploit tool and waits for an explicit decision.
Do you replace human penetration testers?
Not for the work humans are actually best at. Creative business-logic abuse and chained attacks specific to your product still benefit from a person. What continuous automated testing changes is that the human engagement starts from a much shorter list, because the automatable majority has been covered and verified in the meantime.
Why does this page have no statistics or customer names?
Because we do not have ones we can source honestly yet. We would rather publish an argument you can evaluate on its merits than a number you cannot check. When there are customer results worth citing, they will appear with the customer's name on them.
Judge us on chapter one
The part that ships today is the part you can evaluate. Point it at something you own.