Most security platforms try to centralize your data. We don't.
The legacy SIEM was a forwarder with a query language bolted on. To watch you, it had to swallow you, every event, every endpoint, every cloud account, all dragged into a single warehouse it owned. That worked when telemetry was small. It does not work anymore.
A modern security stack produces tens of terabytes per day across identity providers, cloud control planes, EDR sensors, SaaS platforms, AI tooling, email gateways, and increasingly, agentic systems writing code on a developer's behalf. Forwarding all of it costs more than the rest of the security budget combined, and the data is stale by the time the SIEM catches up.
Zaun takes the opposite approach. We treat your existing systems as the source of truth. We send the 1% of high-signal data that needs to live close to detection and investigation. We query the rest in place when an investigation calls for it. The result is a security platform that is faster to deploy, cheaper to run, and honest about what it is doing with your data.
The rest of this paper walks through what that looks like in practice, starting with a single architecture diagram and then drilling into each layer.
One platform, four engines, every system you already run.
Zaun is composed of four cooperating engines: a decentralized Lake, a Detection engine, a Runbook engine, and an Investigation agent. They sit behind 100+ connectors that read from your existing tools and write back to them when an action is approved.
What flows where
On the left, your environment. Zaun connects to identity providers, cloud accounts, endpoint tools, AI and SaaS providers, and email and network sources through OAuth and signed API tokens. No agent installation is required for any of these surfaces. An optional on-prem collector is available for orgs with strict data-egress requirements.
In the middle, the four engines. The Lake holds the high-signal slice of telemetry we need close at hand. The Detection engine evaluates rules in real time and on a schedule. The Runbook engine executes workflows when those rules fire, and gates sensitive actions behind approvals. The Investigation agent fans out across systems to assemble timelines and recommend a next step.
On the right, outcomes. Every customer-visible result lands in one of three places: an action taken in your IAM or EDR, a notification sent to your team, or a piece of audit evidence written to your ledger.
Decentralized SIEM. Send the 1%, query the rest in place.
The Zaun Lake is the small, fast, queryable layer that sits in front of your existing telemetry stores. It holds the slice of data that detection and investigation actually need close at hand. Everything else stays where it is.
What lives in the Lake
The Lake holds three categories of data. First, the high-signal slice from each connected source: detections, authentication events, privilege changes, AI prompts and responses, and anything correlation needs in sub-second time. Second, the normalization layer that maps every source to a common schema (OCSF, ECS, and Sigma where applicable) so a rule written for Okta works for Entra without a rewrite. Third, an enrichment layer that joins identity, geo, and threat-intel context onto every event as it lands.
What stays in place
Cold logs, archives, and the long tail of low-signal telemetry stay in your existing warehouse, S3 bucket, or SIEM. When an investigation needs it, Zaun queries through an authenticated connector, returns the slice we asked for, and discards the rest. You pay for the storage you already have. We pay for the compute we use.
- Storage
- Apache Iceberg on S3-compatible object store, per-tenant key
- Streaming
- Kafka with per-tenant topics and IAM-bound consumers
- Query
- Trino-compatible SQL · entity-graph traversal · time-series indices
- Retention
- 13 / 90 / 400 days · per-source override · zero-day delete on request
- Schema
- OCSF first, ECS-compatible, Sigma rules import natively
- Residency
- us-east-1, us-west-2, eu-west-1 · region-pinned per tenant
- Encryption
- AES-256 at rest, TLS 1.3 in transit, customer-managed keys available
Plain English in. Versioned rules out. No black box.
A detection at Zaun is a plain-text artifact, written for your stack, reviewed by an engineer, version-controlled, and observable end to end. Every customer can read every rule running on their tenant. Every customer can edit them.
How a detection gets built
It starts with a plain-English specification: what behavior matters, on which entity, within what time window, with what threshold. The Forward Deployed Engineer assigned to your account writes the spec with you. An AI co-authoring step translates the spec into a structured rule, generates a test fixture, and runs it against the last 30 days of your real telemetry. The engineer reviews, edits, and approves. The rule ships behind a feature flag, gets observed for a week, and graduates to production.
Why this is different
Most detection engineering teams ship a rule, watch it produce false positives, and quietly mute it. Zaun closes the loop. Every rule emits metrics on hit rate, precision, and analyst feedback, and feeds that signal back into the next tuning pass. Rules that produce noise get rewritten, not silenced. Rules that miss real incidents get a regression test added and a targeted fix.
Automation that's easy to read out loud.
A runbook is what runs when a detection fires. At most platforms, that is a sequence of black-box steps with a few configurable knobs. At Zaun, a runbook is a plain-text workflow: every step, every input, every action, every gate, every output, all visible, all editable, all logged.
The five parts of every runbook
A runbook starts with a trigger: a detection fires, a customer reports a phish, a scheduled hunt completes, or a risk score crosses a threshold. The runbook's gather step pulls every relevant signal from the connected systems: recent identity events, EDR alerts, mailbox rules, geo lookups, related incidents from the last 30 days. The analyze step scores against the per-user behavioral baseline, clusters with related alerts, and builds a timeline.
Then the runbook hits a decision: confidence high enough to act on its own, or kick to a human? Zaun ships defaults, but every customer tunes their thresholds. High-confidence cases run an action: suspend the user in the IdP, isolate the host in the EDR, revoke the OAuth grant, quarantine the email. Lower-confidence cases open an investigation and queue for human review with a 15-minute SLA. Either way, the runbook closes with an audit record: every step, every input, every output, every actor, every timestamp, cryptographically signed.
Approval gates
Not every action should run on its own. By default, low-blast-radius actions (suspending a session, isolating a host) auto-execute. High-blast-radius actions (modifying admin roles, deleting data, opening a firewall) require an explicit human approval. Every gate is configurable per action, per system, and per environment.
Stories, not dashboards. Built by AI agents, reviewed by humans.
An investigation is what happens between a clustered alert and a triage decision. Zaun runs a multi-step AI agent that pulls timeline data from every connected source, reasons about what happened, generates a hypothesis with evidence, and recommends a next action. The human reviewer reads a story, not a dashboard.
What the agent does
The agent operates as a small set of cooperating tools, each scoped to a single connector. When an alert cluster lands, the agent queries identity events for the implicated user, EDR detections for the host, mailbox rules for any forwarding changes, recent OAuth grants, and anomaly scores against the baseline. It builds a minute-by-minute timeline, flags the events most likely to be causal, and writes a structured report.
What the human reviews
The reviewer sees the report, not the raw queries. A hypothesis in plain English. A list of evidence with each event linked back to its source. A recommended action with a rollback plan. An audit trail of every query the agent ran. The reviewer can accept, modify, or reject the recommendation, and that feedback flows into the next tuning pass.
- Reasoning
- Multi-step agent · scoped tool use · per-tenant isolation
- Evidence
- Every claim linked to a source event with a verifiable trace
- Output
- Structured report · timeline · hypothesis · recommendation
- Approval
- Human reviewer accepts / modifies / rejects with reason
- Feedback
- Reviewer decisions feed back into detection + runbook tuning
- Privacy
- No customer data leaves your tenant boundary for model training
The trust boundary is visible. Every byte that crosses it is logged.
Zaun runs as a multi-tenant control plane in three regions, region-pinned per customer. Connectors are outbound-only from your environment to ours. Every query is logged, every credential is scoped, and every grant is revocable in one click.
How a Zaun deployment is shaped
On the customer side: the systems you already run, untouched. Zaun does not ask you to install agents on your endpoints, redirect your DNS, or proxy your network. We connect via the same OAuth flows and signed API tokens you would grant to any mature SaaS vendor.
On the Zaun side: a multi-tenant control plane with strict per-tenant isolation at the connector, key, and storage layer. Each tenant's Lake is encrypted with a per-tenant key, optionally rooted in your KMS. Each connector has its own credential, its own scope, its own audit trail. If you revoke a connector, every byte associated with it is purgeable in 24 hours.
For the regulated and air-gapped: an optional on-prem collector runs as a stateless container in your environment. It buffers events, signs them, and ships them outbound to our control plane over mTLS. No inbound holes, no shared infrastructure, no PII ever leaves your subnet without your explicit grant.
- Compliance
- SOC 2 Type II · ISO 27001 · HIPAA-ready · FedRAMP in progress
- Regions
- us-east-1 · us-west-2 · eu-west-1 · per-tenant pinning
- Auth
- OAuth 2.1 · SAML / SCIM · short-lived signed tokens · per-connector scoping
- Network
- Outbound-only from customer · mTLS · pinned certs
- Data plane
- Multi-tenant logical · per-tenant key · region-pinned · KMS-rooted
- Audit
- Append-only ledger · cryptographically signed · exportable in real time
- Deletion
- Per-source · per-tenant · 24-hour SLA
Programs you can stand up in an afternoon.
The four programs below are not roadmap items. They are how lean teams ship working security coverage on Zaun, with a Forward Deployed Engineer building rules, runbooks, and dashboards specific to your environment.
Controlling enterprise AI use
Discover every AI tool, govern every grant, watch every agent in flight. OAuth, MCP, Copilot, Claude Code, in-house agents.
Read the program →Compromised accounts, found early
Per-user behavioral baselines across IdP, EDR, email, and cloud. Containment in your IAM and EDR with one human approval.
Read the program →Posture and runtime, in one queue
CSPM tells you what is misconfigured. Zaun also tells you when it is being abused. AWS, Azure, GCP, normalized.
Read the program →Insider risk that holds up in counsel
Behavioral baselines and audit-ready evidence. Built on Zaun co-founder Tyler's SAIC heritage with the federal insider-threat program.
Read the program →Setup in hours. Tuned by Friday. Production by next week.
Every Zaun deployment ships with a Forward Deployed Engineer, an integration sprint, and a tuning loop. There is no procurement-grade onboarding plan stretched over a quarter. Most customers are operational the same day they OAuth.
What you control
You own the detection set. You own the runbook set. You own the audit trail. You own the data residency. You own the deletion policy. You own the keys, if you want to. Everything Zaun ships is plain text, signed, exportable, and forkable.