Security you can verify, not take on faith.

People see only what their work already lets them see. Your company's hierarchy decides the rest. Permissions are mirrored from each tool automatically. There are no policies to write by hand and no metadata to tag.

Ethical walls you set apply on top of everything: no share, role or exception can cross them.

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 person, before any model is involved.

• Restricted content never enters the model's context. Information a person cannot open is never assembled into the prompt, so no jailbreak or paraphrase can extract what was never there.
• Answers are complete for each person. Two people asking the identical question each get an answer that is complete for what they may open: not an error, not a redaction, and never a leak. The example above shows it from CEO to sales intern.

Measured across more than 30,000 entries: 0 leaks, and 100% of answers sourced.

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

Access control is not the only thing enforced in code. The product 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 customer data was connected.

Mithrandir mirrors each source's own permissions: Slack channels, GitHub repositories, Jira and Linear teams, Google Drive sharing. A person sees in their agent what they could already open in the source, and nothing more. Nobody writes access policies: the tools already hold them.

• Where a tool has no permissions, your company's hierarchy decides who sees what.
• Stale means dark, not open. If permission data for a source stops refreshing, the content it covers stops being served until it does.
• Revocation follows the source. Leaving a Slack channel re-syncs access immediately. Sources we check on a schedule reflect a revocation within about fifteen minutes. Disabling a person in Mithrandir cuts their access at once.
• The most sensitive documents are re-checked live with the source before they are served, and withheld if the source cannot be reached.

Administrative actions and every write an agent makes in your tools go into a tamper-evident log, one per installation, that you can stream to your SIEM and verify independently (details under “What the product enforces” above).

Separately, each question is recorded as usage: who asked, when, and how much was withheld from them. Never the content of the answer. Usage records are kept for a year and are not part of the tamper-evident log.

• Single-tenant. One organization per installation, deployed in your own cloud or on your own hardware. There is no shared, multi-tenant Mithrandir service holding your data next to someone else's.
• Credentials encrypted. The keys Mithrandir uses to read your sources are encrypted at rest, and every connection to a source or a model provider is over HTTPS.
• Only what the asker may see reaches a model. Search indexes are built on your installation, not by a third party.
• Your model, your terms. Mithrandir trains no models on your data. It runs on your own account with OpenAI, Anthropic or Google, or on a model you host, in which case nothing leaves your network. With a hosted provider, that provider's retention terms are the ones in your agreement with them.

• Erasure on request. A verified erasure (GDPR, KVKK) removes the content, the personal data and its search entries, while the audit log stays provably intact.
• Legal hold. Records under hold are protected from deletion until it is lifted.
• At contract end, offboarding deletes the organization's data and keeps only an anonymized audit summary.

This site has no forms at all: the only way to reach us is the founder calendar. The full picture:

• Call bookings: your name, email, the site link that led you to the calendar, and a timestamp, stored separately in Supabase. They are written by our Cal.com webhook receiver, which accepts nothing without a valid signature; the public API has no access to this table at all.
• Analytics: Vercel Analytics, which is cookieless and does not track you across sites.
• Scheduling: booking opens Cal.com in a new tab. Cal.com receives what you enter on its booking page; nothing from Cal.com is embedded in this site.

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.
• No forms. Booking records arrive only through the Cal.com webhook, and every request without a valid signature is refused.
• The public API has no read, insert, update, or delete path to the booking table.
• 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 we hold to:

• 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 public site holds no database credential at all. Booking records are written only by the Cal.com webhook receiver, which refuses anything without a valid signature.
• Minimal attack surface. There are no user accounts, passwords, sessions, forms, or admin panel on this site, so there is nothing to phish, brute-force, or spam. Booking a call happens on Cal.com.

Mithrandir ships self-hosted. The product deploys as a container inside your own VPC or on your own hardware, so your code, conversations, and company knowledge stay in your infrastructure. It can also run against a model you host yourself, in which case even answer synthesis never leaves your network. Every deployment is done alongside the founders, with a documented runbook rather than a black box. If your organization has requirements beyond this, bring them to the first call.

We keep a booking record while we are in conversation or working together, or until you ask us to delete it. 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, 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; we still want to hear from you, and we will credit you if you would like.