GroLabs treats security as a baseline rather than a checkbox. This page describes how we protect the data flowing through the platform today and where we are headed. We update it when our posture materially changes.
1. Transport encryption
All traffic to and from GroLabs is served over HTTPS with TLS 1.2 or higher. We force a redirect from any plaintext URL. Our certificates are issued by industry-standard authorities and rotated automatically by our hosting providers.
2. Encryption at rest
Customer data is stored by our managed sub-processors (Supabase, Vercel, Browserless, etc.). Each encrypts data at rest using AES-256, managed by the underlying cloud platform (AWS / GCP). Our access to those datastores is logged.
3. Authentication
- We delegate password storage to Supabase Auth, which uses bcrypt with a per-user salt.
- Sessions are managed by signed JWTs with short lifetimes; the refresh flow is rotated server-side.
- SSO and multi-factor authentication are on the roadmap.
4. Authorization and tenant isolation
Tenant isolation is enforced at the database row level. Every operational table carries an instance_id, and Supabase’s Postgres Row-Level Security policies make a user’s membership in an instance the only path to that instance’s data. Application code never writes WHERE instance_id = X clauses — RLS does it, removing an entire class of authorization bugs.
The service-role key (which bypasses RLS) is held in environment variables and only used by trusted server-side flows (admin operations, anonymous public-API ingest, screenshot uploads). It is never sent to the browser.
5. Public read paths
Some report URLs are public: the share token for a diagnostic run is an unguessable UUID. Anyone with the URL can read the report, but without the URL no read is possible. Storage buckets used for diagnostic screenshots follow the same model — public-read access gated by an unguessable run prefix.
6. Network egress and the browser probe
The browser-based probe (Playwright via Browserless) only loads the URLs you explicitly configure for diagnostics, plus assets those pages reference. The probe runs in a managed Chromium pool operated by Browserless, isolated from our application infrastructure.
7. Sub-processor selection
We pick sub-processors with strong security postures: Supabase (SOC 2 Type II), Vercel (SOC 2 Type II), Google Cloud, AWS, Browserless, Railway. The full list and what each receives is in our Privacy Policy. Each is bound by a Data Processing Agreement.
8. Internal access
- Production access is limited to a small number of operators.
- Every admin action against the production database is reviewed against change-management practices.
- Personal devices used for production access run full-disk encryption and use up-to-date operating systems.
9. Logging, monitoring, and alerting
Application errors and performance metrics flow into our observability stack (Vercel logs, Supabase logs, the in-app /configuration/system-health probe). Alerts are sent to on-call when key health checks regress. Sentry integration is on the near-term roadmap.
10. Vulnerability management
- Dependencies are kept up to date with automated PRs and reviewed against advisories.
- We do not run external penetration tests on a fixed schedule yet; we welcome reports from independent researchers.
11. Incident response
If we confirm an incident that affects customer data, we will notify affected customers without undue delay (within 72 hours where data-protection law requires it) with what we know, what we are doing, and how it may affect their data.
12. Compliance roadmap
- Today: we rely on the SOC 2 attestations of our infrastructure providers and apply the technical controls described above.
- Near term: we plan to engage an independent firm to attest our own controls (SOC 2 Type I, then Type II) as the customer base grows.
- GDPR-style data subject requests are honored today via the contact email in the Privacy Policy.
13. Responsible disclosure
If you believe you have found a security vulnerability, please email [email protected] with reproduction steps. Please:
- Give us a reasonable window to investigate and remediate before public disclosure.
- Do not perform testing that affects other customers’ data.
- Do not retain, alter, or transfer data you encounter during testing.
We respond within two business days to acknowledge the report and will keep you updated on remediation. We do not have a paid bug bounty yet, but we are happy to publicly credit researchers (with your permission) for valid findings.
14. Contact
Security questions: [email protected].