Security

Founders trust Foundryard with something sensitive: a live line into their revenue. Here's exactly how that trust is handled.

Stripe access is read-only, by construction

• We only accept restricted keys (rk_…) — the kind that can't move money or modify anything. Secret keys (sk_…) are rejected at the door, with instructions for creating the right kind.
• The minimum scopes are read access to Subscriptions and Invoices. Nothing else is requested or used.
• You can revoke the key from your Stripe dashboard at any moment, independent of us.

How keys are stored

• Keys are encrypted with AES-256-GCM before they touch the database, using a server-side key that never leaves the backend.
• Database rows holding keys are protected by row-level security that permits access to exactly one identity: yours. No other user, in any state, can select that row.
• Disconnecting Stripe deletes the stored key and all cached aggregates immediately.

What we compute and keep

Metrics are fetched on demand and at most hourly. We store only aggregates — current MRR, subscriber count, and a 12-month monthly series. Raw Stripe objects are processed in memory and discarded.

Access control everywhere

• Every table is behind Postgres row-level security — visibility rules (Public / Connections / Private) are enforced by the database itself, not just the UI.
• Authentication is OAuth-only via Google and GitHub. We never store passwords.
• All traffic is encrypted in transit (TLS).

Reporting a vulnerability

Found something? Please tell us before telling anyone else: security@foundryard.dev. We commit to acknowledging reports within 48 hours, and we won't pursue good-faith research conducted without harming users or data.