Security you can verify, not take on faith.

Most enterprise AI systems retrieve everything and then instruct the model to be discreet about what it shows. Prompt-level rules can be argued with. Mithrandir's access control is structural: permissions define what the system can retrieve for a given user, before any model is involved.

• Restricted content never enters the model's context. Information a user is not cleared for is never assembled into the prompt, so no jailbreak or paraphrase can extract what was never there.
• Answers are complete per clearance level. Two people asking the identical question each get an answer that is complete for their access level: not an error, not a redaction, and never a leak.

This is a description of the product's architecture, not a certification. Design partners can verify these properties directly against their own data during onboarding.

Access control is not the only thing enforced in code. The current release ships these mechanisms, each covered by attack-shaped regression tests:

• Tamper-evident audit trail. Every administrative action lands in a per-tenant hash chain, so any alteration or deletion of the record is detectable. A dependency-free verifier can check the chain's integrity off the box that wrote it.
• Audit export to your SIEM. A durable exporter streams the audit chain off-box into your own monitoring stack, so the record survives even a compromised host.
• Controlled break-glass access. Emergency access requires cryptographically verified tokens (KMS-backed), not a shared password, and is itself written to the audit chain.
• Erasure without broken evidence. GDPR erasure is reconciled with the audit chain through chained redaction events: personal data is removed while the record's tamper-evidence stays intact.

We also audit the product internally on a recurring basis. Every High and Medium finding from the August 2026 audit was closed with fixes on the production call path and a regression test, before any design-partner data is connected.

This site has a lightweight waitlist and a separate design-partner application flow. The full picture:

• Waitlist entries: your email, an optional note, and a timestamp, stored in Supabase. The site talks to the database with an insert-only key under row-level security: the public API can add an entry but cannot read the list back (only an aggregate count).
• Design-partner applications: your name, work email, company, function, company size, problem description, source, and a timestamp, stored separately in Supabase. The same insert-only access pattern prevents the public API from reading applications back.
• IP addresses: processed transiently for rate limiting (Upstash). Not stored with either form submission.
• Analytics: Vercel Analytics, which is cookieless and does not track you across sites.
• Email: Resend sends a single welcome email when you join; replies go to a founder's inbox.
• Scheduling: Cal.com receives your name, email, and an opaque application reference only if you continue to the booking step.

Details on your rights and data handling are in the Privacy Policy.

• HTTPS everywhere with HSTS (preload, includeSubDomains), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a strict referrer policy, and a restrictive permissions policy.
• Insert-only grants and row-level security on both public form tables: no read, update, or delete path from the public API.
• Per-IP rate limiting on form submissions (5 requests per minute, sliding window), enforced before any parsing or database work.
• No accounts, sessions, or authentication surface on this site at all.

We do not run our own datacenters. The infrastructure behind this site is built entirely on providers that maintain an independent SOC 2 Type II report, so the physical, network, and platform layers are secured and audited by vendors examined every year. Each provider processes data only as needed to do its job:

Each provider publishes its own compliance documentation on its trust or security page, where its current report can be verified. These providers may process data on servers outside your country, including outside the EU/EEA and Türkiye. Product-level processing (for example, the model provider that reads content from a connected Slack workspace) is described in the Privacy Policy.

A few practices that hold today, not someday:

• Secrets stay out of the code. API keys and credentials live only in environment variables on our hosting provider, never committed to the repository.
• Least privilege by construction. The site reaches the database through an insert-only key under row-level security. Even a full compromise of that key cannot read, edit, or delete waitlist entries or design-partner applications.
• Minimal attack surface. There are no user accounts, passwords, sessions, or admin panel on this site, so there is nothing to phish or brute-force. The waitlist remains email-first; the richer information is requested only in the separate, intentional design-partner application.

Mithrandir ships self-hosted. The product deploys as a container inside your own VPC or on your own hardware, so your code, conversations, and decision history stay in your infrastructure. It can also run against a model you host yourself, in which case even answer synthesis never leaves your network. Design partners deploy alongside the founders, with a documented runbook rather than a black box. If your organization has requirements beyond this, tell us. This is exactly the stage where they influence the architecture.

We keep your waitlist entry until we launch and finish onboarding, or until you ask us to delete it, whichever comes first. We keep a design-partner application while evaluating and operating the program, or until you ask us to delete it. IP addresses used for rate limiting are processed transiently and are not retained. You can access, correct, or delete your data, or withdraw consent, at any time by emailing support@trymithrandir.com; the full list of your rights is in the Privacy Policy.

We are pre-launch and hold no security certifications of our own today, and we will not claim otherwise. The groundwork, however, is deliberate: least-privilege data access, secrets isolated to environment variables, minimal data collection, and infrastructure built entirely on SOC 2 Type II providers. SOC 2 is the target for once we have customers whose review process calls for it, and we are keeping logging, access-review, and change-management habits aligned with that audit from the start.

If you believe you have found a security issue on this site or in anything we ship, email support@trymithrandir.com. We read every report and will acknowledge yours within a few business days. Machine-readable details live at /.well-known/security.txt. We do not run a bug bounty program yet; we still want to hear from you, and we will credit you if you would like.