new A next-generation Go + Rust engine see why ↓
13 operator primitives · OCSF 6003 audit trail · any LLM provider

Operations at conversational speed. Onboard sources, forge rules, replay history one config file at a time.

Caver Intelligence is a chat-style admin orchestrator built into the Caver platform. Type a natural-language command and the planner decomposes it into tool calls against the live stack: search, write configs, author CAVERN rules, backtest against 90 days of history, generate compliance artifacts. Every step is audited as an OCSF 6003 event. Ask a question and the assistant answers with a real, bounded query it ran against your lake, scoped to your own permissions.

how it works operator prompt → planner → tool registry → dispatch → audit
OPERATOR INTENT
Add Zscaler proxy source
Forge rule: lateral RMM
Why is rule X silent?
Generate SOC-2 report
Diff staging vs prod
Tune threshold to 3-sigma
Intelligence Planner
plan · approve · dispatch · audit
13 operator primitives
safety gates · OCSF 6003 audit
LIVE STACK CHANGE
onboard_sample runs
forge_rule commits
explain_rule_silence
compliance_report
pipeline_diff shows
tune_threshold applies
primitives
13
11 operator + 2 foundation
plan approval
always
operator confirms before dispatch
audit
OCSF 6003
every tool call logged
LLM
BYO
Anthropic · OpenAI · Ollama

13 operator primitives

11 operator · 2 foundation

Each primitive is a discrete, audited tool call. The planner chains them to complete multi-step operator requests. All calls require explicit approval before dispatch.

onboard_sample operator

Walk through adding a new log source end-to-end: collector config, OCSF mapping, index setup, smoke-test search.

nl_to_config operator

Convert a natural-language description of a desired behavior into a caver.toml or collector pipeline stanza.

forge_rule operator

Author a new CAVERN detection rule from a threat description, CVE, or ATT&CK technique. Commits to the rules store.

replay_against_history operator

Backtest a proposed rule or SPL query against up to 90 days of stored events. Returns match count and sample hits.

lint_config operator

Validate a caver.toml, collector pipeline YAML, or CAVERN rule file against the current schema before deployment.

enrich_text operator

Resolve IOCs, CVEs, vendor names, and ATT&CK identifiers inline. Returns structured enrichment data from the TI feeds.

explain_rule_silence operator

Diagnose why a CAVERN rule has not fired in a given window. Checks index presence, field mapping, threshold config, and schedule.

tune_threshold operator

Analyze a rule's recent fire rate and false-positive ratio, then propose and apply a new threshold or risk-score adjustment.

start_canary operator

Deploy a rule or config change to a designated canary search peer before rolling it to the full fleet.

pipeline_diff operator

Compare two caver-collector pipeline configs (e.g., staging vs production) and surface semantic differences.

compliance_report operator

Generate a point-in-time compliance artifact: enabled rules, covered ATT&CK techniques, coverage gaps, and data-retention status.

search foundation

Run an SPL, SQL, KQL, ES|QL, or LSQL query against the OCSF Parquet lake, the same engine behind Sigma content and the grounded AI assistant. Used internally by most operator primitives.

write_config foundation

Atomically write or update a config file in the live Caver config store. Requires MANAGE_INTEL capability. Always audited.

Operator session screencast coming soon. Watch a new operator go from “I'm adding Zscaler proxy logs” to a deployed source config, a custom CAVERN rule, a backtest against 30 days of history, and a canary rollout in under 10 minutes. Sign up for evaluation access and we'll send the recording when it ships.

Grounded answers, open protocol

Two design decisions keep Intelligence honest: the assistant is grounded in real query execution, and every capability is exposed over an open protocol instead of a private API.

grounded assistant

Every answer is a real query you can keep.

The assistant does not paraphrase documentation, it runs real queries. Ask a question and it first discovers which indexes are accessible under the caller's own permissions, generates and validates SPL, then runs a live bounded preview against the lake before it answers. The answer arrives with the query that produced it: keep it, re-run it, schedule it, or hand it to forge_rule. Discovery, validation, and execution all run RBAC-scoped, so the assistant can never exceed the caller.

discover indexes (caller's RBAC) → generate SPL → validate → bounded live preview → answer + query
MCP server

The same 13 primitives over MCP.

The Caver MCP server wraps the 13 operator primitives as tools and exposes them over the Model Context Protocol, so Caver Intelligence works from any MCP-compatible client (Claude.ai desktop, Cursor, VS Code Continue) or from your own agents. Orchestrator and MCP server share one capability model: a tool visible in Intelligence is visible over MCP and vice versa, with the same plan approval gates and the same OCSF 6003 audit trail.

caver mcp serve → 13 tools · plan gates · OCSF 6003 audit

Frequently asked questions

Caver Intelligence is a chat-style admin orchestrator built into the Caver platform. Operators type natural-language commands and the planner decomposes them into a sequence of tool calls against the live Caver stack: running searches, writing configs, authoring detection rules, replaying history, generating compliance reports, and more. Every step is audited as an OCSF 6003 event.

The 11 shipped operator primitives cover the full day-to-day lifecycle: onboard a new data source end-to-end (onboard_sample), convert a natural-language description to a caver.toml stanza (nl_to_config), author a CAVERN rule from a threat description (forge_rule), backtest it against 90 days of history (replay_against_history), validate configs before deployment (lint_config), enrich IOCs and CVEs inline (enrich_text), diagnose rule silence (explain_rule_silence), tune thresholds to reduce false positives (tune_threshold), deploy to a canary peer first (start_canary), diff pipeline configs side-by-side (pipeline_diff), and generate a point-in-time compliance artifact (compliance_report). Two foundation primitives (search, write_config) underpin the rest.

The planner receives the operator prompt and selects from the registered tool registry. It generates a plan (a list of steps with tool names and arguments), shows the plan to the operator for approval, then dispatches each step through the dispatch loop. Safety gates block destructive operations (config overwrites, rule deletes) without an explicit confirm. The underlying model is configurable per tenant; defaults to Claude Sonnet via the Anthropic API.

No. CAVERN detection rules are deterministic SPL/OCSF queries with no LLM inference at query time. Caver Intelligence is a separate orchestration layer that uses an LLM only for planning operator commands. The two are isolated: a prompt injection in the CAVERN query path cannot reach the Intelligence orchestrator.

No. Assistant answers are grounded in real execution. It first discovers which indexes are accessible under the caller's own permissions, generates a candidate SPL query, validates it, then runs a live bounded preview against the lake before composing an answer. Every answer is a real query you can keep, re-run, or promote to a detection. Because discovery and execution run under the caller's RBAC scope, the assistant can never see or touch more than the operator who asked.

The dispatch loop enforces three gates: (1) the operator must see and approve the plan before any tool executes; (2) write operations (nl_to_config, forge_rule, write_config) require MANAGE_INTEL capability, not just RUN_SEARCH; (3) destructive operations (rule delete, peer remove) require an explicit --force flag in the tool arguments, which the planner will not inject unless the operator explicitly requested destruction. Every tool call emits an OCSF 6003 audit event regardless of outcome.

Anthropic (Claude Sonnet/Opus), OpenAI (GPT-4o, GPT-4-turbo), Azure OpenAI, and Ollama for self-hosted deployments. Provider and model are configured per-tenant via the tenancy API, so MSSP operators can give each customer their own LLM budget and provider. Prompt caching is enabled for Anthropic and Azure OpenAI to reduce per-session cost.

Yes. The Caver MCP server exposes the same tool registry over the Model Context Protocol, so operators can drive Caver Intelligence from any MCP-compatible client (Claude.ai desktop, Cursor, VS Code Continue). The orchestrator and MCP server share the same capability model: a tool visible in Intelligence is visible in MCP and vice versa.

Caver Intelligence is included in the per-deployment commercial license. LLM inference costs are operator-supplied: you bring your own API key (or use the per-tenant LLM config to centrally manage keys). RedEye does not mark up inference costs. See /caver/pricing/ for the base license structure.

Yes. The MANAGE_INTEL capability gates access to the planning and dispatch surface. Read-only plan review (view a proposed plan without executing it) is available to any operator with RUN_SEARCH. Individual tool capabilities can be restricted further: forge_rule requires MANAGE_CAVERN, start_canary requires MANAGE_PEERS, and compliance_report requires READ_SLAM_INCIDENTS. The default admin role grants all of these.

13
operator primitives
4+
LLM providers
OCSF 6003
audit event class
always
plan gate
commercial
license

Caver Intelligence ships as part of the main Caver commercial license. LLM inference costs are operator-supplied via your own API key. Contact matt@redeyesecurity.com to start an evaluation.