Security.

Last reviewed: May 15, 2026

Hapex is a solo-founder operation. We are not SOC 2 certified. We do not claim GDPR certification. What we do claim is that we have built the system carefully, with encryption on every credential, strict tenant isolation, and a minimal footprint. This page describes exactly what that means.

1. Encryption at rest

Every OAuth refresh token and API credential you authorize Hapex to hold is encrypted with AES-256-GCM before it is written to the database. The encryption key is stored in the environment as CREDENTIAL_ENCRYPTION_KEY, separate from the database credentials. Each credential row gets its own randomly generated initialization vector (IV), so two rows with the same plaintext value produce different ciphertext. This means a database dump alone is not sufficient to recover any credential.

Plaintext secrets touch memory only inside the agent-service process at the moment a capability step runs. They are never written to application logs.

2. Encryption in transit

HTTPS is enforced across every Hapex domain:

• hapex.ai (marketing site) - Netlify, TLS managed by Netlify CDN.
• build.hapex.ai (intake app) - Vercel, TLS managed by Vercel Edge Network.
• Agent service - Railway, TLS terminated at Railway's load balancer.

Internal service-to-service calls (intake app to agent service) use the AGENT_SERVICE_TOKEN bearer header over HTTPS. There are no HTTP-only internal channels.

3. OAuth scope minimization

Hapex requests the minimum OAuth scopes required for the automation you are building. We never request write access when the automation only reads, and we never request broad access when a narrow scope is available.

The full list of scopes Hapex may request per provider is documented at hapex.ai/#data-and-privacy. You authorize each scope explicitly through the provider’s official OAuth consent screen during agent build. No scopes are requested or stored without your action.

4. Tenant isolation

Every data object in Hapex (automations, connections, credentials, run records, cost events, chat messages) is scoped by client_id. This UUID is assigned at account creation and is the root foreign key for every table that holds customer data.

No query in the agent service or intake app fetches data across client_id boundaries. Administrative endpoints that operate across all clients require a separate AGENT_SERVICE_TOKEN that is never exposed to customers. Row-level security policies in the database back this up at the storage layer.

5. Storage location

6. What we do not do

• We do not sell your data. Ever, to anyone.
• We do not train general AI models on the content your automations process. Sub-processors (Anthropic, Google) operate under API terms that prohibit training their foundation models on API inputs; we have not opted in to any such training.
• We do not share your credentials, automation content, or personal information with third parties beyond the OAuth-connected provider you explicitly authorized.
• We do not log the plaintext contents of emails, documents, or automation outputs.
• We do not use tracking pixels, session replay tools, or behavioral advertising on any Hapex property.

7. Vulnerability disclosure

If you discover a security vulnerability in any Hapex property, email security@hapex.ai with a description of the issue and reproduction steps if you have them. We respond within 48 hours. We do not run a bug bounty program, but we will credit researchers who report valid issues and follow coordinated disclosure.

Please do not publicly disclose a vulnerability before we have had a chance to address it.

Privacy Policy · Refund Policy · Terms of Service · security@hapex.ai