Skip to content
Gaard Gaard

Security & Data Isolation

This page explains the security model evaluators ask about: how organizations are isolated from one another, how the different access tokens work, and how sensitive data is protected at rest. It applies to both the cloud and on-premises distributions: the model is identical.

Tenant isolation

Section titled “Tenant isolation”

A tenant is the top-level boundary for an organization’s data. Every video, classification result, user membership, and configuration value belongs to exactly one tenant, and Gaard partitions data by tenant at the database level: each tenant’s operational data lives in its own dedicated database, keyed by the tenant name.

This has two consequences that matter for an evaluator:

  • No cross-tenant reads. A request is bound to a single tenant for its entire lifetime. Queries only ever run against that tenant’s database, so one organization cannot see, list, or address another organization’s data.
  • Access is scoped to the tenant, not shared globally. API tokens are issued for a specific tenant (see below), and a user only sees the tenants they have been granted membership in.

See Core Concepts for how tenants relate to solutions, flows, sites, and cameras.

The token model

Section titled “The token model”

Gaard uses three distinct kinds of credential, each for a different caller.

Browser sessions

Section titled “Browser sessions”

When a person signs in to the web app at app.gaard.ai, the platform issues an encrypted session cookie. Sign-in supports email and password, one-time magic links, and Google sign-in. The session carries the user’s identity and their currently selected tenant; switching tenants changes what the session can address, always within the tenants the user is a member of.

API tokens (tenant-scoped)

Section titled “API tokens (tenant-scoped)”

Machine-to-machine access (the classification API, webhooks, and integrations) uses API tokens. You create them in the web app at Settings → Platform → Integrations, and send them on every request in the Authorization header:

terminal
curl https://vision.gaard.ai/api/result/<classify_id> \
  -H "Authorization: Bearer <your-api-token>"

Each API token is scoped to a single tenant and, optionally, to a specific flow. A request presenting the token can only ever act within that tenant. For how to create and manage these tokens, see API Tokens.

Personal access tokens (CLI)

Section titled “Personal access tokens (CLI)”

The Gaard CLI authenticates with a personal access token (PAT). A PAT is tied to a user account and is recognizable by its pat_ prefix. PATs are created either through a browser-approved login flow or by signing in with your credentials from the CLI.

A PAT is shown in full only once, at creation time. Gaard stores only a SHA-256 hash of the token, never the token itself, so a token value cannot be recovered from the database: it can only be revoked and replaced. You can list and revoke your own tokens at any time.

Encryption at rest

Section titled “Encryption at rest”

Gaard encrypts the sensitive values it must store so that they are not readable in the database:

  • Integration credentials and secrets (such as the credentials used to deliver results to an external system) are encrypted with AES-GCM before they are written to the database, and decrypted only when the platform needs to use them. In the API and web app, these values are redacted (shown as ********) rather than returned in plaintext.
  • User passwords are never stored in plaintext or reversible form; they are hashed with bcrypt.
  • Personal access tokens are stored as SHA-256 hashes, as described above.
  • Session cookies are encrypted.

Next steps

Section titled “Next steps”