The defender's window is open

On August 27, 2026, OpenAI published a call for collective action on cyber defense, supported by more than 100 organizations across AI, cloud infrastructure, security, finance, and critical services.

Its warning is direct:

We have a limited window to strengthen cyber defenses.

The letter argues that increasingly capable models will make cyber attacks more widespread and sophisticated. It calls for broader access to cyber-capable AI, continuous testing against frontier capabilities, urgent remediation of high-risk weaknesses, and verification that fixes actually work. OpenAI's announcement and Sam Altman's accompanying message make the timing explicit: this is not a long-range policy discussion. It is an operational priority.

Drost is not a signatory to that letter, and this is not an affiliation announcement. But the problem it describes is the problem we have been building toward.

The defender's advantage will not come from asking a model occasional security questions. It will come from putting cyber-capable models inside systems that can operate continuously, use real tools, preserve state, respect authority boundaries, test hypotheses, inspect evidence, and remain honest about what they did and did not prove.

That is the Drost thesis:

Cyber capability is becoming model-distributed. Cyber agency is stack-level.

One defender mission, two operating systems

Drost now works on both sides of the exposure boundary.

Drost Attack is an autonomous offensive testing system for authorized targets. It explores applications and APIs, forms attack hypotheses, executes bounded tools, and records a confirmed finding only when it has proof from the real target. Its job is to find exploitable weaknesses before an adversary does.

Drost Defender is an autonomous investigation system for live attack evidence. It observes independently captured telemetry, detects material behavior through a deterministic engine, preserves incident history, correlates related activity without erasing evidence boundaries, and gives an evidence-scoped AI investigator the cases that require interpretation. Its job is to help an operator understand what is happening while an attack unfolds.

These are not one unconstrained agent switching between attack and defense. They have separate runtimes, authorities, evidence paths, and safety boundaries. They share something more important: the same doctrine about security truth.

A plausible model answer is not enough. A scanner pattern is not enough. A traffic cluster is not automatically an actor. Temporal proximity is not automatically causality. A finding, detection, or case must remain bound to the evidence that supports it, and uncertainty must stay visible when the evidence does not close the gap.

The offensive side: find and prove the weakness

The offensive system exists because defenders need more than another source of alerts. They need a way to apply frontier cyber capability directly to systems they are authorized to test.

Drost Attack owns the operational layers around the model:

• explicit target scope and rules of engagement;
• durable engagement state and authenticated context;
• a bounded tool surface and runtime authorization;
• model routing rather than dependence on one provider;
• proof validation and separation of candidate observations from confirmed findings;
• evidence redaction and auditable action history; and
• benchmark and negative-control gates against false confidence.

DrostBench v1 measured this stack on 100 disposable, authorized web-application targets. Under a fixed 30-minute per-target budget, the strongest evaluated Drost/model configuration completed 73 of 100 end-to-end objectives. That is benchmark evidence, not a universal claim about production performance. Its value is that it measures completed outcomes rather than persuasive prose.

Our nginx known-answer validation applied the same standard to native-code research. Drost reasoned from source to sink, built the target with sanitizers, generated a working trigger, and produced an ASAN-confirmed crash. We labeled it correctly as reproduction of a known issue, not a new vulnerability claim.

The standard is simple: capability should leave a receipt.

The defensive side: preserve and interpret the attack

Drost Defender begins at an independent evidence boundary.

The current PrivateKind deployment captures semantic HTTP evidence plus compact process, network-flow, workload, and lifecycle telemetry. The gateway is deliberately neutral: it acquires evidence but does not detect, score, redact, challenge, rate-limit, or block the traffic it observes. Detection and model reasoning remain outside the request path.

From there, two cooperating systems take over:

1. A deterministic observer verifies immutable evidence, extracts bounded features, detects high-value behavior, and publishes append-only incident revisions.
2. An evidence-scoped AI investigator examines material incident changes, explains observed impact, records explicit uncertainty, and recommends proportional operator actions.

The split matters. A model call is too slow and failure-prone to sit in front of every request. Deterministic correlation can react near real time and remain replayable. The model is reserved for the smaller set of cases where cross-signal interpretation adds value.

The investigator cannot browse the web, issue shell commands, scan systems, block traffic, or execute remediation. It can inspect only bounded, secret-free evidence summaries through read-only tools. Raw credentials, HTTP bodies, exact paths, native workload identities, and targetable endpoints do not cross the model boundary.

Cases are also non-destructive. When the system connects multiple incident threads into a likely shared operation, the original incidents remain independently preserved. A later revision supplements prior truth instead of overwriting it. Operator resolution changes workflow state, not detector evidence or historical verdicts.

A live public proof surface

The Defender is running now at privatekind.defender.drost.ai.

PrivateKind is an intentionally public security testbed. The public Defender view updates every two seconds and shows live service health, deterministic severity, confirmed server-side impact, independently preserved incident threads, case correlation, evidence-plane counts, AI assessments, uncertainty, and recommended actions.

That public view is not the private operator console. It is produced through a separate versioned contract, a second structural allowlist, public-only HMAC aliases, and bounded narrative sanitization. Native identities, source clusters, evidence hashes, credentials, IP addresses, exact endpoints, and private artifact references remain private.

The delivery boundary is also deliberately narrow. The public relay accepts only allowlisted read paths and GET/HEAD traffic, has no evidence or credential mounts, cannot reach application or data networks, and can be disabled immediately through a host-controlled kill switch.

Most importantly, the public deployment is labeled honestly: shadow mode, no enforcement.

It observes, detects, correlates, investigates, and recommends. It does not currently block traffic, terminate workloads, mutate hosts, or remediate incidents. Automated response is a separate authority problem and is not smuggled into the product through an ambiguous word like "agent."

What the defender's window requires

The coming shift is not only that attacks will get better. They will get cheaper to repeat, easier to adapt, and possible across more targets at once.

The defensive answer cannot be one heroic model session. It needs a stack that can:

• cover broad surface area economically;
• route the hardest questions to frontier capability;
• operate against real systems under explicit authorization;
• observe real attack consequences instead of inferring them from signatures alone;
• preserve evidence and uncertainty across long-running activity;
• verify findings and fixes rather than merely suggest them;
• expose exactly what authority an autonomous component has; and
• improve without letting benchmark success, model confidence, or urgency lower the proof standard.

This is where the offensive and defensive systems reinforce each other. Offensive testing tells us whether the system can discover and complete difficult attack paths. Defensive observation tells us whether it can recognize, preserve, and explain those paths from the other side. Both create evidence. Both reveal gaps. Both can be replayed and measured. Neither should be trusted because it sounds intelligent.

Put frontier capability on the defender's side

The collective call is right about the window. Security teams cannot wait for AI-enabled attacks to become routine before building the systems that defend against them.

But speed and rigor are not opposites. The way to move faster is to build evidence, scope, identity, observability, and authority into the architecture from the beginning.

That is what Drost is for: find the weakness before it is used, understand the attack while it is happening, and leave behind proof that a defender can act on.

Watch Drost Defender live or contact us to discuss the technical preview.