Security at Atmind AI
These are the controls we run across the software we build, by default.
Last updated: April 18, 2026
Row-level security on every user-facing table
Our applications run on Postgres with Row-Level Security (RLS) enabled on every table that holds user data. Policies are scoped to the authenticated user, so even a bug in application code cannot return another user's rows. The database itself refuses. RLS is defense-in-depth, not a substitute for application checks, but it is the last line that catches anything the application missed.
TLS everywhere, HSTS preloaded
Every connection to our products uses TLS 1.2 or newer. HSTS is enabled with preload, so browsers refuse to downgrade to HTTP even on a user's first visit. Legacy cipher suites are disabled at the edge.
Strict content-security policy
Marketing sites and products both serve a strict Content-Security-Policy. Frames are denied, mixed content is blocked, upgrade-insecure-requests is on, and script sources are pinned to the app's own origin. We also set X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and Cross-Origin-Opener-Policy: same-origin.
Scoped tokens for AI integrations
When users connect Claude, ChatGPT, or any MCP-compatible client to our products, the server issues a token scoped to a single tier (read-only, write, or manage). The token is the only credential the AI agent sees; it never gets the user's password. Revoking the token is immediate. Tool inputs are validated with typed schemas before any database operation runs.
Minimal logging, redacted identifiers
We log what we need to operate each service and no more. Request bodies are not logged; identifiers are redacted where possible. Sensitive categories of data are never logged and never used for advertising or model training. Aggregated, anonymous telemetry may be used to improve product reliability.
Defense in depth across layers
Authentication runs through a proxy that verifies sessions on every request. Server actions re-check the user's identity before any mutation. The database then enforces RLS independently. An attacker would need to bypass three separate layers (application auth, server-side checks, and database policies) to read or modify user data.
Responsible disclosure
Found a vulnerability? Please report it privately to security@atmind.ai. We reply within two business days. Please give us a reasonable window to fix the issue before public disclosure. Our machine-readable policy is at /.well-known/security.txt.