Security and data practices for AntOps.

Security overview

Public AntOps endpoints are served over HTTPS. Application services use authenticated workspace boundaries, security headers, rate limits and bounded request handling. AntOps does not claim SOC 2, ISO 27001 certification, or an independent penetration-test certification.

Security measures reduce risk; they do not make a service invulnerable or replace each customer's own security controls.

Authentication and access

Browser sessions use Supabase-issued tokens verified by the AntOps API. Platform access is associated with an immutable authentication subject and workspace membership rather than an email address alone. API keys are workspace-scoped and their plaintext secret is shown only once.

GitHub Change Risk is opt-in. The dedicated GitHub App is installed only on approved repositories and uses repository metadata, contents and pull requests read access, plus Checks read/write. It does not receive Actions, administration, secrets, members or organization permissions. AntOps does not clone repositories or execute repository code; it analyzes bounded pull-request content and writes a Check Run. Access can be removed by uninstalling the App or removing the workspace/repository mapping.

Data handling and delivery

AntOps processes account data, workspace configuration, monitoring targets, observations, events, evidence, usage and audit data needed to operate the service. Private Document Intelligence accepts only bounded, authenticated uploads; source files have no public URL.

Webhook and supported delivery destinations are restricted to approved HTTPS targets. Destination credentials are encrypted at rest, are not returned after creation, and deliveries use signed payloads, bounded retries and durable history.

Backups, recovery and retention

Operational backups include production database and private-document recovery material. Restore drills use a separate temporary database and isolated document target; they do not restore over production. Encrypted off-host backup generations are part of the operating procedure.

Operational history retention uses plan-based lifecycle management for eligible monitoring observations, resolved incidents, completed delivery history and completed Change Risk assessment history. Other data follows separate lifecycle policies. Automated destructive retention is not currently enabled in production, so AntOps does not promise that all customer data is deleted after a fixed number of days.

Customers can export account/workspace data or submit an operator-reviewed deletion request in Settings. For privacy or deletion requests, contact [email protected].

Incident response and vulnerability disclosure

AntOps maintains operational runbooks for investigating availability, dependency, queue and credential incidents. The response process focuses on confirmation, containment, impact assessment, recovery and follow-up. This is a high-level operating description, not a contractual notification timeline.

To report a potential vulnerability, email [email protected] with a concise reproduction and impact description. Please act in good faith, avoid accessing data that is not yours, avoid service disruption, and allow reasonable time for investigation. AntOps does not currently offer a bug bounty or safe-harbor programme beyond this good-faith reporting channel.

Subprocessors and data residency

This list describes the service providers currently used. A provider may process data outside the United Kingdom; AntOps does not publish a single global data-residency commitment.

Compliance and procurement

AntOps has not claimed SOC 2, ISO 27001, HIPAA, PCI DSS, or another certification unless separately agreed in writing. Security and privacy questions for procurement can be sent to [email protected].

A data-processing addendum is not automatically accepted through this website. AntOps maintains a DPA-ready outline for legal review and can discuss an appropriate data-processing arrangement with business customers.