AI Defense Needs a Feature Stream,
Not Another Model

It was 14:23 on a Tuesday when the IDS signature fired. I wrote about that incident in a previous post — the 24-minute workflow from alert to evidence bundle, the Zeus Bot beacon that had been quietly sitting in the capture for ten days before anyone noticed it.

That post was about how a SOC team can use the data when an alert fires. This post is about what the data looks like ten days before anyone is looking.

When that beacon flow first crossed the wire on day 1, the Protocol Stack processed it without raising a single alert. But it did produce something:

TOKEN STREAM   192.168.1.100 -> 185.234.72.19:80

14:23:14.218   TCP   STREAM_SYN                NORMAL    advanced
14:23:14.219   HTTP  REQUEST_START             NORMAL    advanced   POST /gate.php
14:23:14.219   HTTP  REQUEST_NO_USER_AGENT     WARNING   normal
14:23:14.241   HTTP  RESPONSE_STATUS_200       NORMAL    advanced
14:23:14.325   TCP   STREAM_FIN                INFO      advanced   2 packets, 699 bytes, 0.107s
14:23:14.325   PII   EXTERNAL_DESTINATION      INFO      advanced

Six tokens. Twenty-eight bytes total — less than half the size of the 60-byte TCP handshake that opened the flow. Each one carrying the analytical state that the Protocol Stack was already maintaining, emitted as the analyzer state transitioned, labeled with severity at the moment of emission.

The Problem Nobody Wants to Say Out Loud

I attended RSA three weeks before writing this. By a rough count, seventy-five percent of the show floor had some version of an AI-native pitch: AI-native detection, AI-native triage, AI-native response. The proposition in nearly every case was end-to-end platform — the vendor's model, running on the vendor's ingestion, trained on the vendor's data, with the vendor's governance story.

Almost nobody was selling the substrate the model requires.

There is a conversation happening right now in network defense about the cyber kill chain. The argument, broadly, is that AI-speed attackers have collapsed the time between phases to near zero, which makes the chain useless as an interruption model. The alternative most security leaders are arriving at is state management: not "can we catch them mid-chain" but "have we reduced the conditions that make any chain viable."

That reframe is correct. What it doesn't say is that state management at machine speed requires a continuous, structured, labeled observation stream produced at the granularity the attacker operates at. Whatever consumes that stream — a rules engine, a human analyst, an ML model, a large language model producing summaries — is only as useful as the stream feeding it.

The conversations I have with security leadership teams increasingly arrive at state management as the answer. The conversations almost never continue on to the question that naturally follows: what does the data layer underneath that state actually look like?

Three Things AI-Native Platforms Don't Tell You

Every AI-defense platform pitch I evaluated this year had at least one of three structural problems. The pattern is consistent enough that I can identify which one applies within the first hour of a sales conversation.

The training distribution is the vendor's, not yours

The model performs well in the demo, which uses traffic the vendor has been training against. It performs less well in production, where the actual traffic doesn't match that distribution. There is no way to inspect what the model is seeing, because the pipeline between capture and inference is opaque — usually proprietary, usually a black box, usually protected as a competitive differentiator.

The governance story falls apart in review

Running a model across an enterprise's packet traffic requires feeding that traffic — which includes subscriber PII, authentication tokens, internal service identifiers, sometimes payment or health data — into the vendor's environment. The enterprise inherits the vendor's data-handling posture, cloud footprint, and sub-processor agreements. Data-governance reviews on AI-native defense platforms fail at a higher rate than teams publicly admit. The review usually fails on the same question: where does our data go, and under whose enforcement?

Provenance is hidden inside the enrichment

When the platform tells you "this flow is associated with a known C2 campaign," it doesn't tell you whether the binding is direct, inferred, or speculative. Confidence is collapsed into a single output score. The analyst who needs to act on the alert has no signal for how much weight to put on it, and the training pipeline that wants to learn from these events can't filter to ground truth.

The gap is structural, not cosmetic. An AI model is only as good as the stream feeding it, and the stream feeding a typical AI-native platform is whatever the vendor decided to build — almost never optimized for the model, usually optimized for the vendor's operational convenience, and rarely instrumented with provenance a downstream consumer can trust.

What Actually Changed: A Stream That Predates the Model

The architectural requirement that follows from this is precise: the feature stream has to exist independently of any model that consumes it, and it has to be produced as a byproduct of capture, not assembled afterward by a downstream pipeline.

Sly Technologies ships this in two tiers.

The jNetWorks Token Stream is produced by the Protocol Stack inside the jNetWorks capture pipeline. As packets flow through the stack and analyzers decode them, the analyzers emit tokens whenever their internal state transitions: a flow opens, a TLS handshake completes, a TCP segment arrives out of order, an HTTP request closes with no User-Agent. Each token carries a four-byte header — the width of a modern CPU register — encoding the analyzer namespace, the event type, a severity label set at emission, and a level-of-detail hint for downstream stratification. Control tokens stay at four bytes. Tokens carrying analytical payloads extend to eight or sixteen. Larger payloads use an extended format and are the minority by count.

This stream shipped in jNetWorks v3.0.0 in early 2026. The analyzer state it exposes is not new — the Protocol Stack has been maintaining that state internally since 2013. v3.0.0 formalized it as a first-class consumable output.

The Vantage Token Stream layers on top. Vantage's SILO correlation engine takes the jNetWorks stream and joins it to external data sources: IDS systems like Suricata and Zeek, threat intelligence feeds like VirusTotal and MISP, telemetry from NetFlow and IPFIX. When an external event matches a packet flow held in the live correlation cache — keyed by timestamp, frame number, and tuple — the bridge emits a new token into the stream binding the external event to the specific flow it corresponds to.

Each external SILO source emits into its own dedicated domain. SURICATA for Suricata alerts. VIRUSTOTAL for VT lookups. MISP for threat intel tags. Downstream consumers subscribe to the sources they want without parsing composite type fields.

When the correlator can't complete a binding synchronously — because the alert arrived after its packet window left the live cache — it emits a carrier token with one of four confidence states: FULL, PARTIAL, INFERRED, or UNKNOWN. The original external event is attached as payload. When retrospective correlation against stored data completes later, a refined token supersedes the carrier, with confidence elevated and the binding pinned. Consumers see honest provenance on every enrichment.

From Capture to Three Consumers: One Stream

Back to the day-1 beacon. Ten days after the original capture, the Suricata signature for Zeus Bot fires on a later flow from the same host. The Vantage correlator matches it against the live packet cache, emits a FULL-confidence SURICATA token, and the SOC workflow described in the forensic readiness post kicks in.

But now the retrospective correlator goes back to the day-1 flow that nobody knew was related. It re-runs the Suricata rule against the stored packets, queries VirusTotal for the destination IP, checks MISP for campaign attribution. Three new tokens land in the day-1 window:

14:23:14.218   SURICATA    RULE_2014818           FULL       ANOMALY    Zeus Bot Checkin
14:23:14.218   VIRUSTOTAL  IP_REPUTATION          FULL       ANOMALY    score=87
14:23:14.218   MISP        CAMPAIGN_TAG           INFERRED   ANOMALY    Zeus Bot C2 Infrastructure

The MISP campaign tag is INFERRED rather than FULL because the campaign attribution depends on MISP's own analysis confidence, not on packet-stream verification. A consumer that needs ground truth filters it out. A consumer willing to act on a hypothesis weights it lower than the FULL-confidence tokens. The honesty is in the stream.

With this in place, three different consumers operate against the same data:

The SOC analyst queries the Query Analytics Tree for flows binding SURICATA alerts to specific hosts and traverses backward from the day-11 alert to the day-1 beacon. The 24-minute incident response workflow runs against the enriched view.

An ML anomaly model running in the enterprise's pipeline attaches to the Token Stream via the virtual .tokens file projection that Vantage exposes over the stored stream. It subscribes to tokens with WARNING or ANOMALY status, plus all SURICATA and ZEEK tokens at FULL or PARTIAL confidence. The model scores the day-1 flow based on its token sequence and produces a learning signal that would catch comparable beacons earlier in their lifecycle.

A behavioral summarizer — a large language model trained to produce natural-language incident summaries — attaches to the same stream but subscribes only to LEARNING-LOD tokens at FULL confidence. It produces a plain-English account of the day-1 flow that a non-technical stakeholder can read.

What This Requires (And What It Does Not)

The Token Stream is exposed three ways. Consumers attach at the surface that fits their pipeline.

As a virtual file: every Vantage capture exposes a .tokens projection over the stored event record. Read it with cat, tail -f, dd, or any tool that handles a byte stream. Pipe it into Splunk, into a Python dataframe, into Kafka, into an ML feature store.

As a device: live captures expose /dev/vantage/{capture-name-or-id}/analysis for streaming inference pipelines. Open with open(), read with read(). No intermediary.

As an SDK API: the jNetWorks SDK exposes typed TokenChannel<T> channels for teams building their own capture pipelines at the protocol level. Available under internal and OEM license.

What it requires: a Vantage capture, or a jNetWorks SDK integration in your own capture infrastructure. The stream is produced as a byproduct of capture, not as a separate processing pass.

What it does not require: moving your data into a vendor's platform. Adopting a vendor's model. Trusting a vendor's governance story. Replacing your existing analytics. The Token Stream is bytes on a file handle, a device, or an API channel. Whatever you already use to consume structured data consumes this.

For AI pipelines, this changes the governance posture entirely. An ML model running in a lower-clearance execution context can read the Token Stream through the Vantage security model — sensitive PII fields encrypted at the daemon and decrypted only for sessions whose clearance permits. The model trains on an enforcement-controlled projection of the stream, not on the raw underlying data. The difference between sending sensitive data into an AI vendor's platform and keeping enforcement at the source is a difference your data-governance review will notice.

AI Defense Is a Stream Decision

Sly Technologies does not ship an ML component. That is deliberate.

The AI-native vendor pitch asks the buyer to take the model on faith, move data into the vendor's pipeline, and accept the vendor's latency, governance, and lock-in. The buyer gets a black box with a service agreement.

The alternative is to separate the stream from the model. The stream is infrastructure: it has properties that can be specified, verified, and held to a standard. The model is a consumer of that infrastructure: it can be swapped, retrained, audited, and replaced without disturbing the stream. A buyer who adopts a Token-Stream-based architecture is not locked into any particular model.

We ship two streams. The jNetWorks Token Stream for platform builders licensing the SDK. The Vantage Token Stream — enriched with SILO correlation and the carrier-token confidence lifecycle — for operators deploying the Vantage Platform. Either way, no proprietary model is required. The stream stands on its own.

The conversion from Token Stream to whatever input format your model expects — embeddings, one-hot vectors, tokenized text, structured JSON — is a thin, model-specific bridge. Token type maps to feature index. Status bits map to anomaly labels. Confidence maps to training weight. LOD filter maps to sample stratification. The bridge is cheap to write and lives entirely on the consumer side.

The full architecture — token structure, the SILO bridge, the carrier token lifecycle, the security model that makes the stream safe for AI pipelines, and the complete Zeus Bot scenario followed through both tiers — is described in the Token Stream whitepaper.