Privacy Policy

Interlock MDR ("MDR", "we", "us") operates a managed data rail: companies connect their business systems, define the data products they are willing to share, and deliver them to partners under governed contracts. This policy explains what information we collect, how we use it, who we share it with, and the choices you have. It applies to the website at interlockmdr.com, the MDR application, the partner API, and the emails we send.

1. Who this policy covers

MDR is a business-to-business service, not a consumer product. Every account is held by a company and every transaction on MDR — a registration, a partnership, a contract, a transfer, a payment — is a business transaction between companies. Our customers are companies ("Companies"), and the people who use MDR do so on a Company's behalf ("Users"). When a Company connects to another Company on MDR, that other Company is a "Partner". This policy covers Users, the people whose details appear in Company records (for example a Partner's administrator named on a request), and visitors to our website.

For business data that a Company sends through MDR, the Company is the controller and MDR is the processor acting on its instructions. The terms of that processing are in our Data Processing Addendum. This policy describes what MDR does as the operator of the service.

Business data can include information about consumers — a Company's customers, for example. Although consumer data may be transmitted through MDR, MDR does not store it, and it is the responsibility of the sending Company and the receiving Company to ensure that what is sent and what is received is managed in accordance with all applicable consumer protection and privacy regulations. Requests from consumers about such data should be directed to the Company that holds it.

2. Information we collect

2.1 Account and profile information

When you register we collect your name, email address, phone number, and the credentials you choose. Your password is handled by our authentication provider (Google Firebase Authentication) and is never visible to MDR. We record when you accepted the Terms of Service and this policy, and which versions.

2.2 Company information

A Company's name, address, industry, company type, logo, company code, discoverability setting, plan, partner budget, and the roles each User holds within it. Company information other than the address is visible to other Companies on MDR when the Company chooses to be discoverable, and to Partners once connected.

2.3 Billing information

Payment details are collected and stored by Stripe on Stripe's hosted pages. MDR stores a Stripe customer reference, the card brand and last four digits for display, invoice records (period, partner connections billed, amounts, status), discount codes redeemed, and the trial terms accepted. MDR never stores card numbers.

2.4 Connection metadata

When a Company connects a business system (for example QuickBooks, Salesforce, BigQuery, or a custom API) we store the provider, the connection's configuration, the schema of the entities and fields it exposes, and the credentials the provider issues to MDR — OAuth tokens or API keys. Credentials are encrypted at rest with a key held in a managed key vault, separate from the database, and are used only to fetch data the Company has asked MDR to transfer.

2.5 Products, mappings, controls and contracts

The data products a Company defines (sheet and field names, types, relationships, descriptions), the mappings that fill them from a source, the controls and filters a Company sets, partnership requests and approvals, product-sharing requests, and the contracts under which data is delivered — including their frozen controls, schedules, and delivery history (counts, timestamps, outcome and reason codes). This is metadata about data; it is not the data.

2.6 Partner API credentials

Client identifiers, hashed client secrets, access and refresh tokens, access keys, webhook endpoints and webhook signing secrets that a Partner registers in the Developer Portal. Secrets are shown once and stored hashed or encrypted.

2.7 Audit and activity records

Sign-ins and sign-outs, authorization decisions, partnership and product permission changes, role changes, contract lifecycle events, account deletions, and partner API calls — with the acting User, the Company they were acting as, the time, the outcome, and the IP address of the request. These records exist so that every change to who can see what is attributable.

2.8 AI activity

When a Company enables Hot Sauce AI, we log which AI features were used, by whom, when, and the sources they were allowed to read. What is sent to the AI model is governed by the Company's own AI preferences — see Section 6.

2.9 Communications and support

Messages exchanged between Partners inside MDR, notifications we send you and their delivery status, and anything you send us through the contact form or by email.

2.10 Technical information

Request logs (IP address, user agent, timestamps, the endpoint called, response status), error reports, and performance measurements. We use these to keep the service running, secure, and fast.

3. What MDR does not store

MDR is designed so that the business records a Company transfers to a Partner pass through MDR and are not retained. A transfer reads from the Company's source, applies the contract's controls, and streams the result to the Partner. The records are held in memory only for the duration of that request and are not written to our database or to disk.

There are four narrow exceptions, each bounded and each explained here:

• Previews. When a User previews a product or a mapping, a bounded sample of rows is fetched and shown in that User's browser session. It is not stored by MDR.
• AI results. When Hot Sauce AI runs, the model's response (which may quote sample values it was shown) is held encrypted until the User's browser retrieves it, and is deleted the moment it is read. Abandoned results are deleted automatically.
• Incremental sync positions. To deliver only what changed since the last transfer, MDR stores the watermark values (for example the most recent modification timestamp) that mark where a Partner's last delivery ended. These are encrypted at rest and a Partner may hold them itself instead.
• Delivery diagnostics. When a transfer fails or a join matches nothing, MDR records counts, column names and reason codes so the sender can fix the problem. It does not record the values.

4. How we use information

• To provide the service: authenticate you, run your Company, move data under your contracts, and show you what happened.
• To keep it secure: detect misuse, enforce entitlements, maintain the audit trail, and investigate incidents.
• To bill: compute invoices from partner connections, charge the payment method on file through Stripe, and apply discounts.
• To notify: deliver the emails the service depends on — verification, password reset, invitations, contract and transfer health, invoices.
• To support you: respond to requests sent through the contact form or by email.
• To improve the service: understand how features are used, in aggregate, and fix what fails.
• To meet legal obligations: tax, accounting, and responding to lawful requests.

We may also use a Company's business contact information to tell it about the service — new features, changes to these documents, and offers relevant to how it uses MDR. Company contacts can opt out of marketing messages at any time; messages the service depends on (Section 4, fourth item) continue. We do not sell personal information, we do not use it for consumer advertising or cross-site tracking, and we do not use your business data, your products or your mappings to train AI models.

5. How information is shared

5.1 With Partners you choose

MDR is a platform for sharing between Companies, so some information is visible to the Companies you connect with by design: your Company's name and public profile, the products you offer or request, the contracts you enter, transfer outcomes, and the names and email addresses of the Users who send requests or messages. A Partner's administrators see the same about you. Business data reaches a Partner only under a contract both Companies approved.

5.2 With service providers

We use a small number of providers to run MDR, each bound by contract to process information only on our instructions. The current list, with what each one does and where it processes data, is maintained at interlockmdr.com/subprocessors. Today they are Microsoft Azure (hosting, database, secrets), Azure Communication Services (email), Google Firebase (authentication), Stripe (payments), Anthropic (AI features, only when a Company enables them), and Cloudflare (DNS and network protection).

5.3 With marketing and service partners

We may work with marketing companies and other third-party service providers to help us provide the best possible service to the Companies on the platform — for example to run business communications, gather product feedback, provide support tooling, or deliver onboarding and integration services. Such a partner receives only the business contact and account information needed for its task, under a contract that limits its use to that task. Business data that moves through MDR is never shared with marketing or service partners — it is not stored, and it reaches only the Partner a Company chose (Section 3 and Section 5.1).

5.4 With the systems you connect

When you connect a business system, MDR calls that provider's API with the credentials it issued. Your use of that provider is governed by its own terms and privacy policy.

5.5 Legal and safety

We may disclose information when required by law, to enforce our terms, or to protect the rights, property or safety of MDR, our customers, or the public. Where permitted, we will notify the affected Company before responding to a legal request.

5.6 Business transfers

If MDR is involved in a merger, acquisition or sale of assets, information may be transferred as part of that transaction, under this policy.

6. AI features

Hot Sauce AI helps Companies design data products and map fields. It is powered by models from Anthropic, accessed through Anthropic's commercial API. Each Company controls what the AI may see through its AI Preferences:

• Off — no information is sent to the model.
• Counts — only schema names, field types and row counts are sent; never values.
• Samples — a small sample of records from the sources the Company explicitly allows is sent so the model can judge how fields relate.

Nothing is sent from a source the Company has not allowed. Under Anthropic's commercial terms, inputs sent through the API are not used to train Anthropic's models. Model outputs are held encrypted and deleted once read, as described in Section 3.

7. Cookies and browser storage

MDR uses only what the service needs to function. The application keeps your sign-in in browser session storage, so it ends when you close the browser, and keeps small preferences — such as which Company you are acting as and how a screen was last laid out — in your browser's local storage. We do not use advertising or cross-site tracking cookies. Pages hosted by Stripe for payment set Stripe's own cookies under Stripe's policy. The marketing website sets no cookies of its own.

8. Security

Controls we maintain include:

• Encryption in transit (TLS) for every connection, and encryption at rest for the database and backups.
• Application-level encryption of every stored credential, sync position and AI result, with keys held in a managed key vault separate from the database.
• Role-based entitlements: what a User can do is decided by the permissions on their role within the active Company, on every request, and every change is audited.
• Tenant isolation: every record is attributed to a Company and every query is scoped to it; a new Company starts with an empty slate.
• Verified email addresses, session-scoped sign-in, and automatic sign-out after 30 minutes of inactivity.
• Secrets shown once and stored hashed; partner webhook payloads signed so their origin can be verified.
• Complete-or-fail transfers: a delivery that cannot be completed is stopped and reported, never partially delivered in silence.

No system is perfectly secure. If we learn of a breach affecting your information we will notify the affected Companies without undue delay, as described in the Data Processing Addendum.

9. Retention

• Account and Company information — for as long as the account or Company exists.
• Deleted accounts — when a User deletes their account, their personal details are removed; a non-identifying record is retained because partnerships and audit events reference it. When a Company is deleted, its partnerships, contracts and connections end, its credentials are deleted, and its record is retained in the same non-identifying form.
• Audit records — retained for the life of the Company and afterwards for as long as needed to meet security, legal and compliance obligations.
• Billing records — retained as required by tax and accounting law.
• Transferred business data — not retained (Section 3).
• Technical logs — retained for a limited period for security and operations, then deleted.

10. Your rights and choices

You can view and update your profile, and a Company administrator can update the Company's information, in the application. You can delete your account from your profile; a Company administrator can delete the Company. Depending on where you live, you may also have the right to request access to, correction or deletion of your personal information, to receive a copy of it, to object to or restrict certain processing, and to complain to a supervisory authority.

If you are in the European Economic Area, the United Kingdom or Switzerland, we process personal information on the bases of performing our contract with your Company, our legitimate interests in operating and securing the service, compliance with legal obligations, and consent where we ask for it. If you are a California resident, we do not sell or share personal information for cross-context behavioral advertising, and you may exercise your rights under the CCPA/CPRA through the contact below without discrimination.

Because MDR processes most information on behalf of a Company, requests about business data or about your role within a Company are usually fulfilled through that Company's administrator; we will help them do so. To exercise any right, contact us. We will verify your identity before acting and respond within the time the applicable law requires.

11. International transfers

MDR is operated from the United States and our infrastructure is hosted in Microsoft Azure in the United States. If you use MDR from elsewhere, your information is transferred to and processed in the United States. For Companies subject to European or UK data protection law, transfers are made under the Standard Contractual Clauses incorporated in our Data Processing Addendum.

12. Children

MDR is a business service and is not directed to anyone under 18. We do not knowingly collect personal information from children.

13. Changes to this policy

This policy carries a version. When we change it materially, we will update the version, note the effective date, and ask Users to accept the new version in the application before continuing. Continued use after a non-material change constitutes acceptance.

14. Contact

Questions, requests or concerns about privacy: interlockmdr.com/contact.