FieldworkSign in

Security

Fieldwork is built on infrastructure with strong default security posture. This page describes the specific measures in place to protect your account and research data.

Questions or concerns? Contact joel@locallabs.dev.

Infrastructure

Hosting. The Fieldwork application runs on Vercel. Static assets and serverless functions are distributed across Vercel's global edge network.

Database and storage. All data is stored in Supabase, which runs on AWS (us-east-1). Supabase applies AWS-managed security controls including physical access restrictions, network isolation, and regular security patching.

Encryption

In transit. All data between your browser and Fieldwork is encrypted using TLS. Connections over plain HTTP are redirected to HTTPS.

At rest. All data stored in Supabase is encrypted at rest using AES-256, managed by AWS. This includes interview session data, participant records, and uploaded files.

Access controls

Workspace isolation. Each workspace's data is isolated using row-level security (RLS) policies enforced at the database layer. Application-level access controls enforce workspace membership.

Authentication. Fieldwork uses passwordless magic link authentication. You sign in by clicking a link sent to your email. There are no passwords to phish or credential databases to breach.

Enterprise SSO. Enterprise plan customers can configure Single Sign-On (SSO) via their identity provider, allowing centralised access management and automatic deprovisioning.

Internal access. Access to production infrastructure by Fieldwork team members is restricted and logged. We do not access customer data except when required to resolve a reported issue, with your knowledge.

Data isolation and multi-tenancy

The platform is multi-tenant. Workspace data isolation is enforced through row-level security policies at the database layer, not just at the application layer. Each query is scoped to the authenticated workspace. Background jobs (Inngest) are scoped per workspace to prevent cross-tenant data exposure.

Rate limiting and abuse prevention

All API endpoints are rate-limited using Upstash Redis. Rate limits are applied per user and per workspace. This protects against credential stuffing, abuse of AI endpoints, and denial-of-service attempts.

Sub-processor security

We rely on sub-processors who maintain their own security programmes:

  • Supabase runs on AWS and inherits AWS's SOC 2 Type II and ISO 27001 certifications
  • Vercel holds SOC 2 Type II certification
  • Anthropic operates under enterprise security controls and does not use customer data to train models by default
  • Stripe is PCI DSS Level 1 certified

See our Data Processing page for the full sub-processor list.

What we do not currently have

We believe in being direct about the current state of our security programme.

  • SOC 2 certification. Not yet. We are a focused early-stage product. Our infrastructure sub-processors (Supabase, Vercel) are SOC 2 certified. We will pursue our own certification as the business scales.
  • Penetration testing. We have not yet commissioned an independent penetration test. We plan to do so before targeting enterprise customers at scale.
  • 2FA / TOTP. We use magic link authentication, which removes password-based attack vectors. TOTP-based 2FA is not currently offered as a separate option.

If your organisation has specific security requirements not addressed here, contact joel@locallabs.dev before onboarding.

Responsible disclosure

If you discover a security vulnerability in Fieldwork, please report it to joel@locallabs.dev. Include a description of the issue and steps to reproduce it.

We will acknowledge your report within 3 business days and aim to resolve confirmed vulnerabilities within 30 days. We ask that you do not publicly disclose the issue until we have had the opportunity to address it.

Contact

For security questions, vulnerability reports, or enterprise security reviews:

Locallabs Pty Ltd joel@locallabs.dev Queensland, Australia

Last updated: 2026-04-13