Security posture and vulnerability reporting.

1. Reporting a vulnerability

We investigate all legitimate vulnerability reports and coordinate fixes before public disclosure. Do not disclose suspected vulnerabilities in public GitHub issues, pull requests, discussions, or social channels.

Reporting channels depend on the component:

• Open-source engine and CLI: Send a private report via the repository’s GitHub Security tab underReport a vulnerability.
• Hosted application and website: Email our security mailbox atsecurity@antaeus.io(or privacy@antaeus.io).

In your report, please include:

• The affected component, version, URL, or commit hash.
• A step-by-step description or proof-of-concept to reproduce the behavior.
• An assessment of the potential impact or severity.
• Any known mitigations or proposed remediations.

Do not include live credentials, customer data, or other sensitive information beyond what is strictly required to demonstrate the vulnerability.

2. Response and coordination timeline

When you submit a vulnerability report:

• We aim to acknowledge receipt within two business days.
• We assess severity and determine whether a fix or mitigation is warranted.
• We collaborate on a coordinated disclosure timeline (typically 90 days, or sooner if an active exploit is observed).
• We notify you when the fix is deployed and credit your contribution publicly (unless you prefer anonymity).

3. Safe harbor for security researchers

We support good-faith security research. If you conduct vulnerability research in accordance with these guidelines, we consider your research authorized within our own systems and will not pursue legal action for activity within these guidelines. We cannot authorize access to a third party's systems or bind another party's legal decisions:

• Make a good-faith effort to avoid privacy violations, data destruction, and service interruption or degradation.
• Test only against accounts, policies, and environments that you own or have explicit permission to evaluate. Do not access, modify, or download data belonging to other accounts.
• Give us reasonable time to investigate and resolve an issue before making any information public.
• Do not exploit a vulnerability beyond the minimal evidence needed to prove its existence.
• Do not perform volumetric denial-of-service (DoS/DDoS) attacks, automated brute-forcing, spam, or social engineering against maintainers or users.

4. Scope

The following surfaces are in scope for responsible disclosure:

• The open-source core engine and CLI repository (github.com/antaeusio/antaeus).
• The hosted beta application and API (app.antaeus.io).
• The public website (antaeus.io).

Third-party identity and hosting providers (Cloudflare, Clerk, Buttondown, Google) operate their own vulnerability disclosure programs; issues unique to their infrastructures without Antaeus-specific misconfigurations belong in their respective programs.

5. Data minimization and tenant boundaries

Our security architecture begins by minimizing stored personal data:

• No training on customer content: We do not use your policy definitions, prompts, or evaluation inputs to train foundation models.
• Tenant data isolation: Hosted accounts are partitioned through tenant-scoped access checks and queries in a shared Cloudflare D1 database per environment. This is logical isolation, not a separate database for every customer.
• Optional analytics: Google Analytics is enabled only after acceptance. Our custom events omit customer policy/source text, input content, names and emails; Google still processes pseudonymous browser and device information. Structured Decisions and saved examples can contain personal information. See the privacy notice for providers, retention and choices.
• Client-side transparency: Policy evaluation runs locally in the open-source CLI without external network calls unless you explicitly configure a remote provider.

6. Infrastructure and application security

The Antaeus web properties are built on isolated edge infrastructure:

• Edge delivery: Assets and API endpoints run on Cloudflare Workers over HTTPS with Cloudflare traffic protection. We do not promise a particular minimum TLS version without a verified configuration check.
• Authentication: Identity management is provided by Clerk, using supported sign-in methods such as email codes and Google. API credentials and console sessions have separate admission checks. Multi-factor authentication is not promised for every account.
• Minimal attack surface: The public website serves static HTML without client-side frameworks, databases, or third-party ad tags.

7. Supply chain and release integrity

We secure the software supply chain through automated verification:

• Cryptographic verification: Release archives include SHA-256 checksums and build provenance attestations.
• Build locking: Build and deployment processes enforce atomic build locks (with-build-lock) to serialize build-producing commands in a shared checkout.
• Least privilege: Automated GitHub Actions deployments should use scoped Cloudflare tokens. Token permissions and expiry need separate verification; the public website does not establish the scope of a saved credential.

8. Security contacts and steward governance

Antaeus is operated by Milana Kerbel and Pavel Kerbel. Security inquiries and reports may be addressed tosecurity@antaeus.ioor privacy@antaeus.io. For how personal information is handled, see ourprivacy notice and ourterms of service.