Security controls, with clear boundaries.

Secrets and workload identity

Browser configuration contains only client-safe settings. Supabase service-role credentials, receiver credentials, webhook encryption material, and the dedicated production signing key stay server-side. Model calls use a scoped AWS role through Vercel OIDC identity federation, rather than model credentials in browser JavaScript.

The documented SMTP runtime resolves secrets dynamically and uses instance roles. Its launcher rejects static workload AWS credentials. Operators remain responsible for secret rotation, key expiry, certificate renewal, and the permissions of each deployment.

Sessions, roles, and workspace access

Production browser sessions use HttpOnly, Secure, SameSite=Lax cookies with bounded expiry. JavaScript cannot read those server-set access and refresh cookies. The refresh cookie is configured for up to 30 days; access-cookie expiry follows the provider lifetime within the configured bound. The server verifies the user through Supabase Auth and resolves active organization membership before authorizing workspace operations.

• Membership and role—not profile labels or user-editable metadata—determine access.
• Case writes require analyst-or-higher authorization; administrative actions have narrower owner/admin checks.
• Saved evidence, exports, uploads, and assigned receiver status are scoped to the authorized workspace.

Storage has its own active-session and ownership checks. Logout behavior must be evaluated per route; the platform does not claim universally immediate invalidation of every previously issued JWT.

API keys and signed worker requests

Developer keys are generated with secure randomness, returned once, and stored as SHA-256 hashes with masked display, scopes, status, activation/expiry times, and usage limits. Authentication checks the owner, active membership, key lifetime, required scope, and quotas. Revocation disables linked integrations and prevents subsequent key authentication.

Private worker execution uses a bounded timestamped request, UUID nonce, and HMAC signature. A durable nonce ledger rejects replay. Ordinary browser sessions and developer keys do not substitute for this worker authentication boundary.

Database and private storage boundaries

The 12 October technical review found RLS enabled on every public regular table selected by the audit and all observed Storage buckets private. Some tables intentionally have no client policies and remain service-only. These findings describe that reviewed deployment, not a guarantee about every later configuration.

Server-side service-role operations bypass ordinary RLS. Their safety also depends on verified identity, organization predicates, scoped RPCs, and tenant relationships. Storage policies separately constrain session, ownership, and object access. Private bucket settings alone do not establish that every application operation is correctly authorized.

Request validation and external lookups

Routes enforce their supported method, content type, schema, size, scope, and quota boundaries. API responses use no-store handling and sanitized public errors. Production configuration defines content security policy, transport security, frame restrictions, browser capability restrictions, and protected source-tree routes.

The public-HTTPS fetcher used by relevant enrichment paths validates public destinations, DNS resolution, hostname/peer identity, timeouts, and response bounds. Private or reserved IPs are excluded from public geolocation and reputation queries. Fixed-origin and configured provider adapters have their own boundaries; this is not a claim that every outbound request uses an identical guard.

Trusted SMTP and private inference

In the documented pilot, a hardened Postfix edge requires STARTTLS and forwards controlled transport facts to a loopback Node receiver. The receiver rejects unauthorized recipients and relay use. Internet-supplied headers cannot create trusted proxy observations.

The private AWS CPU classifiers are reached through a scoped Lambda proxy and restricted TLS ingress. Required model failures, quota exhaustion, unsupported authentication states, or unavailable inference safely defer mail rather than produce a benign default. Analysis success and confirmed recipient delivery are separate events.

Open your connected receiver for the relevant receiver workflow. The bare Node companion needs a private environment or a hardened SMTP edge; it is not a public STARTTLS service by itself.

Signing and immutable evidence

Production Evidence Passports require a dedicated Ed25519 private key. Canonical evidence and manifest digests use SHA-256; exported packages include public verification material, not the private signing key. Full verification checks the signature, evidence hash, manifest hash, key fingerprint, and configured issuer trust.

Saved signed snapshots are retained for reopening and export. Historical records are not silently enriched or re-signed to manufacture validity. A valid signature proves package integrity under the verification policy; it does not establish sender identity, content truth, or email safety.

Operational responsibilities and disclosed risks

The technical review records unresolved advisor findings involving service-only RLS tables, authenticated SECURITY DEFINER functions, pg_net placement, and disabled leaked-password protection. Those require contextual operator review. This page update does not clear advisories or change database, IAM, or password settings.

• Monitor key/certificate expiry, receiver freshness, model readiness, failed work, quotas, and retention receipts.
• Verify each additional organization, domain, recipient, and delivery provider independently.
• Keep legal holds, incident handling, restore testing, and dependencies maintained.