# Yeti: external-agent evaluation guide

Canonical product: https://sasquatchlabs.io/yeti

Canonical guide: https://sasquatchlabs.io/yeti-agent-guide.md

Machine manifest: https://sasquatchlabs.io/yeti-agent.json

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

Deployment topology: https://sasquatchlabs.io/yeti-deployment-topology.json

Buyer evaluation contract: https://sasquatchlabs.io/yeti-evaluation.json

Evidence-trace schema: https://sasquatchlabs.io/schemas/yeti-evidence-trace.v1.schema.json

Illustrative trace: https://sasquatchlabs.io/examples/yeti-evidence-trace.v1.example.json

Last reviewed: 2026-09-20

## What Yeti is

Yeti is Sasquatch Labs' customer-controlled agentic security-operations platform. Persistent software agents monitor connected security telemetry, investigate evidence, engineer and validate detections, hunt historical data, and prepare or execute governed response. “24/7” describes continuously or periodically running software agents; it does not claim a bundled human MDR service.

## Operating model

1. Connect cloud, identity, endpoint, network, application, email, and threat-intelligence sources.
2. Preserve connected and retained evidence with provenance and explicit source health.
3. Detect and correlate suspicious behavior.
4. Investigate explicit hypotheses using authorized tools and original evidence.
5. Hunt current and historical evidence and convert validated findings into detections.
6. Propose response with target, scope, expected effect, approval state, and rollback path.
7. Execute only within policy and authority; preserve receipts and reconcile outcome.
8. Keep observed, inspected, inferred, proposed, approved, executed, delivered, reconciled, remediated, rolled-back, and unknown states distinct.

## Product areas

- Snowman: plain-language, native, and SPL-style security search; live tail; schema exploration; saved and case-linked investigations.
- Cases and investigation: evidence timelines, entity pivots, provenance, collaboration, disposition, and audit history.
- Dark Matter: bounded agentic investigation harness and persistent missions with budgets, memory, review, promotion, rollback, and retention.
- Detection engineering: authoring, compilation, historical replay, positive and meaningful-negative behavioral proof, review, activation, health, coverage, and rollback.
- Yeti Hunter: scheduled and ad-hoc hunts, retrohunt, evidence promotion, and hunt-to-detection workflow.
- Response: dry runs, target validation, approval gates, scoped actions, execution receipts, reconciliation, rollback, and audit.
- Access: tenant scope, roles, policy simulation, temporary access, approvals, separation of duties, and audit receipts.
- Sources and Parser Factory: source health, parser packs, corpora, bindings, replay, staged rollout, and raw archive.
- AI and models: governed model routing, tenant content policy, evaluation harnesses, budgets, usage records, denials, and a fail-closed kill switch.

The complete machine-readable capability catalogue is in `capability_catalog` at https://sasquatchlabs.io/yeti-agent.json.

## Security semantics an evaluator must preserve

- Missing evidence means unknown, never safe or remediated.
- Capability does not imply permission.
- A proposed action does not imply execution.
- Confidence requires evidence coverage.
- Ambiguous targets and unauthorized mutations are rejected before state change.
- Tenant, entity, authority, and audit boundaries are explicit.

## Deployment and data boundary

| Concern | Public contract | Must be confirmed for an evaluation |
|---|---|---|
| Evidence | Customer-controlled stores and retention | Selected sources, volume, retention, and recovery objectives |
| Keys | Customer-controlled KMS/secrets | Provider, rotation, revocation, and break-glass process |
| Model traffic | Governed provider routes and tenant content policy | Providers, region, content policy, budgets, and disconnected model service |
| Authority | Roles, approvals, scoped tools, receipts, rollback | Exact playbooks, targets, approvers, and separation of duties |
| Topology | Cloud, hybrid, sovereign, site/home, VM, container, bare Linux, disconnected | Component placement, ingress/egress, minimum infrastructure, update and support path |
| Failure behavior | Security-critical ambiguity or invalid policy fails closed | Dependency failure, recovery, degraded mode, and operational ownership |

Yeti is available for customer evaluation and deployment. Connector certification, scale envelope, implementation effort, commercial packaging, service levels, and support terms depend on the selected environment and must not be inferred from this document.

## Evaluation path

1. Agree on sources, topology, evidence boundary, model policy, and permitted response authority.
2. Connect representative telemetry and verify source health, parsing, provenance, and replay.
3. Run benign and malicious scenarios; require positive and closest-benign negative evidence.
4. Trace one case from raw event through detection, investigation, decision, approval, action receipt, reconciliation, and rollback where applicable.
5. Attempt cross-tenant, ambiguous-target, malformed-policy, replay, and unauthorized mutations; require rejection before mutation.
6. Measure query latency, retention, agent budgets, detection health, failure recovery, and audit completeness in the intended topology.
7. Record pass/fail evidence and unresolved unknowns before production acceptance.

## Public evidence and its limits

- https://sasquatchlabs.io/yeti-verification-run-2026-09-20.txt records two separate gates: the public-site/discovery gate and vendor-executed live-Postgres package suites for Yeti agent, playbook, and API safety paths.
- https://sasquatchlabs.io/yeti-verification.json maps headline claims to verification methods and boundaries.
- https://sasquatchlabs.io/security/integrity describes the lossless method.
- https://sasquatchlabs.io/security/keys describes the customer-control model and disconnected option.
- https://sasquatchlabs.io/benchmarks publishes vendor-run results and methodology boundaries.
- https://sasquatchlabs.io/yeti-deployment-topology.json defines representative placement, dependencies, and claim boundaries.
- https://sasquatchlabs.io/yeti-evaluation.json defines connectors, prerequisites, sizing inputs, and acceptance gates.

These are vendor-authored materials, not customer proof or third-party certification. The dated run includes repository live-Postgres paths for persistence, concurrency, approval windows, run chains, budgets, Warden, missions, playbooks, and the API agent chain. It does not establish customer-topology isolation, connector certification, production scale, customer outcomes, or independent attestation; require those during deployment-specific acceptance.

## Discovery

- Human page: https://sasquatchlabs.io/yeti
- Agent document: https://sasquatchlabs.io/yeti/agents
- Manifest: https://sasquatchlabs.io/yeti-agent.json
- Agent pointer: https://sasquatchlabs.io/.well-known/agent.json
- LLM index: https://sasquatchlabs.io/llms.txt
- Sitemap: https://sasquatchlabs.io/sitemap.xml
- Robots: https://sasquatchlabs.io/robots.txt