Security overview

GoPie protects your data across three services (the web app, the API, and the AI agent) and the datastores behind them. Some protections are built into the platform; others depend on how you deploy and operate it. This page describes both, honestly — treat it as an account of the platform's mechanisms, not a compliance attestation.

How people and programs authenticate#

GoPie exposes three network surfaces, each with its own access model:

Sign-in is email-and-password with required email verification, and accounts can turn on two-factor authentication — a code from any authenticator app, backed by ten one-time recovery codes. Passwords are stored only as salted hashes (scrypt), never in plaintext.

Warning

The internal service API performs no authentication — it trusts request headers and exists solely for service-to-service calls inside the cluster. It must never be exposed to the public internet; its security depends entirely on network isolation.

How access is controlled#

Authorisation runs on two independent axes:

• A system role (admin or user) gates the system-wide admin console.
• An organisation role (owner, admin, or member) gates who can create and manage resources in an organisation.

On top of roles, individual projects and datasets can be shared with specific members, and the person who created a resource always keeps access to it. API keys act with organisation-owner authority within their organisation; an application-scoped key is additionally narrowed to only the projects and datasets you grant it.

Note

MCP refuses application-scoped keys by design. Because an MCP request carries its target datasets and SQL inside the request body — where per-request grant checks can't reach — the MCP endpoint accepts only organisation-wide keys and rejects application-scoped ones outright, failing closed.

How organisations are isolated#

Every read of a project or dataset is scoped to the organisation making the request — the organisation filter is part of the query itself, not applied afterwards, so one organisation cannot address another's data.

GoPie can also go further with schema-per-organisation isolation: each organisation gets its own database schema, its own scoped database role with a distinct credential, and its own storage prefix — so the isolation is enforced at the storage layer, not just in application code.

How secrets are protected at rest#

• Source credentials — the connection strings and cloud-storage keys for your database and cloud sources — are encrypted with AES-256-GCM before they're stored, and are never returned by the API. You can update a credential, but you can't read it back.
• Passwords are salted-hashed (scrypt).
• API keys are stored as hashes, never in plaintext — the full key is shown to you exactly once, at creation.

Note

Credential encryption uses a key from your deployment's configuration — application-level envelope encryption, not an external key-management service. Everything else GoPie stores (dataset contents, chats, files, embeddings) relies on the at-rest encryption of the datastore you run it on. Enable disk/bucket encryption on your PostgreSQL, object storage, and Qdrant to cover that data.

How data is protected in transit#

• TLS is terminated at your ingress or load balancer — run GoPie behind HTTPS in production.
• Download links are time-limited, signed URLs: exports expire after 24 hours and document links after one hour, so a shared link doesn't grant indefinite access.
• Keep the internal API and the database on a private network — GoPie assumes a trusted network between its own services.

Rate limiting#

Request rate limiting is optional and off by default. When enabled, requests are limited per user and per API key; exceeding the limit returns 429 Too Many Requests with a Retry-After header telling the client when to retry. Turn it on for any internet-facing deployment — see the API overview.

Administrative audit log#

GoPie keeps an append-only audit log of access-control events — membership changes, API-key creation and revocation, organisation lifecycle, and user bans or impersonation. It is an administrative trail for who-changed-access, not a record of every data query.

What GoPie leaves to you#

Being clear about the boundary matters as much as the features:

Important

GoPie ships with no compliance certifications (such as SOC 2 or ISO 27001) and no external key-management service, and it does not terminate TLS itself. Encryption in transit, the at-rest encryption of the underlying datastores, network isolation of the internal service API, and rate limiting on internet-facing endpoints are all operational responsibilities of whoever deploys GoPie. The platform gives you the mechanisms; a secure deployment is the two working together.

For what the AI agent does and doesn't send to a model, see AI data privacy.