Security Charter

Every monitored target, probe result, and audit record carries an owner identifier. Row-level security policies are enforced in the database itself, so a query can only ever return rows belonging to the authenticated user — not merely filtered in application code.

• Read, insert, update, and delete policies are all scoped to the signed-in owner.
• The remediation audit log is append-only: rows cannot be edited or deleted.
• The public demo runs on a separate sandbox dataset containing no real customer records.

All traffic to the dashboard, our APIs, and the probe scheduler runs over TLS 1.2+ with HSTS. Data at rest, including telemetry and audit logs, is encrypted using AES-256 on managed storage. Service credentials live in a secrets store and are never committed to the codebase or exposed to the browser.

Browser clients use a publishable key constrained entirely by row-level security. Privileged keys exist only in server-side handlers and are never shipped to the client bundle. Scheduled sweeps run through a dedicated endpoint that verifies its caller before touching any data.

Autonomous remediation is gated by an explicit registry that classifies every action by blast radius. Nothing runs unless it is registered.

• Read-only — re-probe, DNS re-resolve, TLS inspection. No side effects; always allowed.
• Reversible — bounded actions with a defined rollback path, executed with retry limits and recorded in the audit log.
• Guarded — anything that could affect live traffic, DNS records, or billing. Held for explicit human confirmation.

Every attempt — successful or not — writes an immutable audit entry with the trigger, classification, and outcome. Switching the Autonomous Engine off halts all non-read-only actions immediately.

Probes are lightweight HEAD/GET requests with strict timeouts and a fixed schedule. They are rate-limited to avoid adding load to a system that is already degraded, and they never replay writes against your endpoints.