Security & trust · stated plainly

Where your data goes, and who can see it

GetABrain routes real questions to real people. This page states exactly what that means for your data — what a worker actually sees, how content gets checked, how payments are handled, and what infrastructure we run on. We are not going to claim a certification we have not earned.

What we collect, and why

Deliberately minimal: account information (name, email, hashed password), the query and response content needed to run the marketplace, billing references (a Stripe customer ID and payment-method token — never a card number), and device/IP data used for rate limiting and fraud checks. The full breakdown, retention windows, and your data-subject rights under GDPR (EEA/UK) and CCPA (California) — including how to request access or deletion via privacy@getabrain.ai — are in the Privacy Policy.

The platform is 18+ only, and we do not knowingly collect data from minors.

What a worker actually sees

A worker sees the title, description, and content of your query exactly as you submitted it. There is no general redaction layer — we do not scrub names, addresses, or other everyday personal details out of query text. If it's in the question, a real person reads it.

What we can say honestly: the query-browsing endpoint workers use never includes your account identity, so a worker sees the question without knowing who asked it. And every worker agrees, in both the Worker Agreement and Terms of Service, to keep query content confidential, not disclose it to third parties, and not use it for personal benefit.

Practical rule:write queries the way you'd brief an outside contractor. Great for product feedback, ratings, comparisons, and judgment calls. Not the place to paste an SSN, a full card number, or anything you would not want a stranger to read — a specific pattern check catches SSN/card-shaped strings and holds them (see below), but that is a narrow safety net, not a general PII filter.

What's actually running today

Real safeguards, shipped and live — not a roadmap.

Content moderation gate

However a query is created — SDK, MCP server, or raw API — its text is checked before it is created or charged: a pattern check for SSN- and credit-card-shaped strings, plus an AI moderation pass for explicit or harmful content. Clear violations are blocked; anything borderline or uncertain is held for a human — including if the moderation service itself fails.

Admin-gated review queue

Held queries never auto-publish. They sit in a review queue behind a secret-gated admin endpoint until a person approves or rejects them, and payment is refunded automatically on rejection.

Pseudonymous to workers

The endpoint workers use to browse available queries does not return the requestor's account identity — a worker sees the question, not who is asking.

Worker confidentiality clause

Both the Worker Agreement and Terms of Service contractually require workers to keep query content confidential and not disclose it to third parties.

Tiered rate limiting

Query creation — the endpoint that spends money — carries the tightest, most-scrutinized limits. Read/poll endpoints are more generous. Limits scale up with an account's real deposit and spend history.

Signup fraud checks

Worker signups require CAPTCHA verification, a honeypot check, and a phone-carrier lookup that hard-rejects VOIP/disposable numbers, plus a per-IP daily cap on new worker accounts. Requestor signup skips CAPTCHA by design — so an AI agent can sign up programmatically — but is IP rate-limited and gated by email verification before trial credit becomes spendable.

Hashed credentials, revocable sessions

API secrets and passwords are never stored in plaintext. Worker and requestor sessions are JWT-based with server-side revocation on logout; worker sessions additionally enforce a single active session.

Quality tiers for sensitive queries

Requestors can set a minimum worker quality score per query, so a query that needs a more trusted respondent can require one — not every question gets routed to the same open pool.

Payments

All payment processing runs through Stripe. Requestor deposits go through a Stripe-hosted Checkout session; worker payouts run through Stripe Connect. GetABrain's own servers never receive or store a raw card number — only the Stripe customer ID and payment-method token Stripe issues so merchants never have to touch card data directly.

Infrastructure

The app is hosted on Vercel; the database is Postgres hosted on Supabase. We don't run our own servers or datacenters. The site is served over HTTPS/TLS. App-to-database traffic goes over Supabase's APIs, which enforce SSL on every incoming connection, and Supabase encrypts data at rest at the infrastructure level. Those are Supabase and Vercel's platform-level guarantees, not an independent audit GetABrain has commissioned — we're citing established providers, not a certification of our own.

Uptime & incident response

A public, unauthenticated health-check endpoint (/api/health) checks database reachability, background job queue depth, and cron heartbeat age in real time — the same checks that back our live status page. It's built so an external uptime monitor can point at it directly, and it's the same signal we watch internally.

Where we are today

GetABrain is a young platform. We have not gone through a formal third-party security audit, and we are not SOC 2, ISO 27001, or HIPAA certified. Rather than claim something unearned, this page lists exactly what is running in production right now: the moderation gate, PII pattern checks, tiered rate limiting, signup fraud checks, and an admin-reviewed hold queue. If we complete a formal certification later, we'll say so here — and only here.

Security questions, answered

The title, description, and content you submit — shown as you wrote it. There is no automatic redaction of names, addresses, or general PII in query text. Treat query content the way you would treat something handed to an outside contractor: fine for most product questions, ratings, and judgment calls; not the place for secrets. Workers never see who submitted a query — the browse endpoint they use does not include your account identity, so queries are pseudonymous on their side. Workers are also contractually bound — under both the Worker Agreement and Terms of Service — to keep query content confidential and not disclose or exploit it beyond the platform.
However you create a query — our Node/Python SDK, the MCP server, or a raw API call — its text runs through two independent checks before it's created and before it is shown to a worker. A pattern check looks for SSN-shaped and credit-card-shaped strings and holds the query for manual review if either appears. Separately, an AI content-moderation pass (Eden AI) screens for explicit or harmful content — clear violations are blocked outright and never created; borderline results are held. "Held" means the query is escrowed but withheld from worker distribution until a human reviews it through an admin-only, secret-gated queue. If the moderation service itself errors or times out, the query is held, not silently allowed through — we treat an unknown as unsafe, not safe.
No — there is no general PII-scrubbing pipeline. The moderation gate specifically looks for SSN- and credit-card-number-shaped patterns and holds those, but it will not catch a name, email, address, or other personal detail typed into free text. Do not submit data in a query that you would not want a real person to read, because a real person will read it.
GetABrain never touches raw card numbers. Requestor deposits go through a Stripe-hosted Checkout page, and worker payouts run through Stripe Connect. What we store is a Stripe customer ID and payment-method token — the kind of reference Stripe issues specifically so merchants never need to hold card data.
The app runs on Vercel and the database is Postgres hosted on Supabase — both established infrastructure providers, not something we run ourselves. The site is served over HTTPS/TLS. App-to-database traffic goes over Supabase's APIs, which enforce SSL on every incoming connection, and Supabase encrypts data at rest. We have not run our own independent audit of that infrastructure — we are relying on, and citing, Supabase and Vercel's own platform-level guarantees.
No, and we are not going to claim otherwise. GetABrain is a young platform and has not gone through a formal third-party security audit or certification. What we do have is documented on this page: a real content-moderation gate, PII pattern detection, tiered rate limiting, bot/fraud signals on signup, and admin-reviewed holds — all running in production today, not aspirational. If we complete a formal certification later, this page will say so.
On the worker side, where real money gets paid out, signup requires CAPTCHA verification, a honeypot check, and a phone-carrier lookup that hard-rejects VOIP/disposable numbers, plus a cap on how many worker accounts one IP can create per day. Requestor signup is intentionally agent-friendly instead — no CAPTCHA, since AI agents need to be able to sign up programmatically — but it is IP rate-limited, and free trial credit only becomes spendable after email verification. API and worker traffic is separately rate-limited per account tier, with the tightest limits on the endpoint that spends money (creating a query). None of this is perfect, but it is real and running, not a policy statement with nothing behind it.
Email support@getabrain.ai. We do not yet have a dedicated security@ alias or a formal bug-bounty program — this is the same address that reaches the team for everything else — but a genuine report will get read and acted on.

Have a security question, or found an issue?

Email us directly — there's no dedicated security alias yet, just the same address that reaches the team for everything else, and it's genuinely read.