The security market has no one defining what you can own.

A security buyer can find an independent read on almost any property that matters. Performance has benchmarks, public and re-runnable. Security has SOC 2, FedRAMP, and a pile of audits. Detection efficacy has the ATT&CK Evaluations. Even total cost has analyst models you can argue with. The one property nobody scores is the one that decides whether you're a customer or a hostage: can you run this tool, understand what it's doing, and keep operating it if the vendor relationship ends or the network to their cloud goes away. There's no rating for that, no matrix column, no independent body defining the terms, and so it never enters the purchase decision as a number. It shows up later, as a renewal you can't walk away from.

It helps to make the property concrete, because "ownership" drifts into a slogan otherwise. I score it on four questions, each of which has an honest answer for any given tool:

• Air-gappable. Can it run with no outbound network, no call home to a vendor cloud?
• Self-hostable. Can you run and inspect the binary or the server, rather than reaching it only as a hosted service?
• Legible. Does it enumerate what it does in a form you can read, or does it abstract its own workings away from you?
• Open formats. Are the durable artifacts — the detections, the data, the analysis — portable open text, or trapped in a proprietary container?

None of those is a yes-or-no for the whole product. A tool can store data in open Iceberg and still wrap its detection logic in a format that only runs in its own engine, which is most of the lakehouse market right now. The point of scoring all four, per component, is that "open" stops being a marketing word and becomes a measurement with a number attached, and the moment it's a number, a buyer can compare two vendors on it and a vendor has a reason to move. Today no one publishes that number, so the market has no pressure pushing it toward tools you can own, and quite a lot of pressure pushing the other way.

Detection content is the layer where I can show the ownership argument winning on the evidence rather than asserting it. Go back a few years and the shareable security use case was a Sysmon config you forked: SwiftOnSecurity's heavily annotated template, then Olaf Hartong's modular, ATT&CK-tagged successor. Both were genuinely good, widely used, and text in git, and both have stalled, the first with no commits since 2021 and the second since the summer of 2024. They were single-maintainer projects, central to the people who relied on them right up until the maintainer's attention moved, and then they froze. (Tier B, from the repositories' own commit history.)

What didn't stall is Sigma. The SigmaHQ ruleset carries on the order of three thousand rules across something like ten thousand stars, with a fresh release in April 2026, a core maintainer team rather than one person, and several hundred contributors. (Tier A/B, from the project's releases and repository metadata.) The design choice that made it durable is the part worth copying: the rule format and the per-engine conversion are split, so vendors maintain their own backends at the edges and no single vendor gates the format. Open governance plus a portable conversion layer plus an ATT&CK coordinate system is the combination that survived contributor turnover, and the single-maintainer configs that had the text-in-git property but not the governance did not. The honest asterisk, which I keep on this claim everywhere I make it, is that a shareable rule is not the same as identical detection across every engine; field-mapping fidelity is a real and unsolved soft spot, and I won't pretend the portability is total.

The lesson isn't "open always wins." It's that open content wins durably when something defines the standard, governs it, and pushes the ecosystem to support it, and stalls when it depends on one person's stamina. That conditional is the whole argument for an intermediary. The open option is real, but it needs a force behind it, and at most layers of the security stack that force is absent — which is exactly where the agentic shift is taking the problem from chronic to acute.

The clearest current evidence is the rush to publish MCP servers. The Model Context Protocol is the standard, now governed under the Linux Foundation's Agentic AI Foundation, by which an agent reaches a tool, and a wave of security vendors shipped servers in the last year. The ones worth caring about are for the products that produce the telemetry a SIEM ingests, the data sources: endpoint, network, cloud, identity, vuln, threat intel. The destination platforms that bolt an MCP onto the SIEM are a different question, and the pipelines a different one again. For a data source, the test of a good MCP server is sharp: it should run air-gapped, and it should teach you the two things the vendor usually keeps in its own people's heads and docs, how to administer and manage the system, and how to access and analyze the data it produces. That is the opposite of Microsoft Sentinel's pitch that you "don't need to understand the schema." A good MCP doesn't hide the schema and the operations, it hands them to you in a form an agent, or a person, can run offline.

The split is the finding, and it falls along ownership. Across thirty-one data-source producers I inventoried, the seventeen that are open and self-hostable are all air-gap-capable, and they span six categories, not one: network (Zeek, Suricata, Arkime), endpoint (Wazuh, osquery, Velociraptor), cloud-runtime (Falco), vuln (OpenVAS, Trivy), identity (Keycloak, FreeIPA), and threat intel (MISP, OpenCTI). Several already encode both axes the ask calls for: Wazuh and Velociraptor carry administration and analysis both, Keycloak the admin side, Zeek and Suricata the analyst side. Of the eleven commercial SaaS producers, not one is air-gap-capable. CrowdStrike ships the best-built server in the whole set, MIT-licensed and genuinely legible, and it still phones home because Falcon is a cloud product. And of the network-detection leaders, only Corelight shipped an MCP at all; Darktrace, ExtraHop, and Vectra have none. (Tier B for the inventory, per-vendor marketing flagged Tier C.) So the air-gap-capable layer is the open, on-prem sensor and agent ecosystem, and the brand-name cyber producers are absent from it by construction.

Here is that split as a starting scorecard for the data sources, showing whether you can run each one with the network unplugged, and which of the two best-practice axes its MCP encodes. The pattern is plain: the air-gap-capable producers are the open, on-prem tools, and the SaaS brands, however good their servers, sit on the wrong side of the line because their products were never air-gappable.

Thirty-one producers inventoried, grouped here; "air-gap" requires the product on-prem, not just the server binary, which is the bar the SaaS brands fail. "Encodes" is which best-practice axis the MCP carries, administration or analysis. A research snapshot rather than a census, and most of the open entries have several competing community servers.

The heart of it is that vendors could ship air-gappable MCP servers that teach how to run their system and how to read its data, for the practitioners who operate inside a closed network. The protocol supports it, the stdio transport is local by definition, and the open tools already do it. There is just no market force identifying that capability, defining what it requires, and pushing for it, so each vendor optimizes for the hosted service that fits its business model and the air-gapped practitioner is left to assemble it alone. The fallback, when the vendor won't, is the lakehouse move: ingest the source into your own store and run a self-hosted MCP, a DuckDB server over the logs, against your copy, air-gapped by construction. The honest limit is that a generic server over your lake gives you the records and the triage but not the tool-native actions, you can read what Velociraptor collected without its MCP but you can't launch a hunt, so the dedicated air-gappable vendor server, scored on those two axes, is still the thing worth asking for.

You don't have to wait for the market to grow a referee to start scoring like one. In your next platform or tooling decision, put the four ownership questions on the page next to the capability and cost columns, and make each vendor answer them on the record: can it run air-gapped, can you self-host and inspect it, does it enumerate its own workings, and do the detections and data come out as portable open text. Keep the durable artifacts in formats you hold — Sigma rules and SQL and plain notebooks rather than vendor containers — so that whatever you decide at the tool layer, the work you build on top stays yours. When a vendor calls a product "open," ask open at which layer, because the answer is usually the storage layer and far less often the authoring or agent layer where the abstraction runs deepest, and that gap between the two is what an ownership score would force into the open.

And price the ownership honestly rather than romanticizing it. An air-gapped open stack on local models trails the frontier and puts the update discipline on your team, and that cost is real, so the right call isn't "own everything" any more than it's "rent everything." It's to know the number, for this tool, at this layer, what owning it costs and what renting it costs you in control, and to make the trade deliberately. A referee doesn't hand you a verdict that open is always right; it hands you that number, early enough that you decide the trade rather than discovering it at renewal.