Security

Data isolation between customers

Every table that holds customer data (accounts, projects, API keys, interaction logs, subscriptions, and more) has Postgres row-level security turned on, with a policy that filters every query down to the accounts the requesting user actually belongs to. This is enforced by the database itself, on every query, not by an if statement somewhere in our application code: a bug in a dashboard page or a forgotten WHERE clause cannot leak another customer's data, because Postgres won't return rows the policy excludes regardless of what the application asked for.

Concretely, as of this page's last update: every one of the 12 tables in our production database has row-level security enabled, and the tables holding account-scoped data (projects, API keys, interaction logs, subscriptions, usage counters, legal acceptances, disclosure settings) each carry a policy of the same shape — access is restricted to accounts the authenticated user belongs to, resolved through a single, shared, security-definer database function rather than a hand-rolled subquery repeated (and potentially miscopied) in each policy.

Your audit trail can't be edited, including by us

interaction_logs — the table Article 50 audit records live in — has exactly one row-level security policy: a SELECT policy. No UPDATE or DELETE policy exists for it at all. Postgres denies any operation with no matching policy by default, so this isn't a permission we chose not to grant the dashboard — it's an operation the database has no path to allow, for any authenticated user, including our own team logged into our own dashboard. The only way a row reaches that table is a single INSERT from the backend's own service role when your SDK or API call logs an interaction.

A log a customer, an admin, or an attacker could quietly edit after the fact isn't worth much as evidence for a regulator. This is why: an audit trail is only as credible as its immutability, not its existence.

API keys are hashed, never stored in plaintext

Your API key is shown once, at creation, and never again — the dashboard has no "reveal key" feature because there is nothing to reveal. What we store is a one-way SHA-256 hash and a short prefix for you to identify the key by in the dashboard; the table has no column that could hold a usable key even by mistake. A full database dump, in the worst case, hands an attacker hashes they cannot turn back into working credentials — not live keys to your account.

Data location

Our production database runs in AWS eu-west-1 (Ireland). That matters for two reasons that are directly relevant to why you'd use Disclarion in the first place: GDPR's data transfer rules are simplest to satisfy when personal data stays in the EU, and the AI Act's own compliance record-keeping expectations are easier to defend to a regulator when the records themselves are stored in the same jurisdiction the obligation comes from. Two exceptions: Stripe, our payment processor, may process payment data outside the EU under standard safeguards, and the dashboard's session handling runs on Vercel's edge network, which isn't pinned to a single region. See the sub-processors page for the full list.

Encryption in transit and at rest

Every connection to Disclarion — the landing page, the dashboard, and the API — is HTTPS-only; our hosting providers (Vercel and Railway) issue and enforce TLS certificates for all of our domains automatically. Data at rest is encrypted by Supabase's underlying infrastructure by default, for every project, with no opt-in step on our side.

Internal access to your data

Stated plainly rather than dressed up: we're a very small team today, so this isn't backed by a formal access-review process yet — that's a real gap we're noting, not glossing over, and it's a commitment we intend to formalize as the team grows. What already exists at the database level: cross-account admin functions (the ones our own team would use to look up an account) are gated behind an explicit allowlist table checked on every call, not open to anyone who happens to be authenticated — the same row-level security engine described above applies to us too, not only to the boundary between customers.

Sub-processors

Every third party in our infrastructure — what each one does, what data it touches, and where it runs — is listed on a dedicated sub-processors page, referenced from our Data Processing Agreement. We update that page, not this one, when the list changes.

Certifications

We don't hold SOC 2, ISO 27001, or any other formal security certification yet. We'd rather say that plainly than let a badge imply something we haven't actually been audited for — everything on this page is something you can verify yourself against the DPA and sub-processors list above, not a claim asking you to take our word for it.

Reporting a vulnerability

If you find a security issue, please email hello@disclarion.com with details and, if possible, steps to reproduce it. We don't have a dedicated security@ address or a bug bounty program set up yet — that inbox is read by the same small team, and we'll acknowledge and act on a genuine report promptly. Please give us a reasonable window to fix an issue before disclosing it publicly.