Security at Alpha Scaling

Identity & authentication

Access to the Alpha Scaling client platform requires an authenticated account. Nothing in the platform is served to anonymous visitors.

• Accounts and sessions are managed by Supabase Auth, with password and magic-link sign-in.
• Server-side functions verify the caller's session token (JWT) before performing any work; unauthenticated requests are rejected.
• Every privileged operation is gated on a verified identity, not on values supplied by the browser.

Authorization & access control

Least privilege is a core design principle. Every request is authorized on the server against the identity of the caller, and each tenant can reach only its own data. This principle is enforced in the database itself, not only in application code:

• Row-Level Security is enabled and forced on every table, with a default-deny posture — a request sees nothing unless a policy explicitly grants it.
• Tenants (organizations) are isolated at the database layer: access policies are scoped to the caller's own user and organization (auth.uid()).
• Client and staff/auditor roles are separated; staff-only operations run through dedicated, role-checked procedures.
• Staff-only mutations — such as writing, publishing, or removing audit findings — run inside SECURITY DEFINER database functions whose first action is to verify the caller's staff role (is_staff()) and reject anyone who is not staff; each such function records the change to an append-only events log together with the acting user.
• The organization a write belongs to is derived on the server from the engagement it relates to, never from a value supplied by the caller.
• The audit findings table grants no insert, update, or delete to signed-in (authenticated) sessions at all — the role-checked functions above are the only path by which a finding can change.

Data protection

• All traffic to the site, the platform, and our APIs is encrypted in transit using TLS (HTTPS).
• Data at rest is protected on the managed platforms of our infrastructure providers.
• Uploaded business documents are held in private storage buckets that are not publicly accessible; files are served only through short-lived signed URLs.
• Client data is separated by tenant, and document contents are never exposed to another organization.
• Documents can be soft-deleted, and an organization's data can be purged, through dedicated server-side operations.
• We do not process or store payment-card data on the platform.

Data retention and the full data lifecycle are described on our Data Governance page. We do not publish specific encryption cipher details.

Application security

Authorization is always performed on the server. The browser is treated as untrusted input.

• Privileged operations run inside authenticated, server-side functions — never in the browser.
• Inputs are validated and size-capped before they are processed.
• Uploaded files pass a deterministic, server-side validation step (upload-sanity) that runs no AI model, enforces a parse-size limit, and records its verdict before a file is accepted.
• The marketing funnel's lead webhook verifies an HMAC-SHA256 signature using a timing-safe comparison, rejecting unsigned or forged requests.
• Contact fields sent from the marketing funnel to our advertising-measurement provider are hashed (SHA-256) before transmission.

Infrastructure security

The platform runs on two managed providers: Vercel for web and serverless hosting, and Supabase for the database, authentication, file storage, and server-side functions. We rely on their infrastructure security and keep application privileges separated across these boundaries, so that a component holds only the access it needs.

The full list of providers that process data on our behalf is on our Subprocessors page.

HTTP security headers

Responses are returned with a baseline set of browser-hardening headers, so a browser enforces safe defaults on every page:

• HTTP Strict Transport Security (HSTS), so browsers connect only over HTTPS.
• X-Content-Type-Options: nosniff, to stop content-type sniffing.
• A Referrer-Policy that limits what referrer information is sent to other origins.
• X-Frame-Options to restrict framing of our pages.
• A restrictive Permissions-Policy that disables device features the product does not use.

A Content-Security-Policy is being introduced in report-only mode first, so it can be validated against real traffic before it is enforced.

Secrets management

• Secrets and API keys are read from server-side environment variables only.
• Secrets are never embedded in client code, committed to the repository, or written to logs.
• Privileged credentials, such as the database service-role key and third-party API keys, are used only inside server-side functions.

Logging & observability

• The platform maintains an append-only event log of significant actions.
• Server-side functions emit structured logs for monitoring and diagnostics.

Auditability

Because the product itself is an audit, traceability is built in.

• Significant actions are written to an append-only event log; the events a client can see are explicitly whitelisted.
• Each AI assistant exchange records a single audit row capturing only metadata, such as input size and success — not the conversation content.
• Findings move through a review-and-publish workflow, and become visible to a client only once they have been published.

How analysis is reviewed before it reaches you is described on our Audit Integrity page.

AI security

Our AI features are designed for controlled, human-in-the-loop analysis. The in-product assistant is a status and process helper; it is deliberately kept away from producing client-facing numbers.

• Model access happens only on the server; the browser never holds model credentials.
• The assistant is gated by the caller's verified session (JWT).
• The assistant's context is built on the server from the caller's own profile and engagement — never from identifiers supplied in the request — keeping it scoped to the caller's tenant.
• Data sent to the model is minimized to metadata such as file names and statuses; document contents and financial figures are not sent to the assistant.
• Requests are bounded by per-request size caps: a cap on recent messages (20), a per-message input limit (2,000 characters), a bounded model response (600 tokens), and a 30-second timeout.
• AI usage is additionally rate-limited per user and per organization — a rolling-window limit with a daily ceiling — enforced server-side in the assistant edge function.
• Client-facing numbers come only from findings the audit team has reviewed and published; the assistant is instructed not to produce findings, dollar figures, or benchmarks.

For how we govern AI end to end, see our AI Governance page.

Vulnerability management

We continuously review the application for security issues as the platform evolves.

Incident response

We maintain a defined internal process for identifying, investigating, and responding to security incidents. If an incident affects your data, we will work to contain it and to notify affected parties where appropriate.

Security framework

The controls described above are the substance of our security program; framework language is secondary to them. Alpha Scaling uses security controls informed by relevant SOC 2 Trust Services Criteria. Alpha Scaling does not currently claim a SOC 2 attestation.

We build security in from the start (privacy-by-design) and are honest about our current status: no third-party penetration test or independent audit has been performed to date; we conduct internal security reviews as the platform evolves. We do not hold, and do not claim, any third-party security certification.

Where we describe our program as “SOC 2-aligned,” we mean it is designed with the relevant Trust Services Criteria in mind — not that it has been independently certified. We do not currently hold SOC 2, ISO, HIPAA, or PCI certification. For a control-by-control view, see our Security Overview and Controls matrix.

Report a vulnerability