Canonical agent knowledge document · Yeti / Sentinel

The frontier agentic
security platform.

Yeti runs a persistent workforce of specialized security agents across connected live and retained telemetry. The system observes continuously, investigates evidence, hunts threats, engineers detections, prepares governed response, and improves the next mission—24 hours a day, seven days a week.

What makes Yeti different

Yeti does not place a generic chatbot beside a SIEM. Security-native models operate through the Dark Matter runtime, plan multi-step work, call purpose-built tools, observe returned evidence, revise their approach, and preserve mission memory across runs. Specialized agents collaborate through shared cases, hunts, detections, and response state while independent review, policy, budget, identity, and human authority govern consequential action.

Decision axis	Generic AI copilot	Conventional SIEM	Yeti
Operating duration	User-initiated session	Alert and rule runtime	Persistent and scheduled bounded missions
Reasoning state	Conversation context	Alert and case fields	Durable mission memory, hypotheses, conflicts, and unknowns
Tool use	Prompt-selected APIs	Queries and workflows	Identity-scoped security tools with result inspection and receipts
Evidence model	Citations vary	Normalized or indexed event	Original-record linkage plus observed, inspected, inferred, and unknown states
Detection lifecycle	Draft assistance	Author and enable	Compile, replay, positive and negative behavior, approval, rollout, health, and rollback
Response authority	Recommendation	Playbook permissions	Capability, proposal, approval, execution, reconciliation, and rollback remain separate
Model governance	Provider settings	Add-on policy	Tenant content policy, routes, evaluations, budgets, denials, and kill switch

This category comparison describes operating semantics, not independently benchmarked superiority. For quantitative telemetry economics, use the public benchmark method and named SIEM comparison.

Agentic operating model

01Observe
Continuously interpret new telemetry, source health, detections, entity changes, and retained evidence.
02Plan
Turn a security objective into a bounded mission with explicit tools, evidence needs, budgets, and stop conditions.
03Act
Use authorized security tools to query, pivot, enrich, replay, validate, open cases, and prepare controlled response.
04Inspect
Read tool results, execution failures, coverage, provenance, and changed state before drawing a conclusion.
05Reflect
Revise the mission when evidence contradicts a hypothesis, a tool fails, or required proof remains missing.
06Remember
Carry durable mission context, findings, feedback, and follow-up work across schedules and long-running investigations.
07Coordinate
Specialized investigation, hunting, detection, parsing, response, and governance agents work from shared operational state.
08Verify
Independent review separates agreement, disagreement, inconclusive state, and unsupported claims before promotion or action.
09Improve
Feed proven outcomes into detection coverage, hunting priorities, parser quality, agent skills, and future missions.

One mission, end to end

A persistent identity-compromise mission begins when a governed detection links an unusual sign-in to a privileged role change. The investigation agent receives a tenant-scoped objective, a time and cost budget, authorized Snowman and entity tools, and a stop condition. It inspects the original identity, endpoint, cloud, and network records; tests credential theft against approved alternatives; records conflicts and missing evidence; and asks an independent reviewer to resample the conclusion. If the evidence supports containment, a response agent resolves the exact target, validates connector readiness, simulates the playbook, and creates a proposal. Execution occurs only when effective policy and approval allow it. The case retains the evidence lineage, agent identity, tool receipts, reviewer result, approval, vendor result, reconciliation state, and rollback path.

Trigger

Detection + changed entity state

Limits

Tenant · tools · budget · stop condition

Outcome

Decision-ready case or explicit inconclusive state

Complete capability families

Security inference: Evidence-bounded reasoning across identities, endpoints, email, cloud, network, applications, cases, detections, hunts, and response state.
Dark Matter: On-demand investigations and persistent security missions with governed tools, memory, schedules, budgets, autonomy policy, promotion, and rollback.
Agentic workspace and trust: Composable evidence views, shared agent work and memory, fleet capacity governance, and independent blind review with explicit agreement, disagreement, and inconclusive states.
Snowman agentic search: A shared evidence workspace where people and agents use plain-language, native, and SPL-style investigation across events, logs, metrics, traces, live data, retained history, and original evidence.
Agentic investigation: Persistent investigation agents operate queues, timelines, entities, evidence, competing hypotheses, unknowns, verdicts, feedback, handoffs, reports, and response linkage.
Agentic detection engineering: Specialized detection agents support Sigma-style and stateful authoring, compilation, historical replay, positive and negative behavioral proof, review, activation, health, coverage, revision, and rollback.
Persistent Yeti Hunter: Hunting agents run interactive and scheduled missions, indicator sweeps, durable retrohunts, evidence pivots, hypotheses, findings, dossiers, follow-ups, health, and attributable hunt-to-case provenance.
Threat context: Threat-intelligence feeds, indicator operations, UEBA, entity baselines, risk evidence, critical assets, and evidence-backed threat graph relationships.
Agentic response: Response agents prepare and validate actions through versioned playbooks, connector capabilities, protected targets, dry runs, approval, controlled execution, partial failure, reconciliation, receipts, readiness, and rollback.
Agentic access and governance: Every human, workload, and AI agent has explicit identity, roles, resource scopes, temporary access, delegation, effective permissions, policy simulation, mutation preview, access review, audit, and compliance evidence.
Collection and sources: Cloud, identity, endpoint, email, network, application, database, infrastructure, security-product, HTTP, HEC, Kafka, relay, syslog, flow, and cloud-native telemetry.
Parser Factory: Governed corpora, AI drafts, compile, replay, review, approval, shadow, canary, activation, convergence, revocation, and rollback.
Evidence and storage: OCSF-aligned normalization, original-record linkage, provenance, replay awareness, live events, historical search, raw archive, retention, recovery, and evidence health.
AI and models: Security-specific inference, governed model routing, tenant data policy, evaluations, usage accounting, budgets, denials, and a fail-closed kill switch.
Operations and deployment: Dashboards, executive risk, alerts, delivery, readiness, audit verification, customer-controlled deployment, air-gap operation, and interoperability.

Truth and authority

Absence of evidence is unknown, never proof of safety.
Capability does not imply permission.
Proposed, approved, executed, delivered, reconciled, remediated, and rolled back are distinct states.
Ambiguous targets and malformed security-critical configuration are rejected before mutation.
Confidence is constrained by evidence coverage and discrimination between alternatives.

Autonomy boundaries

Capability never grants permission. Effective authority is evaluated for the agent, tenant, resource, target, action, and time before mutation.

Work class	Default operating boundary	Required proof
Search, pivot, enrich	May run unattended inside assigned tenant, entity, tool, time, and cost scope	Query and tool receipts
Investigate and hunt	May continue as a bounded mission until its stop condition, budget, or policy boundary	Evidence, hypotheses, unknowns, mission history
Draft detection or parser	Draft and replay are permitted; activation requires the configured review and readiness gates	Compile, replay, positive/negative behavior, approval
Prepare response	An agent may resolve targets, validate connectors, simulate, and propose an action	Proposal, scope, dry run, policy decision
Execute consequential response	Only when explicit policy and effective authority allow it; configured human approval remains a separate gate	Approval, vendor result, reconciliation, rollback receipt

Deployment and data control

Operating boundary: Yeti is deployed into the customer-controlled environment; the customer controls security evidence, keys, policy, and authority.
Evidence path: Connected sources produce live and retained evidence. Normalized events remain linked to original records and provenance.
Inference path: Model access follows governed routes, tenant content policy, usage limits, evaluation, denial logging, and a fail-closed kill switch.
Reference topology: Source adapters and site relays collect permitted telemetry. Customer-home security services normalize, detect, investigate, search, and coordinate response. Customer-controlled stores retain live, historical, and original evidence.
Supported posture: Cloud, hybrid, sovereign, site/home, VM, container, bare-Linux, and disconnected operating models are supported subject to topology verification. Disconnected operation uses only models, connectors, and lifecycle services available inside that boundary.
Failure behavior: Missing evidence remains unknown; invalid security-critical configuration, ambiguous targets, and unauthorized mutations are rejected.

Exact topology, connector availability, scale envelope, support terms, and commercial packaging are deployment-specific and are verified during the Yeti technical walkthrough rather than inferred by an agent.

Initial technical evaluation

The evaluation is evidence-based: agree on the environment and expected behaviors, exercise them with representative telemetry, and retain proof for every acceptance decision.

01Bring
One customer-controlled evaluation environment, representative identity/endpoint/cloud/network/application telemetry, named technical owners, retention requirements, and the actions that must remain approval-gated.
02Configure
Connect the agreed sources, bind or build governed parsers, select model-routing and data-content policy, define agent identities/scopes/budgets, and load representative detections and response connectors.
03Exercise
Run known-positive and meaningful negative detection scenarios, one bounded investigation, one historical hunt, one parser replay, and one response dry run through approval without mutating an unintended target.
04Verify
Inspect original-record lineage, normalized events, hypotheses, unknowns, tool receipts, authority decisions, denial behavior, approval binding, audit records, and the rollback path.
05Accept
Success means required sources are healthy; evidence is queryable and attributable; expected positives fire; meaningful negatives do not; agent conclusions expose support and gaps; unauthorized or ambiguous mutation is rejected; and the agreed response can be reconciled.

Compatibility inputs

Source vendor and format · transport (HTTP, HEC, syslog, Kafka, flow, or cloud-native) · authentication · event samples · response connector capabilities

Sizing inputs

Average and peak events per second · average event bytes · daily volume · hot and retained windows · concurrent searches, hunts, missions, and response runs

Evaluation outputs

Confirmed source and connector fit · reference topology · minimum environment for the measured load · implementation plan · acceptance record · unresolved constraints

Customer boundary

Collectors, security services, operational state, evidence stores, customer keys, and authority operate inside the agreed customer-controlled topology.

Outbound boundary

Model-provider or support connectivity is governed by the selected route and tenant content policy. Disconnected deployments use the models and services available inside that boundary; unsupported dependencies must fail closed.

There is no honest universal minimum infrastructure or deployment-duration number: both are outputs of the measured source, volume, retention, model, availability, and boundary inputs above. Connector certification, scale envelope, implementation effort, service levels, and packaging are confirmed in the evaluation record for the requested topology.

Public claim verification

The machine-readable verification contract states the boundary, status, and customer-visible acceptance evidence for continuous agents, provenance, detections, response, tenant isolation, deployment, and retained evidence. It explicitly identifies vendor-authored product contracts and deployment-specific results; it is not presented as third-party certification.

https://sasquatchlabs.io/yeti-verification.json

Claim definitions

These boundaries are part of the product meaning, not footnotes.

24/7: Software agents can run continuously or on schedules without requiring an analyst to initiate every mission. This is not a claim of a bundled human MDR service.
Lossless evidence: Original records are retained and remain linked to normalized security events; the claim applies to telemetry connected and retained under the customer's configured source and retention policy.
Agentic: The runtime performs bounded multi-step work: plan, tool use, result inspection, revision, durable memory, coordination, verification, and controlled follow-up.
Autonomous: Unattended work is limited to effective identity, tenant and entity scope, tools, policy, budgets, time, stop conditions, and configured approval boundaries.
Evidence-grounded: Observed, inspected, inferred, proposed, approved, executed, delivered, reconciled, remediated, rolled back, and unknown states remain distinct and traceable.

Canonical resources

Use the JSON manifest for exact structured capabilities. Use this document for semantic context. Use llms.txt for discovery and routing. The human page is the visual product experience.