Security Overview

This page explains how the Maverick Console protects the information customers put into it. It describes the controls built into the product today. These are product controls, not a certification: we have not been audited against SOC 2, ISO 27001 or any other standard, and we say so plainly in the last section.

The Console is operated by Speedloop Technologies, an offering of Speedloop Auto Private Limited (India), 2nd Floor, Plot No. 296, Sector 10, PCNTDA, Pimpri Chinchwad, Pune, Maharashtra 411039, India. Security questions: maverick@speedloopauto.com.

Where the Console runs today

• The Console is a working product that currently holds fictional demonstration data only. The demo companies (such as Lone Star Freight & Logistics and Mesa Ridge Earthworks) and every record in them are invented and labelled as such.
• Real customer data is refused by the database until the admission gate described below has been passed for that customer.
• Hosting: the database, sign-in and file storage run on Supabase in the United States (US East, Virginia). The web application runs on Vercel. AI features use Anthropic, only when AI is enabled for a workspace.
• There is no public sign-up. A Speedloop administrator creates every account.

Separating customers from each other

• One tenant per customer. Each customer's records live in its own tenant. Every database function checks that the workspace, Purpose, dataset and record all belong to the same tenant.
• Row-level security. Postgres row-level security is switched on for the Console's tables. The tables that hold customer records have no direct read policy at all: records can be reached only through a governed function that applies the caller's Purpose and the data markings described below.
• Least privilege by default. New database functions can be called by nobody until access is granted on purpose, and each grant carries a recorded review note.

Purpose-based access with expiring grants

• Every read of customer data happens under a Purpose: a defined task with an owner, the datasets assigned to it and the kinds of data it may see.
• People apply to a Purpose, never directly to a dataset. A request needs a written reason, and nobody can approve their own request.
• Grants expire: after 90 days by default, and never later than 365 days.
• Closing a Purpose revokes its grants and withdraws pending requests.
• Roles are kept short: Speedloop administrator, customer controller, member and auditor. An auditor can see who has access to what, and why, without seeing the data itself.

Field masking

Data is marked with one or more of four markings:

A Purpose sees a dataset only if its markings are allowed, and individual fields with a marking the Purpose does not allow are masked: they cannot be read or written. Names of people are always treated as PERSONAL.

Audit log and history

• The audit log is append-only for every role, including the platform's own service account. The database rejects attempts to change, delete or truncate it.
• Reads are recorded by dataset (who read which dataset, when, under which Purpose), not by copying the content that was read.
• Every create, edit, delete and restore of a record leaves a revision with the person and time, written by the database itself so no code path can skip it.
• Governance changes (grants, approvals, security settings, deletions) require a written reason.
• Each call to an external AI model is recorded with the provider, model, tenant and person, without the prompt or the data sent.
• Customer controllers and auditors can read their tenant's audit log in Nimbus, the Console's security and trust module.

Sign-in, two-factor and sessions

• Sign-in uses email and password through Supabase Auth. Our staff cannot see passwords.
• Two-factor sign-in is always required for Speedloop administrators and for customer controllers, and a customer can require it for everyone in its tenant. When required, it is enforced both by the application and by the database on every data read.
• Speedloop administrators must use an authenticator app.
• Customer users get a 6-digit code by email each time they sign in, or can use an authenticator app instead; a customer can require the authenticator app for its tenant.
• An emailed code expires after 10 minutes, works only for the sign-in that asked for it and allows 5 tries, and we store only a scrambled (hashed) copy. It protects an account whose password is stolen, but someone who can also read the user's email could use it, so an authenticator app is the stronger choice.
• Idle sign-out: sessions end after a period of inactivity (8 hours by default; the customer can shorten it).
• IP allow-lists: a customer can restrict its tenant to listed networks.
• Both rules are checked on every request, and a session that has ended is also refused by the database. If the check cannot run, access is refused rather than allowed.

Files and exports

• Files are stored in a private storage bucket, separated by tenant. Opening a file attached to a record requires a Purpose that can read that record.
• Files are shared only through short-lived links that expire after 60 minutes by default (the customer can set between 1 minute and 24 hours).
• Individual files are limited to 50 MB, and total storage is capped by plan.
• Exports follow the customer's export setting and are recorded in the audit log.

Real-data admission gate

Before any non-fictional record can be stored for a customer, a Speedloop administrator must approve an in-date processing register for that tenant. The register records the customer's controller contact, Speedloop's role, the purpose, data categories, geographies, legal basis, contract reference, transfer path and review date. Until then the database refuses real records. Editing the register withdraws the approval until it is approved again.

External AI controls

• Each tenant has an external-AI setting: off, demo data only, or approved with a reference and an expiry date. The data categories that may be sent to the AI provider can be restricted.
• The AI analyst reads only what the user's Purpose allows, and masked fields stay masked.
• If the setting does not allow a call, the call is refused. The check fails closed.
• Each AI call is logged without its prompt content, as described above.
• AI answers are an aid to people. A named person owns every decision.

Deletion and legal hold

• Deletion is staged: requested → soft-deleted (hidden at once and restorable for 7 days by default) → hard-deleted.
• A hard delete also purges the record's revision history, comments, files and copies held in pending change sets. Stored files are removed by an hourly purge job with retries and alerts for anything overdue.
• A hard-deleted record is never re-imported by a later data load.
• A legal hold on a dataset (placed by a customer controller or a Speedloop administrator) blocks hard deletion until a Speedloop administrator releases it.

Application and operational safeguards

• Security headers: the Console tells browsers not to guess file types (X-Content-Type-Options: nosniff), not to show it inside other sites' frames (X-Frame-Options: DENY), to limit referrer information (Referrer-Policy: same-origin) and not to index it in search engines.
• HTTPS: all traffic to the Console is served over HTTPS by our hosting provider. Our hosting providers state that they encrypt stored data at rest; see their security documentation for details.
• Secrets: privileged keys are kept on the server only and never sent to browsers. Scheduled jobs and the website-to-Console intake are authenticated with random tokens or signed messages.
• Automated tests in CI: every change to the Console runs type checks, linting, a production build and a database test suite. The suite builds a full copy of the database in memory with fictional tenants and tests tenant isolation, Purpose masking, person-name masking, function privileges, session policy, IP allow-lists, hard-delete purge and file purge.
• Plan limits: AI questions, toolkit runs, records, seats and storage are metered per tenant, so usage cannot grow without limit.
• Security & governance panel: customers can see a posture summary, the processing register, the list of subprocessors, data-subject requests, security incidents, and which roles can call each database function.

What we do not claim yet

We prefer to be clear about what is not in place:

• We have no SOC 2 report, ISO 27001 certificate or third-party penetration test, and we do not claim HIPAA or PCI compliance.
• We offer no uptime commitment (SLA) and no backup or restore guarantee. Our database provider takes backups, but we have not yet run a full restore test. That test is planned.
• An independent security and legal review is planned before real customer data is admitted.
• Some protections are not yet built: a Content-Security-Policy, our own rate limiting beyond our sign-in provider's limits, and malware scanning of uploaded files. Two-factor is not yet mandatory for every member and auditor: it is always required for administrators and controllers, and for everyone else when their organisation turns it on.
• Data residency is not restricted to one country: the Console is hosted in the United States and supported by our team in India (see our Privacy Policy).
• We do not claim that any system is immune to breaches.

Report a vulnerability

If you believe you have found a security weakness in the Maverick website or Console, email maverick@speedloopauto.com with the subject "Security report". Please include what you found, where, and the steps to reproduce it.

We ask that you:

• do not access, change or delete data that is not yours, and stop as soon as you see someone else's data;
• do not degrade the service (no denial-of-service or automated flooding);
• give us a reasonable time to fix the issue before sharing it publicly.

We aim to acknowledge reports within 3 working days and to keep you informed while we fix the issue. We will not pursue action against good-faith research that follows these guidelines. We do not currently run a paid bug bounty.