Trust
Security you can read, not just a badge.
Every control on this page exists in the product or in our operating routine today. Where something is still in progress, it says so.
What we protect and how
Controls that exist today
The status on each card is the honest one. Live means it runs in production now; in progress means partly there; planned means not yet started.
Tenant isolation
LiveOne organization can never read another’s data. The rule lives in one place and every query goes through it.
- Every corpus query passes
filters.scope_to_org(); every customer object is scoped by organization id - Internal documents you submit are visible only to your organization: feed, search, Ask, impact and webhooks alike
- Supabase PostgREST is closed: Row Level Security on every table with no policies, grants revoked from the public roles
- Every corpus query passes
Identity and roles
LiveSupabase Auth for people, hashed keys for integrations, one permission matrix for both.
- Email magic link, Google, and SAML 2.0 single sign-on for customers who bring an identity provider
- Owner, admin, analyst, viewer: the matrix is one file in the codebase and is rendered on the Roles page
- API keys are random, stored as a SHA-256 hash, shown once, revocable, and act as
analyst
Enforced multi-factor authentication for console users is planned; SSO customers inherit their provider’s MFA.
Encryption
LiveTLS on every hop, encryption at rest handled by the platforms that hold the disks.
- HTTPS with managed certificates on the API, console and MCP server; HSTS on secure responses
- Services reach Supabase over TLS (
ssl=require); LLM, email and webhook calls are HTTPS - Database, backups and Auth data encrypted at rest by Supabase on AWS; secrets encrypted at rest by Render
Signed webhooks
LiveEvery delivery can be verified by the receiver and cannot be replayed.
X-RegSignal-Signature: t=<unix>,v1=<hex>, HMAC-SHA256 over the timestamp and raw body- Reject deliveries older than 300 seconds; verifiers ship in the Python and JavaScript SDKs
- Rotate a secret per endpoint at any time; every attempt is logged with status and response time
Audit log
LiveEvery change is recorded in the same transaction as the change itself.
- Actor, how they authenticated, action, target, summary, metadata, client IP and request id
- Readable by analysts (
GET /v1/audit, Settings > Audit log), exportable as CSV by admins - Membership, key, webhook, profile, triage and organization changes all appear
Monitoring and alerts
LiveErrors, failing sources and spend are watched by people who get paged, not by a dashboard nobody opens.
- Sentry on API, worker, MCP server and console with PII off, no request bodies, credential headers scrubbed
- Operator alerts when a source fails repeatedly or the daily LLM budget is exhausted; a daily pipeline summary
- A daily LLM spend ceiling pauses enrichment and returns 429 with Retry-After instead of running away
Change management
LiveNo change reaches staging or production without passing the pipeline.
- Pull requests plus CI: lint, format, unit tests, SDK builds, console type-check and tests, container builds
- Schema drift check against staging before deploy hooks fire; migrations run pre-deploy so a failure leaves the old version serving
- Production releases are pinned version tags, never latest; rollback per service
Branch protection with required reviews is being enabled as part of the SOC 2 programme.
Hardening
In progressSensible defaults on every response and every request.
- nosniff, strict referrer policy, frame denial, restrictive permissions policy, no-store on API responses
- Request bodies capped at 2 MB and rejected before any handler runs; forwarded IPs trusted only from known proxies
- Console Content Security Policy with frame-ancestors none, report-only today, enforcing next
Backups and recovery
In progressDaily backups exist; the restore path is being turned into a routine.
- Automated daily backups of the production database by Supabase, kept in the same region
- Point-in-time recovery being enabled on production
- Quarterly restore test into staging with recorded recovery times, first run scheduled
Data flow
Where your data goes
Compute in Render’s Oregon region, data in Supabase in AWS us-west-2, one LLM provider, and only the destinations you configure.
| From | To | What | How it is protected |
|---|---|---|---|
| Console users, SDKs, AI agents | API and MCP server on Render | Requests with a Supabase session or an API key | TLS; roles enforced per endpoint |
| API, worker, MCP, console | Supabase Postgres and Auth (AWS us-west-2) | All application data; identities | TLS to the session pooler; PostgREST closed |
| Worker | Official publishers (96 active sources, 21 jurisdictions) | Outbound fetches only | Honest bot user agent; Jina Reader as a fallback tier |
| API and worker | Anthropic API | Document text, questions, profile descriptions | TLS; no identities or keys in prompts; daily spend ceiling |
| Worker | Your webhook endpoints, Slack, Microsoft Teams | signal.created, signal.updated, impact.matched | HMAC-SHA256 signature, 300 s replay window, retries logged |
| Cron | Resend | Daily and weekly digests, sign-in email | TLS; DKIM and SPF on the sending domain |
| Every service | Sentry | Exceptions only | PII off, bodies never attached, credential headers scrubbed |
Compliance status
Where we are, in plain words
We publish status, not seals. When a report exists this section will say who audited us and how to request the report.
Current status
SOC 2 Type I: in progress, target Q1 2027
- ScopeSecurity (Common Criteria). Availability and Confidentiality are stretch goals after the first report.
- Type IIPlanned for the six months following the Type I.
- Other attestationsNone held today. No ISO 27001, no penetration test report yet; the first external test is budgeted in the programme.
- Report requestsOnce a report exists, customers and prospects under NDA will be able to request it from this page.
Scope and controls mapped (done)
Security criteria (CC1 to CC9) mapped to what the product does, with gaps and owners.
Policies drafted (done)
Information security, access control, change management, incident response, vendor management, continuity, retention, secure development, acceptable use.
Platform and auditor selected (not started)
Compliance automation platform connected to GitHub, Supabase, Render, Google Workspace and Sentry; audit firm engaged.
Gaps closed, evidence collected (not started)
Branch protection, access review, restore test, dependency scanning, MFA decisions.
Type I report (not started)
Point-in-time report on the design of controls.
Type II report (not started)
Six-month observation window after the Type I.
Subprocessors
Who else touches the data
Ten vendors, each with the data category it actually sees. Destinations you configure yourself, such as your webhook receivers, Slack, Teams or your SAML identity provider, are under your control and are not listed here.
| Vendor | Purpose | Data it processes | Region |
|---|---|---|---|
| Supabase | Database (Postgres, pgvector) and Auth | All application data; member identities | AWS us-west-2 (prod), us-west-1 (staging) |
| Render | Compute, environment configuration, logs | Data in transit; request logs without bodies; secrets as environment variables | Oregon, US |
| Anthropic | LLM classification, summaries, impact assessment, Ask | Regulatory document text including customer-submitted documents, questions, product profile descriptions; no identities or keys | US |
| Sentry | Error tracking | Stack traces and scrubbed request metadata; no bodies, no credentials | US |
| Resend | Email digests and authentication email | Recipient addresses, digest content, sign-in and invitation links | US |
| Jina | Rendering public publisher pages that block direct fetches | Public URLs only; no customer data | Global |
| Exa | Discovery of official publishers | Search queries about publishers; no customer data | US |
| GitHub | Source code, CI, container registry | Source code and CI logs; no production customer data | US |
| Google Workspace | Staff identity and email | Staff accounts; support correspondence | US |
| Stripe | Subscription billing, when enabled | Billing contact email, organization name, plan, usage totals; card details stay on Stripe Checkout | US |
Optional providers that are off by default (OpenAI, Voyage, Browserless) become subprocessors only if a deployment enables them. Data residency today is US West only; an EU deployment is on the roadmap.
Responsible disclosure
Found something? Tell us first.
Email security@regsignal.dev with the affected endpoint or URL, steps to reproduce and any proof of concept. The same address is published in /.well-known/security.txt.
- Acknowledgement within three business days, triage within ten, updates until it is fixed
- Credit if you want it; no legal action against good-faith research that follows the rules below
- Test only against organizations you own; never read, change or delete other customers’ data
- No denial-of-service or volumetric tests against the API, the publishers we crawl, or the LLM endpoints
- No social engineering of staff; stop and report once an issue is demonstrated
A paid bounty programme does not exist yet.
Security overview, the short version
- Tenancy
- Organization-scoped data through a single scoping function; internal documents private to the submitting organization; PostgREST closed with RLS on and grants revoked.
- Identity
- Supabase Auth with magic link, Google and SAML SSO; four roles enforced per endpoint; API keys hashed, shown once, acting as analyst.
- Encryption
- TLS in transit on every hop with HSTS; at rest by Supabase (AWS) and Render.
- Keys and secrets
- Secrets only in Render environment groups and the operators’ password manager; never in code; scrubbed from error reports.
- Webhooks
- HMAC-SHA256 signatures with a 300-second replay window; per-endpoint secret rotation; delivery log.
- Logging
- Audit events written with every change; structured logs without bodies or tokens; Sentry with PII off.
- Change control
- Pull requests, CI gates, schema drift check, pinned release tags, per-service rollback.
- Residency
- US West (AWS us-west-2 and Render Oregon). Backups stay in region. LLM processing in the US.
Questions
Security FAQ
Do you have a SOC 2 report?
Not yet. A SOC 2 Type I for the Security criteria is in progress with a target of Q1 2027, and a Type II is planned for the six months after it. Until a report exists we describe our status, not a certification.
Where is my data stored?
In Supabase Postgres in AWS us-west-2 (Oregon), with compute in Render’s Oregon region. Backups stay in the same region. LLM processing happens in the US through Anthropic’s API.
Is my data used to train models?
We use Anthropic’s commercial API under its API terms; document text, questions and profile descriptions are sent for processing and we do not use customer data to train models of our own. The retention terms for API inputs are being confirmed in writing as part of the vendor review and will be published here.
Can other customers see the documents I upload?
No. Internal documents carry your organization id and are excluded from every other organization’s feed, search, Ask, impact matching and webhooks. The public regulatory corpus is shared by design.
Do you support single sign-on?
Yes. SAML 2.0 identity providers (Okta, Entra ID, Google Workspace, OneLogin) can be bound to your email domain through Supabase Auth, and Google sign-in is available without any setup.
How do I verify a webhook?
Recompute HMAC-SHA256 over the timestamp and the raw body with your endpoint secret, compare in constant time to the v1 value in X-RegSignal-Signature, and reject anything older than 300 seconds. The Python and JavaScript SDKs include a verifier.
What happens when I delete my organization?
Every organization-scoped table cascades: profiles, internal documents, matches, tasks, conversations, webhooks, keys, members and audit events. Rows leave backups when the backup window rolls over. Owners can also set per-organization retention windows, and each nightly purge records a deletion receipt.
Can I get an audit trail of what my team did?
Yes. Every change writes an audit event with actor, action, target and metadata. Analysts can browse it in Settings and admins can export CSV through the API.
Do you offer a DPA or a penetration test report?
A draft data processing addendum is published at /legal/dpa and is pending legal review. No external penetration test has been performed yet; the first one is budgeted in the programme and its summary will be shared under NDA when complete.