Security posture

Built with security from the start

Tages is open-source and self-hostable. We document our security posture openly so you can evaluate it for your team.

AES-256-GCM encryptionTLS 1.2+Supabase AuthRLS on all tablesRBACOpen source

Encryption at rest

Tages supports optional AES-256-GCM field-level encryption for memory values stored in Supabase. When enabled, memory content is encrypted before it ever reaches the database. Only your application can decrypt it.

To enable encryption, set the TAGES_ENCRYPTION_KEY environment variable to a 32-byte hex key. Without this variable, data is stored in plaintext (protected by Supabase RLS policies and your database credentials).

Encryption is opt-in by design. Self-hosted users choose their own key management strategy.

Encryption in transit

All connections to the Tages cloud dashboard and Supabase backend use TLS 1.2 or higher. HTTP Strict Transport Security (HSTS) is enforced on the dashboard to prevent protocol downgrade attacks.

The MCP server and CLI communicate with Supabase over TLS. Local SQLite cache reads remain on-device and never leave your machine.

Authentication

The dashboard uses Supabase Auth with GitHub OAuth. Sessions are managed with SameSite=Strict cookies to prevent cross-site request forgery.

CLI tokens are hashed with SHA-256 before storage. Raw tokens are never persisted. Tokens support configurable expiry and can be rotated at any time with:

tages token rotate --expires-in 30

Auth events (login success/failure, token validation) are written to an audit log for accountability and incident response.

Data flow and LLM privacy

Your memory data is never used to train LLMs. Tages does not send your codebase memories to any external model unless you explicitly invoke a recall or auto-index operation.

Auto-indexing uses Ollama (local, no network calls) by default, with Claude Haiku as an optional fallback for users who opt in. Data sent to Haiku is governed by Anthropic's API terms, which prohibit training on API inputs.

When you self-host, all data stays in your own Supabase project. Tages never has access to it.

Access control

Every table in the Tages schema has Row-Level Security (RLS) enabled with per-user and per-project policies. Users can only read and write their own data. This is enforced at the database layer, not just in application code.

Projects support role-based access control with three roles:

  • Owner: full control, can manage members and delete the project
  • Admin: can read and write memories, manage most settings
  • Member: read-only access to project memories

Self-hosting

Tages is fully open-source (MIT). You can run the entire stack on your own infrastructure with your own Supabase project. Bring your own keys, your own OAuth app, and your own encryption key.

When self-hosting, the cloud dashboard at tages.ai is never involved. Your agents connect directly to your Supabase instance. This is the highest-isolation option for teams with strict data residency requirements.

npm install -g @tages/cli tages init --supabase-url YOUR_URL --supabase-key YOUR_KEY

Responsible disclosure

We take security reports seriously. If you discover a vulnerability, please report it privately. Do not open a public GitHub issue.

Email: security@tages.ai

GitHub Security Advisory: Submit a private report

We acknowledge reports within 48 hours and aim to patch critical issues within 7 days. Full disclosure policy in SECURITY.md.

Questions about our security posture?

We're happy to answer questions from security teams evaluating Tages.

Contact security@tages.ai