Your SIEM Assumes the Network Is Up

Correction notice, August 14 2026. This article accompanied version 1 of The Endpoint Mesh. I later red teamed that document and several load-bearing claims in it did not hold, including the actor-class routing rule described below, the autonomous action set, the learning rule, and the framing of centralized detection as though modern EDR did not already prevent on the sensor. This article is left up uncorrected, because a dated disclosure that gets quietly rewritten is not a record. Read the correction before you build anything from this. The full list of withdrawn claims is in ERRATA.md.

Every SIEM ever sold makes two assumptions, and almost nobody says either one out loud. First, that the endpoint can reach the middle. Second, and more important, that the round trip is fast enough to matter.

Ship the logs to a central place. Correlate them there. Train models there. Decide there. Send the answer back.

The second assumption fails everywhere, including in a perfectly healthy data center with no packet loss and plenty of bandwidth. Detection travels, a model thinks, a verdict travels back, and by the time any of that lands the process has already spawned its children and written to disk. You did not prevent anything. You documented it.

That is true when the network is fine. It is the whole problem, and it has nothing to do with connectivity.

The round trip is only the part you can measure

If it were just latency you could argue about milliseconds. The bigger problem is that the round trip shapes everything upstream of it, and most of that damage happens before an alert is ever raised.

You already drop telemetry, because ingest is priced by the gigabyte. Every SIEM deployment I have seen has a quiet tier of "we do not send that." Verbose process creation, full command lines, DNS, module loads. The things you would most want when you are trying to tell a novel attack from a noisy Tuesday are exactly the things that cost the most to ship and store, so they get filtered at the agent or dropped at the pipeline. The SIEM is not slow to decide on that data. It never receives it.

The pipeline is measured in minutes. Collection interval, batching, indexing, rule evaluation, correlation window, notification. Each stage is individually reasonable and the sum is nowhere near the speed of a process spawning children. Vendors quote query performance because query performance is the part that looks good. Nobody quotes event-to-verdict.

Segmentation works against you. The environments where you did the security work properly, where egress is restricted and networks are carved up, are the environments where telemetry has the furthest to travel and the most policy to cross.

And the manager is a single point of decision. This is the one that gets missed. It is not only that the centre is slow. It is that when the centre is unreachable, endpoints do not degrade gracefully into a reduced local capability. They stop deciding at all. Every agent in your fleet becomes a log shipper with nowhere to ship to.

None of that is a vendor problem and no product fixes it, because it is not a defect. It is what the architecture is.

Follow the constraint

I did not arrive at this by studying SIEM architecture. I arrived at it from one physical fact that will not negotiate: sending data somewhere else to be thought about is too slow to respond at machine speed.

That is not an implementation detail you can optimize away with a faster link or a closer region. Attacks execute at the speed of the processor they are running on. Anything that has to travel has already lost.

So the AI has to be where the event is. Not an agent that forwards to a model somewhere else. The detection and the response, on the endpoint, deciding on its own.

Most people get that far and stop, and they ship a smarter agent. The useful part is the next question, and it is the one worth teaching:

If the AI on the endpoint can detect and respond on its own, what was the center for?

Follow that honestly and the answer is uncomfortable. The center was doing four things. Collecting, which was always local anyway and only shipped out by convention. Correlating. Learning. Deciding. And deciding just moved to the endpoint, because it had to.

The SIEM is not the brain anymore. It is a place you report to after the fact. Useful for humans, for compliance, for the investigation next week. Not in the path of the decision.

That is the whole architectural move, and it comes from a latency constraint rather than from anything clever.

Then you ask what you broke, and you fix only that. This is the part people skip, and it is where the real design work lives. When you relocate a function, whatever it silently depended on goes away with it. Find those dependencies and the answers show up as consequences rather than as inventions you had to be brilliant to think of.

What breaks

Deciding already moved, because latency forced it. That leaves three, and one of them turns out to have never needed the center at all.

Collection does not break. It was always local. The center was a destination, not a requirement.

Correlation breaks, because it depended on seeing multiple hosts at once. One endpoint has one point of view. The fix is that endpoints have to tell each other what they concluded. Not their raw logs, which is the whole cost problem repeating itself, but their conclusions. Small, signed, cheap to send. A verdict is kilobytes. A day of telemetry is gigabytes.

Learning breaks, because it depended on volume. One machine sees too little to learn much. So endpoints have to share what they learned rather than what they saw, and weight what arrives by how much the sender has earned.

Deciding breaks, because a decision with no human in the loop can take down the thing it was protecting. This is the one that deserves the most fear. The answer is not to ask permission, which puts the network back in the path. The answer is that every action has to be atomic and reversible: staged, committed, verified, and rolled back automatically when the verification fails. If your autonomous response cannot undo itself unattended, it is not ready to be autonomous.

The thing the new position makes possible

There is a fifth item, and it is not a consequence. It is a capability that only exists once you have moved.

Sitting on the endpoint, you can see the operator's tempo. The pauses. The hesitation. The backtracking. The shape of how a human works through a problem versus how a language model does.

A central log pipeline flattens all of that away by the time the data arrives. It is not in the schema, because nobody thought to keep it.

That is worth paying attention to right now, because a growing share of attacks are driven by models rather than people, and models have a different signature. Faster, more consistent, less prone to the flailing that humans do when something does not work the first time.

I want to be careful here, because this is the part that gets oversold. A detector built on operator tempo is beatable. Add jitter and slow the model down and you have defeated it. I have watched that happen in about an afternoon.

That is not a reason to skip it. It is a reason to understand what you are buying: a signal that raises cost for the unsophisticated and buys nothing against someone who knows it is there. Most defenses are that. The mistake is not knowing which one you have.

Who is on the other end, and why it decides everything

Here is the part that started all of this, and it is the piece I care most about.

Before you decide how to respond, you should know who you are responding to. Not whether the activity is malicious. Whether the thing driving it is a person or a machine. Those are different defensive problems and the difference is tempo.

If the attacker is an AI, a human cannot be in the loop. Not because people are not good at this, but because the attack is executing at the speed of a processor and a person cannot read an alert, form a judgment, and act inside that window. Asking someone for approval is the same round trip I have been complaining about this whole article, wearing a different hat. So an AI-driven attack goes down the autonomous path: decide locally, act reversibly, tell the neighbors, inform the console afterward.

If the attacker is a human, or a script, or something deliberately throttled, the calculus flips. A human attacker moves at human speed. A human defender can keep up. Centralized correlation across many hosts actually earns its latency, because the attack is slow enough to allow it. So that one goes down the hybrid path, with the SIEM in the loop and a person making the call.

This is the thing I want to be clear about, because it is easy to read this article as an argument that the SIEM is finished. It is not. The mesh does not replace central correlation. It routes around it only when the attacker is too fast for it. Everything you already built for investigation and correlation keeps its job for the slow attacks, the ambiguous ones, the ones worth a human looking at next week. What changes is that those stop being the only path, and the fast ones stop having to wait in line behind them.

The two ways to get this wrong are not equally bad, and that asymmetry is useful.

Call a human an AI and you fire an autonomous response on a slow attack somebody could have handled. Annoying. Recoverable, because every action has to be reversible anyway.

Call an AI a human and you route a machine-speed attack into a path built for human-speed attacks. The verdict arrives after it is over. There is no undo, because nothing was decided in time.

So you bias the thresholds toward the autonomous path. An over-triggered reversible response is a mistake you can walk back. An under-triggered one is not. Anyone tuning this to reduce false autonomous actions is optimizing in the wrong direction.

And it reframes what the jitter weakness actually costs you. An attacker who successfully dresses a machine up as a human does not disappear. They demote themselves out of the fast path into the slow one. That is the attack worth worrying about, and it is a good argument for not resting the routing decision on tempo alone.

What I have and have not built

The honest status, because the alternative is the thing I keep complaining about in this industry.

The parts that exist and run: telemetry collection, scoring, and a decision ledger, in Specter, which is public and open source. The parts that are designed but not finished: the peer gossip layer, the atomic response commit, and cooperative learning across a fleet.

So this is an architecture and an argument, not a product announcement. If you were expecting a benchmark, there is not one, and anyone showing you a benchmark for a three node lab is selling you something.

Now put it somewhere that is not a server room

Everything above is about a SIEM, because that is where the problem is easiest to prove. The endpoint is a laptop, the centre is a manager, and the round trip loses on a network with nothing wrong with it.

But nothing in the architecture cares that the endpoint is a computer.

A body camera is an endpoint. It records for a full shift and does not touch a network until it docks. A camera on a light pole is an endpoint, and a few hundred of them across a city are a mesh whose members can see each other long before any of them can reach a datacenter. A vehicle is an endpoint. So is a drone on a link that is contested by design rather than by accident.

Every one of those has the same shape as the problem I started with. Something happens fast, the decision has to be made where it happened, and the thing that would normally decide is either too far away or not reachable at all. And they have the property that makes the peer layer worth building: they are near each other. A camera that concludes something is wrong can tell the next camera down the street in the time it would take to open a connection to anywhere else.

I have not built any of that, and I want to be careful not to describe it as though I have. It is the same four mechanisms pointed at a different kind of device. But it is the direction I find most interesting, and it is the reason I would rather this get built by a lot of people than owned by one.

Why this is published instead of filed

There was a version of this where it became a patent portfolio. I closed that.

Partly because the prior art is denser than the story I was telling myself. Partly because the research underneath it did not hold up when I checked it properly, which is its own lesson about verifying things you want to be true.

But mostly because I would rather this get built than owned. Publishing it puts it in the open where anyone can build on it and where nobody else can lock it up. If a large vendor decides defenders should not have this, they are now too late.

The techniques are more useful in a hundred hands than in mine.

The pledge

So here it is, plainly, so there is no ambiguity later.

I have not filed a patent on any of this, and I am not going to. No provisionals, no applications, nothing pending. This article is the disclosure, it is dated, and it is public. The permanent version of this statement lives in the repo, alongside the full technical writeup.

Any open-source security project is free to implement all of it. Wazuh, Elastic, OSSEC, osquery, Velociraptor, Suricata, and anything else built by defenders for defenders. You do not need to ask me. You do not owe me attribution, though I would enjoy hearing about it. Take the argument, take the design, build it better than I described it.

That includes commercial vendors. I would rather CrowdStrike or SentinelOne or Microsoft ship this than nobody ship it. My only concern is that it stay buildable by everyone else too.

I want to be accurate about what publishing does and does not accomplish, because overselling it would be the same sin I am complaining about. Publishing puts this into the public record where it can be cited as prior art. The disclosure is archived at Zenodo under DOI 10.5281/zenodo.21716611, so there is a permanent citable identifier for it that does not depend on my repo or my domain still being there in ten years. That is a real thing and it is also a modest thing. It does not by itself guarantee that a patent office finds it, and if a bad patent issues anyway, somebody still has to challenge it. Publication is the strongest move available to one person working alone. It is not a guarantee.

But it is a lot better than sitting on it, and it is a lot better than filing.

The thing I actually do not want is for endpoint autonomy to become a fenced yard, where three platform vendors can ship it and the open-source security tools that everyone else actually runs get locked out. Wazuh, OSSEC, osquery, Velociraptor, Suricata, and the projects around them are what a great many organizations are defended by, whether or not that appears in anyone's market sizing. Those tools should be allowed to have this.

---

The full technical disclosure — all four mechanisms, the diagrams, and the limitations — is published as prior art at github.com/CarbeneAI/endpoint-mesh and archived at DOI 10.5281/zenodo.21716611. No patent has been filed on any of it and none will be. Take it and build it.