Immunis

Protection while the fix is coming
The burst opens an investigation
Evidence you can inspect
Normal traffic still gets through
Red is the tester. Immunis is the defense

Inspiration

Finding a vulnerability and fixing it are two different moments. Between them, an application remains exposed while developers investigate, test a fix, and prepare a release.

We built Immunis around a question: could an autonomous agent help protect an application during that gap?

Inspired by the immune system, we wanted a defense that remembers suspicious behavior, investigates attacks, and develops temporary protections—with checks on its decisions and clear explanations for the people responsible for the application.

What it does

Immunis is an autonomous application defense system running on Cloudflare Workers. It observes suspicious traffic, connects related events, and generates temporary rules that block matching requests before they reach the application.

Its defense has three parts:

Shield: Inspects incoming requests and enforces active protections.
Commander: Maintains incident history, scores suspicious behavior, and correlates attack patterns across addresses.
Analyst: Investigates incident evidence, proposes a mitigation, and revises proposals when validation rejects them.

Before a proposed pattern goes live, Immunis checks it against attack evidence and a collection of benign requests. The dashboard shows intercepted payloads, investigation steps, validation results, and active mitigations.

To demonstrate the defense, we built a separate adaptive Red Agent. It sends attacks against our controlled practice application and uses the results to choose subsequent attempts. This lets viewers watch Immunis respond to changing traffic.

Immunis provides temporary protection; it does not modify or repair the application’s source code.

How we built it

Cloudflare provides the backend for the defense:

Workers run request filtering, API routes, and orchestration.
Queues separate incident analysis from the main request-handling flow.
Durable Objects maintain incident state and correlate distributed campaigns.
Workers AI powers the Analyst’s investigation and mitigation proposals.
KV stores protections for the Shield to enforce.
D1 records incidents, mitigations, and audit events.

The Analyst uses a bounded tool loop to inspect evidence, read supplied history and campaign context, and propose rules. Deployment authority stays with the Commander, which independently validates proposals.

When model inference is unavailable, a deterministic fallback derives candidate patterns from observed evidence and validates them. The defense dashboard distinguishes this path from Workers AI output.

We built the dashboard with Next.js and React, using a WebSocket feed to display events. Our practice target uses Express and SQLite, including a deliberately vulnerable login for demonstrating a real SQL-injection bypass. Additional attack classes use simulated outcomes to exercise the defensive workflow.

Challenges we ran into

The hardest part was connecting detection, investigation, and enforcement into one consistent system. A rule is only useful if the Shield interprets requests the same way the Analyst and validator do.

We also had to balance protection with false positives. Broad patterns can catch more variations, but they can also reject legitimate requests. We introduced restrictions on model-generated patterns, validation against benign samples, and explicit rejection feedback.

Another challenge was making autonomous decisions understandable. We connected actual request evidence and Analyst traces to the dashboard so viewers could see what triggered an investigation and why a rule was accepted or refused.

Finally, local demonstrations introduced practical constraints: multiple simulated users share one machine, model access can fail, and local storage behavior does not establish global deployment timing. We added explicit demo controls and fallback behavior to make those differences manageable.

Accomplishments that we're proud of

Connecting the complete defense loop: suspicious request, investigation, validation, rule publication, and enforcement.
Demonstrating a SQL-injection bypass succeeding before protection and being blocked afterward.
Giving the Analyst a way to receive rejection feedback and revise its proposal.
Making incident memory and cross-address correlation part of defensive decisions.
Replacing placeholder dashboard content with actual evidence and investigation traces.
Keeping the defense operational when AI is unavailable, while identifying the fallback path.

What we learned

We learned that an agent’s value comes from the system around its model: useful context, bounded tools, persistent state, validation, and the ability to complete an action.

We also learned that adapting during an incident is different from training a model. Immunis updates its context and active protections; it does not retrain model weights.

Most importantly, a blocked request is only part of the story. A useful defense must explain its decisions, preserve legitimate traffic, and communicate what its evidence does—and does not—prove.

What's next for Immunis

Our next priorities are to:

Evaluate live Workers AI investigations for latency, reliability, and mitigation quality.
Expand testing against realistic legitimate traffic and attack variations.
Route anomalous but unclassified traffic into investigations, addressing the current reliance on recognised attack patterns.
Test proposed mitigations against an isolated application before enforcement.
Measure protection propagation and behavior across deployed Cloudflare locations.
Strengthen operator controls for reviewing, revoking, and auditing protections.

Our goal is to make Immunis a dependable first responder that helps contain attacks while developers address the underlying vulnerability.