Security

Security

How this website and its contact form are secured, what a submission stores, and how to report a vulnerability.

Disclosure policy · RFC 9116

What this page covers

This page describes the security of theomega.ai and the contact-form endpoint behind it. That is its whole scope.

It does not describe the Omega AI compute platform. Questions about that are answered directly, under diligence, rather than summarised here.

Reporting a vulnerability

Email hello@theomega.ai with enough detail to reproduce the issue: the affected URL or endpoint, the steps you took, and what you observed. A proof of concept helps. Please do not open a public issue for a security report.

We will acknowledge receipt and tell you whether we consider the report in scope.

This address is also published in /.well-known/security.txt per RFC 9116.

Testing scope

In scope

  • theomega.ai and www.theomega.ai, the public marketing site
  • The contact-form endpoint this site posts to

Out of scope

  • Any third-party infrastructure, including any provider or customer system. We cannot authorise testing against systems we do not control, and neither can you.
  • Denial-of-service and volumetric testing against production.
  • Reports that consist only of a scanner’s output with no demonstrated impact.
  • The presence of the contact-form endpoint URL in the frontend JavaScript bundle. This is deliberate. The lead sink is pinned at compile time precisely so that redirecting it requires a reviewed code change rather than an environment variable, and no credential ships with it.

What the contact form stores

A submission stores the name, email, organisation and workload or capacity description you enter, plus intent, which records which side of the exchange the enquiry is on. Two diagnostics are stored with it, used to identify automated abuse of the form:

  • A salted SHA-256 hash of the client IP address. The raw address is never stored, and the hash cannot be reversed back into one.
  • A user-agent string, truncated to 512 characters.

The form contains a hidden field that automated submissions tend to fill in and people do not. Its contents are never stored, only a derived boolean. Application logs record exception types only, never submitted values or generated identifiers.

The full collection notice is on the privacy policy.

Response headers

The site is served with HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a Referrer-Policy, a Permissions-Policy denying camera, microphone and geolocation, and an enforcing Content Security Policy. They are configured in the repository and applied by the host on every deploy, so they also cover preview builds rather than production alone.

Two gaps, stated rather than left to be discovered. The CSP is enforced but has no violation collector, so a mis-scoped rule reaches a visitor as silent breakage rather than as a report that reaches us. And HSTS carries no includeSubDomains, because this header set is verified on the www responses and a zone-wide pin is the one header here that cannot be rolled back in minutes. Both are tracked.

Accepted risks

We keep a written register of risks we have accepted rather than fixed, each with the reasoning that justified accepting it and the condition that would reopen it. An accepted risk that is written down is acceptable; one that is not written down is not.

The register is maintained alongside the code rather than published here, and is shared on request under diligence.