June 29, 2026 ยท 09:15 UTC 8 min read

Turning Runtime Events Into a Smart Firewall

Turning Runtime Events Into a Smart Firewall

Events Become the Sensor

Runtime events already describe how an application truly behaves, so this project quietly turns that raw stream into a firewall, letting a small model learn the shape of normal traffic and then flag the deviations that a static rulebook never once anticipated, all while reading the app from the events it already emits and pushing each verdict down to a layer that blocks.

The firewall watches the very same signals the app emits while serving live requests, then quietly builds its own working sense of what truly belongs on a given endpoint and what clearly does not, one carefully observed and logged request at a time.

Detection stops being a long static list of patterns to match, it simply becomes a live question of whether this one fits well.

Regex Rules Age Badly

Most firewalls in front of web apps still lean on signature lists and regular expressions, matching each request against known bad strings that a vendor curates and ships on a schedule, which holds only until an attacker rephrases the payload once.

Commercial appliances solve this with scale and a large research team, yet that scale always arrives with a heavy licence bill.

The deeper problem is that a regex rule knows nothing about the application it guards, so it cannot tell that a login route suddenly receiving deeply nested JSON is strange, or that an endpoint which only ever returned small responses is now streaming megabytes, because none of that behaviour was ever written into a rule and no static pattern was built to notice the drift.

Signature rules matching strings while behaviour drift slips past unnoticed

Signals Buried in Noise

Turning raw runtime events into a usable defence surface meant solving several hard problems at once, since the event stream is noisy, high volume, and mixes ordinary client traffic with genuine framework faults, so the model had to separate a real attack from a slow day, a deploy, or a plain traffic spike without a human constantly relabelling every fresh example by hand.

Cost was a hard constraint too, since a model that needs a whole fleet of GPUs to run quietly defeats the entire point of it.

Acting on a verdict added its own real tension, since reading each request happens up where the app speaks, yet the block lands lower down and far faster, so a truly bad request is stopped cold well before the app itself ever feels the hit at all.

Learn the App, Not Patterns

The core goal was simple to state and hard to reach, teach the firewall the whole application rather than a fixed list of attacks.

A second goal was adaptivity, because an app changes as it grows, and a defence that learns from behaviour should quietly follow those changes instead of forcing someone to hand edit a rule file after every deploy, so the model was meant to retrain from fresh traffic on a schedule, or learn once from a good contract when behaviour is expected to stay stable for a while.

Affordability shaped every single decision as well, since the real aim was a defence a small team could genuinely afford to run, one that leans on cheap signals the app already emits rather than an expensive external service billed by the request.

Behaviour Feeds the Model

The strategy centres on one idea, the app already tells the truth about itself through the events it emits, so the firewall only has to listen with real care, since every request, render, and refused connection is a labelled example of behaviour.

An instrumentation hook subscribes to the running pipeline and forwards each event, stamped and structured, to a learning engine that turns the raw stream into features such as request shape, timing, payload size, and how often a given path fails a check, then the engine builds a compact profile of normal behaviour for each endpoint and keeps refining it as traffic lands.

Two training modes cover two realities, steady learning for apps that keep changing, and one clean pass over a fixed contract.

Runtime events flowing into a learning engine that profiles each endpoint

Wiring Hooks to Detection

Execution started at the seam where the app already speaks, a single subscription to the observability bus that hands every lifecycle and security signal to one listener, so wiring the firewall in took a few lines rather than a full rewrite, and the same hook a team might use for plain logging quietly doubles as the feed that trains and later queries the detection model.

Each event reaches the learning engine as a small structured record, never once as a raw and fully unparsed log line at all here.

The engine folds those records into per-endpoint behaviour profiles, and at request time a light scorer compares live behaviour against the learned profile, returning a verdict fast enough that the block lands a layer below before the app feels it.

// Subscribe once to the runtime event stream and feed the detector
const off = router.on((event) => {
  // Every lifecycle and security signal becomes a training sample
  firewall.observe({
    kind: event.kind,
    metadata: event.metadata,
    at: event.timestamp
  })
})

// At request time, score live behaviour against the learned profile
const verdict = firewall.score(request)
if (verdict.drift > verdict.threshold) {
  return new Response('Blocked', { status: 403 })
}

An inline scorer comparing a live request against its learned profile

Detection Without a Rulebook

The result is a firewall that reads as part of the application rather than a wall bolted awkwardly in front of it, since the rules here are not written by hand but quietly learned from the behaviour the app already shows while it runs in production.

No regex list ships with this defence at all, and none of it ever needs updating when an attacker rephrases a payload once more.

Because detection rides on cheap signals the app emits anyway, the running cost stays far below a per-request scoring service or a licensed appliance, and the adaptive profile means a change in the app is followed rather than fought, so the same setup that guards a small internal tool scales up to a busier service without a human rewriting a rule file after each deploy.

What the Traffic Taught

The biggest lesson was that an app emits far more real signal than any rule ever captures, if something finally bothers to listen.

Separating a real attack from ordinary change turned out to be the hard part, since a deploy, a marketing spike, or a brand new feature all look like drift at first, so the model needed a real sense of gradual change versus sudden anomaly, and the contract training mode earned its place by giving a stable baseline for apps whose behaviour is not supposed to move.

Keeping the whole thing cheap forced real discipline as well, because leaning on signals the app already produces meant the defence added almost no overhead, and that one constraint pushed every design choice toward the simplest option that worked.

A Firewall That Adapts

What began as a simple question about cheaper defence became a firewall that learns the app instead of memorising known attacks, wired directly into the runtime events the pipeline already emits, trained on the real behaviour whether it keeps changing or holds to a contract, and reading each request where the app speaks so a verdict drops it a layer below by honest fit.

Rules that write themselves from behaviour beat rules that a vendor ships on a fixed schedule, and they cost far less to run.

Share
On this page
No results found.