Security posture for Hoot & Hoot Interceptor.

We sell to companies whose security review process won't approve sending production data to a third-party cloud. This page documents the design decisions that make that possible — and how to reach us responsibly with a vulnerability report.

LAST UPDATED · MAY 2026 · APPLIES TO HOOT v2.0.x AND HOOT INTERCEPTOR

Found a vulnerability in Hoot?

Email santiago@watchowllabs.com with the subject line starting Hoot Security Disclosure. We aim to acknowledge within 48 hours and provide a triage update within five business days.

Please include: affected version, reproduction steps, observed impact, and any environment specifics that help us reproduce. Encrypt sensitive details with our PGP key on request. We will not pursue legal action against good-faith researchers who follow this policy.

Guardrails, scope enforcement, audit.

GUARDRAILS

140+ shell-pattern guardrails block catastrophic operations (rm -rf /, fork bombs, raw-device writes, system-file clobbering, password-file overwrites) before they execute. The agent also refuses these by reasoning — belt and suspenders.

SCOPE ENFORCEMENT

Every tool execution checks the target against your declared scope. Out-of-scope hosts are rejected at the executor layer, not just the prompt. The agent cannot accidentally hit your provider's other customers.

AUDIT LOG ON EVERYTHING

Every credential reveal, session start, license event, config change, and tool execution is recorded with the operator's email and a structured event tag. Defensible for compliance, debuggable for forensics.

Your data stays on your machine.

LOCAL-ONLY DATA

Findings, sessions, evidence, captured traffic, memory writes, and AI conversation transcripts all live in your local SQLite under ~/.hoot/. Never our servers.

FERNET ENCRYPTION AT REST

Operator-supplied secrets (AI provider API keys, tool credentials, JWT tokens) are encrypted at rest with a local Fernet key generated on first run. Never transmitted off-machine.

ZERO TELEMETRY

No usage pings, no crash reports, no anonymized events, no analytics SDK. We don't know what you scan, what you find, or who you're testing.

AUTH + LICENSE ONLY

Two outbound calls exist by design. (1) Operator-initiated Supabase Auth (email/password or refresh token → JWT) when signing in. (2) A daily license heartbeat: license_key, install_id (UUID), version, OS string. 192 bytes/day. Air-gapped mode disables even that.

Chrome extension. Local-only by design.

Hoot Interceptor is the companion Chrome DevTools panel that pipes captured HTTPS traffic to your local Hoot install. Same data-stays- local guarantee as the main product.

WHAT IT READS

While DevTools is open and the operator is browsing the inspected tab: request URLs, response bodies, auth headers (Authorization, Cookie), and request method/status/timing. Does NOT capture mouse movements, keystrokes, clipboard, browser history outside the inspected tab, or page DOM.

WHERE IT GOES

ONLY to the operator's local Hoot install at http://localhost:7337. Never to Watch Owl Labs servers. Never to Google, advertisers, analytics providers, or any third party. The connection is a local loopback request — data never leaves the operator's machine.

WHAT IT STORES

A single value via chrome.storage.local: the UUID of the operator's last-selected Hoot workspace. No traffic data, no request bodies, no credentials, no URLs. Captured traffic lives only in panel memory during the DevTools session and is discarded when DevTools closes.

EXTENSION PERMISSIONS

<all_urls> — required to call entry.getContent() on DevTools network events (without it, response bodies are not readable from extensions). Used solely while DevTools is open. storage — used only to remember the operator's last-selected workspace ID.

You hold the authorization.

  • 01Operators are responsible for ensuring they have explicit written authorization to test or intercept traffic from any application they target.
  • 02Hoot is intended for offensive security professionals — penetration testers, red teamers, security engineers — operating under contract or in-scope agreements.
  • 03For healthtech work involving PHI, operators must have a Business Associate Agreement (BAA) in place with the target organization.
  • 04Operators are responsible for the lifecycle of credentials they store in Hoot (rotation, revocation, isolation per workspace).
[ COMPLIANCE QUESTIONS ]

Diligence team needs more?

We can answer SIG, CAIQ, or custom security questionnaires individually for active sales evaluations. Email us with the framework you're working with and we'll route to the right person.