Data Processing Addendum
Last updated · 21 October 2026
This Data Processing Addendum (the “DPA”) forms part of the Terms of Service and the Software License Terms between Mithrandir Technologies Inc., a Delaware corporation (“Mithrandir”, “we”), and the customer (“Customer”, “you”). Capitalised terms not defined here have the meaning given in the Software License Terms. For personal data, this DPA prevails over the other documents of the Agreement. A data processing agreement signed with a customer prevails over this DPA for that customer.
1. The short version
- Mithrandir runs in your own cloud account (AWS, Azure or GCP), set up with our Terraform. Your Customer Data is stored and processed there, under your control, and we have no access to it.
- We process your personal data in two cases only: Telemetry you opt into, and data you choose to show or send us during support. In both, we are your processor and you are the controller.
- The LLM provider you configure works under your own contract with it. It is your processor, never ours.
2. Parties and roles
Customer is the controller of the personal data in Customer Data. Mithrandir is the processor only for (a) personal data in the Telemetry tiers Customer has turned on, and (b) personal data Customer shows or sends us during support. Mithrandir is not a processor of data that stays on Customer’s own infrastructure.
The LLM provider Customer configures, the source systems Customer connects and the AI clients its Users connect are Customer’s own providers, working under Customer’s own contracts. They are not Mithrandir’s subprocessors.
For the information this website and our billing collect (for example the name and email of a person who books a call or subscribes), Mithrandir is the controller, as the Privacy Policy describes. That processing is outside this DPA.
3. The personal data we process
- Tier 1 Telemetry, usage reports. Metadata only: per-tool call and error counts, latencies, request and response sizes, the Software’s own LLM token usage, configuration values, version identifiers, the license id, and salted seat pseudonyms. A salted seat pseudonym is a keyed hash of an account id; it is pseudonymised personal data. Never content, questions or answers.
- Tier 2 Telemetry, crash reports. The exception, stack trace and failing request, masked on the Deployment for secrets, personal-data patterns and the names the Deployment holds, before anything is sent. What free text a report may contain depends on the content class (full, question or metadata) set out in the Software License Terms, section 9. The seat appears only as a salted pseudonym.
- Support data. Only what Customer chooses to send or show in a support case, for example logs, screenshots or a shared screen. Never sent automatically. Personal data only as it appears in that material.
Data subjects: Customer’s Users, and the people whose data appears in a crash report or in support material. Purpose: to support, secure and improve the Software, to diagnose failures, and to apply any usage-tier discount. We never sell this data.
Telemetry is off by default and is sent only when Customer and we have agreed in writing to turn a tier on. A Subscription bought online sends no Telemetry unless that has been agreed. If Customer turns on automatic license renewal, the Software sends us the License File in force, which names Customer, the license tenant and the number of Seats; it carries no usage and no Customer Data.
4. Where Customer Data lives
Mithrandir is self-hosted and single-tenant. It runs in Customer’s own cloud account (AWS, Azure or GCP), set up with Mithrandir’s Terraform, or on other infrastructure Customer controls, one organization per install, and there is no hosted multi-tenant Mithrandir service. The LLM runs on Customer’s own provider account (its own API key, or Amazon Bedrock in its own AWS account), and the decision model runs self-hosted in Customer’s own account. Mithrandir does not host Customer Data and does not sell its own API keys. The graph, embeddings, answers and usage records stay in the database on Customer’s host. Embeddings are computed locally and are never sent to an LLM provider.
Mithrandir has no remote access to Customer’s hosts. The license check is offline and there is no remote kill switch. Apart from the opt-in flows in section 3, the Software sends nothing to Mithrandir.
5. Instructions and confidentiality
Mithrandir processes personal data only on Customer’s documented instructions, which are the Agreement and, where there is one, the Order Form. If Mithrandir believes an instruction breaks the law, it says so. People at Mithrandir with access to the data are bound by confidentiality.
6. Security measures
Mithrandir applies appropriate technical and organizational measures, including:
In the Software, on Customer’s infrastructure
- Connector OAuth refresh tokens and sync cursors are encrypted in the database with Fernet (AES-128-CBC with HMAC-SHA256), under a rotatable key that a key held by Customer can wrap.
- The web interface listens on the host’s loopback address only; the database publishes no port. Every application container runs as an unprivileged user with all Linux capabilities dropped.
- Every read is limited to what the asking person is cleared to see, and actions are recorded in tamper-evident audit chains that Customer can stream to its own collector.
- Crash reports are masked for secrets and personal data on the Deployment, before they are written.
- Release images are built from pinned, hash-locked dependencies and signed with Sigstore, so Customer can verify which release workflow produced them.
At Mithrandir
- Written company policies approved by both founders on 18 October 2026, covering information security, access control with quarterly review, change management, vendor management, business continuity, acceptable use and security training.
- Support data is used only for the case it was sent for, kept out of personal accounts, devices and storage, never put into a public or personal-account LLM, and deleted when the case closes.
- Least-privilege access, and secrets kept in a password manager, never in chat or code.
- Each Telemetry inbox belongs to one customer alone, with its own access token.
Customer secures the Deployment and its infrastructure: the host, the network edge and TLS, secrets, identity, backups and the choice of LLM provider. The security overview and security details pages describe the shared responsibility in full. This DPA makes no SOC 2 or ISO 27001 claim.
7. Subprocessors
Customer authorises the subprocessors listed on the Subprocessors page: GitHub, Inc. for the Telemetry inboxes, and the support tools (Google Workspace for email and screen-share, and a shared Slack channel where one is agreed). Mithrandir gives Customer at least 30 days’ written notice before it adds or replaces a subprocessor. Customer may object by switching Telemetry off, which removes both GitHub inboxes from its Deployment with no action from us, and by not sending support data through a tool it objects to.
8. International transfers
Either Telemetry tier sends pseudonymised personal data to GitHub in the United States. Customer turns a tier on only after it has met the requirements for that transfer that apply to it as controller (under KVKK art. 9, for example, standard contractual clauses notified to the Personal Data Protection Authority). Support data passes through the support tools named in section 7.
9. Data subject requests
Mithrandir helps Customer answer data subject requests for the personal data Mithrandir processes. For the data on its Deployment, Customer answers requests itself with the Software’s erasure commands, as the Software License Terms describe.
10. Personal data breaches
If Mithrandir confirms a security incident affecting Customer Data in its possession, or a vulnerability in the Software that puts Customer Data at risk, it notifies Customer without undue delay and at the latest within 72 hours of confirmation, with what it knows and the steps it recommends, so that Customer can meet its own notification deadlines under the GDPR and the KVKK.
Customer reports an incident on its Deployment to help@trymithrandir.com, and a vulnerability in the Software to security@trymithrandir.com. Detecting incidents on the Deployment is Customer’s task, because Mithrandir cannot see it.
11. Demonstrating compliance
Mithrandir provides Customer with the information reasonably needed to show compliance with this DPA, including the security pack that ships with every image of the Software.
12. Deletion and return
- Usage reports are deleted 13 months after receipt, and crash reports 90 days after receipt.
- Within 30 days after the Agreement ends, Mithrandir deletes every Telemetry document from Customer’s Deployment by deleting both inbox repositories, version history included.
- Support data is deleted when the support case closes, and in any event within 30 days after the Agreement ends.
- On the Deployment, Customer deletes its Customer Data with the full-deletion procedure the Software License Terms describe (section 15.4). Ending the license never blocks deletion: the deletion commands work without a License File in force.
13. KVKK and GDPR
Each party complies with the data protection law that applies to it, including Turkish Law No. 6698 on the Protection of Personal Data (KVKK) and, where it applies, the EU General Data Protection Regulation (GDPR). Customer is responsible for having a lawful basis for the data it connects to the Software, and for giving any notice its Users and other people whose data appears in Customer Data are owed.
14. Liability and term
Liability under this DPA is subject to the limits in the Software License Terms (section 13); there is no separate cap. This DPA lasts as long as Mithrandir holds personal data it processes for Customer.