Moats in security AI, honestly

There's a version of the moats conversation security vendors love to have, and a different version that survives a serious diligence review. This post is the second one.

The frame most often borrowed for these conversations is Hamilton Helmer's 7 Powers — counter-positioning, scale economies, switching costs, branding, cornered resource, network economies, process power. Helmer's framework is genuinely good. The problem is that vendor decks tend to claim 4–5 powers when the honest answer is 1, maybe 2, and the rest are aspirations that depend on execution that hasn't happened yet.

We're going to do this exercise on Setu, naming the powers we have, the powers we don't, and the powers we've sometimes gestured at that don't survive the question "compared to whom?"

The four powers we sometimes get credited for, that aren't real moats

1. "Cornered resource: the customer's graph data." We've used this framing in older writing. It does not survive scrutiny. The customer's graph data lives in the customer's tenant. Every SaaS vendor has access to data inside its own tenant boundary. By that logic, every vendor has a cornered resource, which means none does. What we have is deployment inertia — once we're integrated into the customer's pipelines, switching is annoying. Annoying is real, but it is not a moat in Helmer's sense. It is a tax on switching, and at the price points we operate at, it is a tax customers pay routinely.

2. "OCSF as differentiation." Every modern security data platform speaks OCSF — Splunk, Cribl, CrowdStrike Falcon LogScale, AWS Security Lake, Sentinel. Claiming OCSF support as a differentiator in 2026 is table stakes dressed as virtue. We use OCSF because it's correct, not because it sets us apart.

3. "The math." Spectral graph wavelets are Hammond 2011. Personalized PageRank is 2003. Heat-kernel diffusion as a smoothing operator on graphs predates both. Our application of these methods to identity-asset graphs is honest production engineering, but the underlying mathematics is in the public domain and the implementation pattern is reproducible by any team that reads the relevant graph signal processing literature. There is no algorithmic moat here, and we have been wrong to imply one.

4. Patents. We have an active patent portfolio — twelve families, the most recent being the temporally-unbounded entity graph with monotonic upsert semantics. Patents are useful as a defensive shield and as a credibility marker in enterprise procurement, especially in regulated verticals. They are not a customer-facing moat. No mid-size SOC has ever bought a security tool because the vendor had filed claims under §3(k) of the Indian Patent Act. We file patents to protect ourselves from being copied at scale, not to win deals.

The two real moats we are actively building

1. Per-tenant analyst feedback as compounding training data. This is the one that matters. Every triage decision a customer's analysts make — closed alert, escalated alert, dismissed alert — is a labeled example specific to that tenant's notion of normal. Six months into a deployment, a typical mid-market SOC has generated 15,000–40,000 triage decisions. That data trains a per-tenant model that no pretrained model from a competitor can match, because the competitor never saw the tenant's notion of normal.

The reason this is a moat in Helmer's sense and "cornered resource" wasn't is that the data accumulates because of how the product is used, not because the customer happened to have it. Switching vendors after 12 months means losing that accumulated learned weighting, which has measurably better precision-recall than any cold-start replacement. This is process power and switching cost compounding together.

The honest caveat: this moat exists at month 12, not month 1. We have to survive long enough to accumulate the data before the moat is real. That's why path B in our cold-start argument matters — we ship a useful day-one product so the analyst feedback starts compounding from week one.

2. Air-gapped on-prem deployment for regulated and sovereign tenants. A non-trivial fraction of the global enterprise security market — banks, pharma, defense, central government, critical infrastructure — cannot ship identity telemetry to a SaaS vendor. Not "would prefer not to," cannot. The compliance regime forbids it. Wiz can't deploy there. CrowdStrike can deploy a sensor but the SaaS console isn't allowed to see the data. Microsoft can deploy Defender but the cross-tenant analytics live in a cloud the customer's data sovereignty rules forbid touching.

Setu runs fully air-gapped, including a local LLM (Ollama-served) for narrative generation. The architecture was designed for this from week one. This is not a moat in the sense of being uncopyable — Microsoft could in principle build an air-gapped product if they decided to — but it is a moat in the sense that the incumbents have spent ten years architecting in the opposite direction and the cost of reversing those decisions is enormous. Counter-positioning, in Helmer's vocabulary.

Counter-positioning, properly defined

Helmer's counter-positioning power requires that the incumbent's existing business model makes it costly or impossible to copy the entrant's strategy. The classic example is Vanguard versus actively-managed mutual funds: Vanguard's index funds exist because the active managers can't cut their fees to compete without destroying the economics that pay their analysts.

The security-AI version of this is: incumbents who have spent a decade building cloud-native, cross-tenant AI cannot easily build single-tenant air-gapped products because their entire data and model architecture assumes the cross-tenant case. CrowdStrike's cross-tenant threat intelligence is genuinely valuable; it also depends on Falcon devices reporting to CrowdStrike's cloud, which the air-gapped customer cannot allow. Defender's pretrained anomaly models were trained on Microsoft's cross-tenant data; the customer who refuses to send data to Microsoft cannot consume those models.

This is real counter-positioning, narrowly. It does not extend to the parts of the market where customers happily ship data to a SaaS. In those markets we compete on product, and there we do not have counter-positioning. We have to win on something else.

What about Software 3.0?

A version of this question we get often: "If AI agents become primary actors in enterprises, does the identity graph framing still hold? Does Setu survive Software 3.0?"

The argument for trouble is: Software 3.0 (Karpathy's framing — code increasingly written and executed by AI agents on behalf of humans) collapses the distinction between user and application. Every workflow becomes a chain of agent invocations. The traditional identity-permission model — user authenticates, user takes actions — gets replaced by something fuzzier: a human goal triggers a chain of agent authentications that traverse systems on behalf of the human.

The argument for why Setu's framing survives, and arguably gets stronger: the identity-permission graph doesn't disappear in Software 3.0, it gets denser. Every agent gets its own service-principal-equivalent. Every agent invocation is an edge. Every credential the agent holds is a node. The graph that was already too sparse for humans to reason about (typical enterprise: 50,000 identities, 200,000 access edges) becomes the graph that has to be reasoned about (Software 3.0 enterprise: 500,000 agent-identities, 2 million edges, half of them ephemeral).

Graph as the substrate gets more important, not less. The model on top of the graph might change — in fact, will change, because temporal-graph networks become more useful when the graph itself is changing every second instead of every week — but the substrate persists. The moats above persist with it: per-tenant analyst feedback compounds whether the analyst is triaging human or agent activity; air-gapped deployment matters more in a world where regulated enterprises won't let their AI agents phone home to a SaaS.

What's not a moat, restated

Putting it all together. Things we will not claim as moats in future writing:

• The math (public domain since 2011).
• OCSF support (table stakes).
• "Cornered resource" derived from data living in the customer's own tenant (deployment inertia, not a moat).
• Patents (defensive shield, not a customer-facing moat).
• The brand (we are pre-brand; claiming brand power would be silly).
• Network economies (we don't have a network — every tenant is isolated).
• Scale economies (we are sub-scale; incumbents have us beaten on raw cost-per-event).

Things we will claim, and that we will work to deserve:

• Per-tenant analyst feedback as compounding training data — process power that becomes switching cost over time.
• Counter-positioning against incumbents whose architecture forecloses air-gapped deployment.

Why this exercise matters

A vendor who claims five moats in their fundraise deck and has one real one tends to lose to a vendor who claims one and has one. The fake moats absorb effort that should go into the real ones. The team starts to believe the deck. Hiring decisions, roadmap decisions, partnership decisions all get warped by the assumption that the moats exist.

If the moat is per-tenant feedback, then the engineering priority is the feedback loop — UI for triage, instrumentation of triage decisions, training pipelines that consume them, model versioning per tenant. If the moat is air-gapped deployment, the engineering priority is shipping infrastructure that runs disconnected — local LLMs, no-call-home defaults, SBOM transparency. These are different roadmaps. Pretending you have both moats lets you avoid choosing, and avoiding the choice means neither gets built well.

We're choosing both, because we have evidence both are real and they reinforce each other (an air-gapped tenant generates feedback that a SaaS competitor will never see). But we're not pretending we also have brand, network effects, scale economies, or a cornered resource. Naming the powers honestly is how we make sure the work goes where it has to go.

The version of the moats conversation that survives diligence is the version where the founder can say, in one sentence: "Here are the two things that get harder for a competitor to copy every quarter, and here is what we're doing this quarter to make them harder." That is the only version of the conversation worth having.