Security

Every tenant’s data is isolated at every layer — not just one. Isolation is enforced from the edge through to the database, where row-level security ties each query to the authenticated tenant. A request without the correct tenant context sees no rows.

Data is encrypted in transit (TLS) and at rest. Integration access and refresh tokens for connected services are additionally encrypted at the application layer before they are stored, so a datastore compromise does not expose usable credentials.

Models propose; tools execute. Anything that commits the company or mutates a system of record stops for human approval — enforced by a deterministic execution shell and a policy layer, not by prompt text. Routine reading and drafting are automated; decisions stay human.

Authorization and guardrails are expressed as versioned policy and evaluated on every governed action. Each tool declares its required scopes, reversibility, and blast radius, so high-impact operations are gated consistently rather than case by case.

Consequential actions are recorded in a tenant-scoped, hash-chained audit log kept in a separate store from operational data. The chain is verified continuously, so tampering is detectable rather than silent.

Access follows least privilege through role- and attribute-based controls and scoped service credentials. Service-to-service calls are authenticated; internal capabilities are not reachable from the public surface.

On request or account closure, a tenant-scoped erasure process removes your content and derived artifacts (such as embeddings) from primary stores and search indexes.

If you believe you have found a security vulnerability, please report it to your Gaia account representative or through in-product support. We investigate reports promptly and ask that you avoid accessing or modifying other users’ data while testing.