Trust

Security

FounderReply holds OAuth credentials for accounts you own and acts on them on your behalf, so the honest version of this page is a list of mechanisms rather than a list of adjectives. Below: what the system actually does, the exact permissions we request from each platform, and what we have not done.

OAuth access and refresh tokens are encrypted with AES-256-GCM before they are written.
Workspace membership is checked before anything is read — a valid session belonging to another tenant gets a 403, not data.
Application data is hosted in the EU (Supabase EU region).
No SOC 2, ISO 27001 or comparable audit — and no badge for one. Said in the open, below.

Last updated 8 June 2026

Posture

What is in place, and how it works

Each row names the mechanism rather than the intention, so you can check it against the behaviour of the product and against the answers you get from us in a security review.

Sign-in and sessions: Identity and credentials live in Supabase Auth. Edge middleware revalidates the session cookie on every authenticated page and every /api/v1/* request, rotating the access token when needed; a missing or expired session gets a 401 on the API and a redirect to /login in the browser.
Tenant isolation: Route handlers resolve the caller, then check workspace membership against the workspace_members join before reading anything. A valid session belonging to another tenant gets a 403, not data. This app-layer membership check is the primary isolation control.
Row-level security: RLS is enabled on the tenant tables with membership-scoped policies, and an authenticated request runs its data access through a user-scoped Postgres client those policies apply to. Background work — cron, webhooks, the agent worker — uses the service-role key, which bypasses RLS by design. So RLS is a second line here, not the only one.
Platform credentials at rest: OAuth access and refresh tokens are encrypted with AES-256-GCM via Web Crypto — a fresh 96-bit IV per token, and a 256-bit key held as a Worker secret, never in the repo or in config. Ciphertext is stored beside a scheme-version column so the format and the key can be rolled forward.
Credentials in responses: The account serialiser deletes both the plaintext and the encrypted token fields before anything is returned, so no API response can carry a token even by accident. Decryption happens in memory, for the duration of one platform call.
Transport and edge: The application runs on Cloudflare Workers and is served over TLS, with Cloudflare’s network perimeter and DDoS protection in front of it. The www host is 301-redirected to the apex at the edge before any handler runs.
Rate limits on the auth surface: Per-IP fixed windows on the endpoints worth brute-forcing: 10 sign-ins and 10 OAuth starts per minute, 5 sign-ups and 5 password changes per minute.
Untrusted inbound content: A comment or DM written by a stranger is prompt-injection surface. Each one is fenced inside a per-request random sentinel the author cannot predict or close, and any URL a draft contains that was not present in the source it replies to is stripped before you ever see it.
What the agent may do unattended: Every post, reply, DM and comment passes an autonomy controller that resolves your per-action setting before anything dispatches. Actions ship at the level each platform’s own automation policy allows — human approval for posts, replies and DMs, and read-only for comments on other people’s content — and you can move any of them, including past what a platform permits, after an explicit warning that names the rule.
Audit trail: Sign-ins and failed sign-ins, password changes, account connections, publishes and deletions each write a timestamped row to an audit table with the actor and the action.
Where data is processed: Application data is hosted in the EU (Supabase EU region). AI drafting uses Google’s Gemini API by default, which processes in the US under Google’s API terms; the EU/CH-hosted phi-cloud path is used instead when it is configured. The full sub-processor list is on the GDPR page.

Permissions

The permissions we actually request

Least privilege is easy to claim and easy to check. These are the exact OAuth scope strings we send to each platform's consent screen — no company-page scopes, no ad-account scopes, no read access to anything we do not act on.

The OAuth scopes FounderReply requests from each platform, and the state of each connection
Platform	Scopes requested	Connection
Reddit	identity submit read privatemessages history edit	Live
X	tweet.read tweet.write users.read dm.read dm.write like.write offline.access	Live
LinkedIn	openid profile w_member_social	Pending platform review
Facebook	pages_show_list pages_manage_posts pages_read_engagement pages_manage_engagement pages_messaging business_management	Pending platform review
Instagram	instagram_basic instagram_content_publish instagram_manage_comments instagram_manage_messages pages_show_list pages_read_engagement business_management	Pending platform review
YouTube	youtube.force-ssl	Pending platform review
Stack Exchange	write_access no_expiry read_inbox private_info	Pending platform review

Bluesky, Lemmy and Discourse have no OAuth redirect: they connect with an app password, an instance login and a per-forum API key respectively. Those credentials are stored in the same AES-256-GCM columns as the OAuth tokens above, and a Discourse API key is long-lived with no refresh flow — revoke it in your forum’s admin panel if you ever need to cut access outside of FounderReply.

The short version

What the system always does, and what it never does

Credentials, content and paperwork

The same facts as the tables above, in the shape a questionnaire asks for them.

Always

Encrypt OAuth access and refresh tokens with AES-256-GCM before they are written

Check workspace membership before reading anything — another tenant gets a 403

Fence a stranger’s comment or DM inside a per-request sentinel they cannot predict

Write a timestamped audit row for sign-ins, password changes, connections, publishes and deletions

Delete the stored credential when you disconnect, even if the platform’s revoke call fails

Never

Train any model on your content

Sell or share your content with anyone for that purpose

Return a token in an API response — the serialiser strips both fields

Show a badge for an audit that did not happen

Publish a post, reply or DM the autonomy controller has not cleared

On this page

Reporting a vulnerability

Email admin@founderreply.com with the affected URL or endpoint, the steps to reproduce, and what you were able to reach. We appreciate responsible disclosure, we respond promptly, and we will tell you what we found and when it will be fixed rather than closing the thread silently.

There is no bug-bounty programme, so we cannot offer a reward — what we can offer is a straight answer and credit if you want it. In return we ask that research stays inside your own workspace: do not access another customer’s data, do not degrade the service for anyone else, and give us a reasonable window to fix the issue before publishing it.

Certifications we do not hold

FounderReply has not completed a SOC 2, ISO 27001 or comparable audit, and you will not find a badge for one on this site. We are a small team, those audits have not happened, and a compliance graphic for an audit that did not happen is not a design decision.

If your procurement process needs paperwork, what genuinely exists is this page, our Data Processing Agreement, the sub-processor list and lawful-basis detail on the GDPR page, and a person who will answer a security questionnaire by email. If a certification is a hard requirement for you, we would rather tell you that now than after a contract.

Disconnection, deletion and retention

Disconnecting a platform account attempts a token revocation at the platform first — Reddit, X, LinkedIn, Facebook and Instagram all publish a revoke endpoint and we call it — and then deletes the stored credential rows regardless of whether that call succeeded, so a platform outage can never leave a token behind on our side. Deleting your account cascades through the workspaces you own: connected accounts, drafts, the approval queue, mentions, messages and billing records go with it, and the identity record itself is removed from the auth database.

Retention periods for the data that outlives a session — server logs, billing records — are set out on the privacy page, and you can start a deletion or an export from Data & Deletion without emailing anyone.

Your content and model training

We do not train any model on your content, and we do not sell or share it with anyone for that purpose. Drafting is a request to a third-party model API and nothing is retained by us for training; the terms that govern what those providers may do with an API request are theirs, and we name every one of them, with the region it processes in, on the GDPR page so you can read them yourself rather than take our summary for it.

Contact

Security questions, questionnaires and disclosure reports all go to admin@founderreply.com.

What a security review reads next

GDPRThe full sub-processor register, with the region each one processes in.Read Data & deletionEvery table we hold, why it exists, and when it is erased.Read DPA summaryThe Article 28 processor terms, and how to get a signed copy.Read

Control

You hold the accounts. You set what the agent may do unattended.

See what we store Read the GDPR page

Security questions and disclosure reports · admin@founderreply.com