How Armbrain is secured.

Architecture and data flow

Armbrain is a hosted service. You use it through the Armbrain HQ dashboard in your browser, or from AI assistants such as Claude and ChatGPT, which connect to Armbrain over the Model Context Protocol (MCP).

• Application. Armbrain’s application runs on Cloudflare’s serverless platform. Every request is authenticated there before it can read or write data.
• Storage. Your memories, minds, and settings are stored in a managed PostgreSQL database hosted by Supabase. Original files you upload or connect are stored in Cloudflare R2 object storage.
• AI processing. To extract memories and answer questions, Armbrain sends the relevant text to Anthropic’s Claude models. These requests are routed through Cloudflare’s AI Gateway. To make your content searchable, Armbrain sends text to Voyage AI to create search embeddings.
• Connected tools. When you connect a tool, Armbrain reads from it with the access you approved and stores what it brings in under the mind you chose.

Encryption in transit and at rest

• At rest. Your stored data lives with Supabase (database and backup storage) and Cloudflare (uploaded files and short-lived data). Both encrypt stored data at rest with AES-256, managed by the provider.
• In transit. Armbrain’s website, dashboard, and API use HTTPS. They send HTTP Strict Transport Security (HSTS) headers, which tell browsers to use only HTTPS on later visits. Armbrain’s own calls to its database, AI, and search providers also use HTTPS.
• Connected-account credentials. Armbrain encrypts the OAuth tokens and credentials for your connected tools before storing them. It uses envelope encryption with AES-256-GCM. Each credential gets its own data key, and that key is in turn encrypted with a master key. The master key is held as a platform secret, never in the database, and can be rotated.
• Keys and tokens. Armbrain API keys, and the access and refresh tokens issued to AI assistants, are stored only as one-way SHA-256 hashes. The original value can’t be read back, even by us.
• Passwords. New dashboard passwords are salted and hashed with PBKDF2-SHA-256 at the work factor OWASP recommends.

Sign-in and access control

Dashboard sign-in

• You can sign in with Google, with Microsoft, with a passkey, or with an email and password. Google and Microsoft sign-ins are checked against each provider’s published signing keys.
• Browser sessions use signed cookies marked HttpOnly, Secure, and SameSite, and they expire. Changes made in the dashboard with a session cookie must come from Armbrain’s own site, which protects against cross-site request forgery.
• Armbrain emails you when your account is signed in to from a new device or location, and when your password changes.

AI assistant (MCP) access

• AI assistants connect through OAuth 2.0 with PKCE, and PKCE is mandatory. Redirect addresses must exactly match an approved list, and authorization codes are short-lived and work only once.
• Access tokens Armbrain issues to Claude expire after one hour, and ChatGPT access tokens expire after 90 days. Each refresh token is replaced every time it’s used.
• Instead of OAuth, you can use a personal Armbrain API key. Keys can be rotated.
• Every request is authenticated, tied to your account, and rate-limited. Failed sign-in attempts are tracked, and unusual patterns alert our team.

Team access

• Access is granted mind by mind. Each team member has a role on each mind (owner, editor, or viewer), and Armbrain checks that role on the server before it allows a change.
• Memory search applies the role’s visibility rules on the server, so restricted content isn’t returned to roles that aren’t allowed to see it.
• Armbrain’s internal admin tools use their own separate sign-in. Customer credentials can’t open them.

Customer and mind isolation

• Every record is tagged with the customer it belongs to, and client content is also tagged with its mind. Each request is checked against the signed-in customer and the requested mind, both when information is added and when it’s recalled.
• This scoping is enforced by automated checks. The build fails if code queries a customer-owned table without a customer or mind filter. Unscoped bulk reads are refused at runtime. Code that keeps data in memory between requests is also checked, so it can’t share data across customers.
• A dedicated isolation test suite has to pass before any change can merge. It tries to read across customers and across minds, including through exports, handoffs, and team sharing. It also runs every night against the live codebase.
• Row-level security is turned on for customer tables, and the database’s public access roles have no access to them. Armbrain’s server connects with a privileged database role, so in practice isolation comes from the application scoping every query by customer and mind. The automated checks and isolation tests above are the controls for that.

Secrets handling

• Production secrets are stored as Cloudflare platform secrets and supplied to the application when it runs. This includes database credentials, provider API keys, and encryption master keys. They are never committed to source code.
• Every proposed code change is automatically scanned for leaked secrets, and a change that fails the scan can’t merge.
• Passwords, session cookies, and webhook signatures are checked with constant-time comparisons, so response timing doesn’t reveal them.

Connected tools and permissions

• You choose which tools to connect. Each connection uses your own account with that provider, and you approve it on the provider’s own consent screen. You can disconnect a tool at any time.
• Google. Gmail, Drive, Google Analytics, Search Console, and Contacts are requested as read-only. Google Calendar uses event access, so Armbrain can add calendar entries when you ask it to.
• Microsoft 365. Mail, Files, and Calendars are requested as read-only.
• Apps connected through Composio. Some apps, such as LinkedIn, Instagram, and Facebook Pages, connect through Composio, an integration provider. For those apps, Composio holds the login tokens. Armbrain stores only a reference to the connection, plus the page you choose for it to read.
• Each connection flow checks a server-side state value, which blocks forged connection attempts.
• Armbrain treats content from connected tools as untrusted. Web addresses it fetches for you are checked so they can’t point at internal networks. Uploaded archives are checked for decompression bombs. Text is screened for prompt-injection patterns, and anything suspicious is flagged.

Hosting and service providers

• Your stored data is hosted in the United States. Cloudflare runs Armbrain’s application on its global network and places it close to the database.
• The service providers that process customer data include Anthropic (AI), Voyage AI (search embeddings), Supabase (database hosting), Cloudflare (application hosting, storage, and request routing), Resend (transactional email), and Stripe (payments). The sub-processor disclosure gives each listed provider’s purpose and data categories.

Retention and deletion

• Armbrain keeps your content while your account is active, until you delete it.
• Memories. A deleted memory stops appearing right away. It’s permanently removed once a 30-day recovery window ends.
• Client minds. To delete a mind, you confirm it by typing its name. Deleting it removes the mind’s records and its stored original files, and the deletion is recorded in an audit log. Backup copies of its files expire after 30 days.
• Accounts. When you delete your account, it’s deactivated and signed out right away, and you get an email with a link to cancel. After a 7-day grace period, the deletion becomes permanent.
• Export. You can export a client mind at any time, for example to hand it off.
• The traces Armbrain uses to debug its ingestion pipeline contain only identifiers, counts, and timings. They never include your content.

Logging and audit

• Every API and tool request is logged with the account, the tool used, the result, and the timing. We use these logs to monitor usage and abuse.
• Selected account actions are written to an append-only audit log. The database itself refuses to delete entries from it.
• Mind deletions are recorded in a separate deletion audit log, along with a count of what was removed.
• Every change to a mind’s brand voice is kept as a history entry.

Backups

• Every night, original files are copied from primary storage (Cloudflare R2) to a separate provider (Supabase Storage). That way, a problem at one vendor can’t destroy them.
• Each backup copy is checked against the file’s content hash before it’s marked complete. Files from deleted minds aren’t copied, and backup copies of deleted files expire after 30 days.

Monitoring and incident response

• Automated monitoring and synthetic customer checks run around the clock and alert our team when something fails.
• We keep written runbooks for the incidents that matter most: a compromised key or credential, a service outage, a database provider outage, and a bad release. For a compromised key, the runbook covers revoking it, rotating every affected secret, and redeploying.
• To report a vulnerability, email security@armbrain.io. This contact is also published in our security.txt file.

Secure development and vulnerability management

• Every change reaches production through a reviewed pull request. The main branch is protected: changes need an approving review, go through a merge queue, and can’t be force-pushed.
• Before any change can merge, it must pass secret scanning (gitleaks), dependency vulnerability scanning (OSV-Scanner), static analysis (Semgrep), and the test suite, including the isolation tests.
• Changes to sign-in, OAuth, security code, or build pipelines are automatically flagged for a separate security review.
• Dependency updates are proposed automatically each week. New versions wait through a short cooling-off period, which guards against compromised releases. A weekly audit also checks production dependencies for known high-severity vulnerabilities, and dependency and static-analysis scans run on a schedule.
• Third-party build actions are pinned to exact commit versions, not movable tags.
• A prompt-injection test suite runs every night, and again whenever ingestion code changes.