Adamant Security Model

Account and login storage

• Account identities and authentication state are managed by Supabase Auth in the configured Supabase project.
• The browser Supabase session is stored under an Adamant-specific client storage key and refreshed by the Supabase client.
• Google and GitHub sign-in use OAuth/OIDC through Supabase. Email login uses one-time links. Password login is available only as a fallback path.
• Adamant does not store OAuth provider passwords, Google passwords, GitHub passwords, or Supabase service-role keys in the browser.

Login hardening

• OAuth and email-link sign-in are preferred over password entry.
• Auth redirects return to the exact production /app callback and the browser client uses the PKCE auth flow.
• OAuth provider buttons are shown only when the matching deployment flag is enabled and the Supabase provider is configured.
• Optional Cloudflare Turnstile can be enabled for email-link and password attempts.
• Client-side cooldowns reduce repeated auth attempts from the modal. Supabase rate limits and provider controls should also remain enabled.
• User-facing auth errors are intentionally generic to reduce account enumeration signals.

What stays local

• Provider API keys are stored on the user's device, not in Supabase.
• Connected note folders (Markdown, text, org) are read on-device through the browser's file permission model. Original files are never uploaded.
• The browser capture helper reads only visible text in the current tab and copies JSON to the clipboard.
• Payload scanning and sanitization run before external model calls.

What can leave the browser

• Memory records sync to the user's Supabase account when signed in.
• Vectors are sent to a Pinecone index only if the user connects one. Vector storage is optional; without it Adamant uses built-in keyword retrieval.
• Selected chat context is sent to the chosen model provider after retrieval and sanitization.

Transport and storage protections

• Traffic between the browser, Supabase, and connected services uses TLS (HTTPS).
• Synced records live in Supabase Postgres, which encrypts data at rest.
• Every user-data table is protected by Postgres row-level security: an authenticated session can read and write only its own rows.
• Signed-out browsing runs on bundled sample data. It does not read any user's stored records.

Current beta responsibility boundary

• Users should bring their own Pinecone index and namespace for vector storage.
• Users are responsible for deciding what data they are allowed to import, vectorize, and send to model providers.
• Supabase, Pinecone, and model providers process data under the user's selected accounts, configurations, and terms.
• Adamant is not a compliance product and does not provide legal, security, medical, or financial advice.

Read the data responsibility notice before using personal or business data.

Visibility

The Payload Inspector shows retrieved chunks, source provenance, token estimates, and sanitization results. The CLI prints [Adamant] status lines for each retrieval.