Security practices

This page describes implemented application controls and the checks still required before a production deployment. It is not a certification, audit report, uptime commitment, or contractual SLA.

Credentials and workspace isolation

Account sessions and API keys have separate permissions. The API validates authenticated sessions with Supabase and checks trusted email confirmation. API keys are randomly generated, stored as hashes, scoped to a workspace, and revocable. Key secrets are only returned when created.

Run reads and mutations are scoped to the authenticated workspace. A run ID from a different workspace cannot be used to retrieve that workspace's output. The initial credit grant and subsequent reservations are transactional.

Request and provider boundaries

The server limits request bodies and uses strict action inputs. CORS uses configured origins. Authentication headers and cookies are redacted from server logs. Provider URLs are validated, calls have bounded timeouts, and normalizers project approved output fields instead of returning raw provider payloads.

Request limits, bounded queues, per-account pacing, and monthly source admission ceilings prevent a customer request from bypassing the shared execution policy. These controls do not remove upstream restrictions or guarantee source availability.

Protect your integration

Use API keys from a server-side environment. Avoid embedding them in a browser bundle. Rotate them when staff or integrations change and revoke them after exposure. Use idempotency keys for retries and set a credit budget on each execution request.

Treat extracted records as sensitive business data. Restrict access, minimize storage, and define an appropriate retention policy in your application.

Production readiness

The repository includes infrastructure configuration for TLS ingress, restricted runtime-secret access, bounded Lambda concurrency, and a non-root frontend container. Those settings require deployment and verification to become operational protections.

Production launch also requires working email delivery and verification, signup-abuse controls, backup and restore validation, monitoring, an incident-response process, and approved privacy and service terms. We do not claim SOC 2, ISO certification, a DPA, or an SLA that has not been established.

Public documentation boundary

The docs site serves only explicitly approved public pages. Arbitrary paths, internal planning documents, and the operator runbook are not routed through the public documentation interface. The container copies only public documentation into its serving directory.