Sub-processor Register
Effective 2026-09-10
inxo — Sub-processor Register
Version 2026-09-10.
This page is written from compliance/sub-processors.json (register version 8, effective
2026-09-09), which is the source of truth. It is not generated from it — a person transcribed
it — so where this page and that file disagree, that file is right and this page is a bug.
A parity check between them is tracked as part of publication.
Current status: no external tenant is yet connected, and this page is not yet published in the sense the law means — the availability obligation to controllers is satisfied at the first external tenant, not before. It is versioned here from the start so its history is honest, not because processing has begun.
Who processes your data on our behalf
| Sub-processor | What it does | Where | Categories |
|---|---|---|---|
| Microsoft Corporation — Microsoft Azure | Hosting and managed data services. Runs the inxo ingress and worker roles and stores the operational data they process on your behalf. | A single United States region — Microsoft Azure’s Central US region. We operate one deployment and do not offer a choice of region. Every shard, replica and backup stays in that region — there is no cross-region replica. If you, or the people who write to you, are outside the United States, our storage of your data is itself an international transfer; see the Data Processing Addendum §11. | Email content, email addresses, thread metadata, end-user identifiers |
| Microsoft Corporation — Azure AI Foundry | Model inference for drafting and classification, when your workspace is pinned to a model Microsoft itself sells and hosts — our Foundry-OpenAI path, on which Microsoft is the sole processor (see the next row for the other path). Also: converts your knowledge-base text into search vectors when you add or change an entry, and searches that knowledge base when a reply is drafted — which sends the incoming message to the same endpoint as a search query, and passes the passages it finds to the model with the draft. Embedding always runs through this Microsoft-operated endpoint, whichever model drafts your reply — including on a workspace pinned to a Claude model. | The region pinned on the workspace’s provider-readiness record — a separate one for embedding, which is pinned and cleared independently of drafting. | Email content, email addresses, thread metadata, end-user identifiers, third-party participants named in a thread, and the text of knowledge-base entries you add |
| Anthropic, PBC | Model inference for drafting and classification, only when your workspace is pinned to a Claude model on Azure AI Foundry — our Foundry-Claude path. Claude on Foundry is a Marketplace offering that Anthropic — not Microsoft — sells and operates: Anthropic is an independent processor for the prompts and completions sent to it, and Azure OpenAI’s zero-data-retention commitments do not extend to it. Microsoft separately shares your account’s contact information, transaction details and usage volume with Anthropic to operate the offering — a disclosure distinct from, and in addition to, the reply content itself. Automatic safeguards may flag content for human review by Anthropic’s Trust and Safety team, on an exceptions-only basis — not routine access, but real access, named here rather than left for you to assume away. | Depends on which of two hosting options Microsoft’s deployment of the pinned model uses. Hosted on Azure keeps ingress, the API and inference on Azure infrastructure, with data at rest in the selected Azure geography — a geography, not a single region, and processing may be routed within it under Microsoft’s global or data-zone deployment options. Hosted on Anthropic Infrastructure processes on Anthropic’s own infrastructure, and Microsoft states data may be processed outside Azure and outside the selected region entirely — a materially different placement, because it can mean leaving Microsoft’s infrastructure altogether. Which option is in use is not recorded in our own provider-readiness record today — that record pins the provider, the model and the region, and has no field for it — so it is established from the deployment itself as part of the terms and assessment below. We say so rather than implying a control we do not have. | Email content, email addresses, thread metadata, end-user identifiers, third-party participants named in a thread |
What the model receives, specifically
Drafting sends the model context drawn from the whole thread, not a single message — that is what makes a reply read like it belongs to the conversation, and it is a wider disclosure than a per-message design would be. It is bounded by a size budget, so a very long conversation is truncated to its newest turns plus the message being replied to. We state both rather than let either be inferred.
What is not sent: attachments; content hidden in HTML (stripped before the model sees anything); and context beyond the per-draft budget (truncated). The model can only return a message body — it cannot choose a recipient, a subject, a sending address, a language or the AI marking, because none of those are fields it is allowed to write.
Your knowledge base reaches the model in two ways, and we would rather name both than let you infer them from silence. First, when you add or change an entry, its text is sent once to an embedding endpoint to be turned into search vectors — a different flow from drafting, because it happens when you save an entry rather than when a reply is written. Second, when a reply is drafted we search that knowledge base: the incoming message goes to the same embedding endpoint as a search query, and the passages it matches are passed to the model alongside the thread. Both flows carry what you chose to put in your entries — which, in a support knowledge base, may include customer detail.
Three limits apply to what a draft can pull in, and they are enforced rather than intended. The search is scoped to your workspace and the specific data controller whose mailbox the message arrived on — in a managed-service account holding mailboxes for several client organizations, one client’s knowledge base is never read while replying on another’s mail, and if the controller cannot be determined nothing is retrieved at all. The number of passages and their total size are capped, so what a draft sends does not grow as your knowledge base does. And a draft that could not search — because you have no entries, because the retrieval budget is spent, or because the endpoint was unavailable — falls back to the thread alone and records that it did, rather than quietly producing a less-grounded reply.
Because a knowledge base is shared across every conversation in a workspace, a passage written while helping one customer can be matched while replying to another. So any reply written using your knowledge base is put in front of a person — automatic sending is withheld for all of them, not only for the ones a check happens to flag. We say it that way because the alternative would be a promise about what our checks can spot in the wording, and the wording is the part an attacker who can get text into a knowledge base is trying to influence. Where a reply does repeat personal detail traceable to a passage, the reviewer is shown which passage it came from.
Two consequences of holding a knowledge base, both worth stating plainly. Its entries have no time-based expiry — they stay until you remove them, the workspace closes, or the last mailbox connection for that data controller is disconnected. And because an entry is free text rather than a structured address field, we cannot yet prove we have found every mention of a person inside it, so an erasure request is held rather than reported complete while a knowledge base is present — or while a reply written from one is still held, since deleting an entry does not delete a reply already written from it. The per-entry delete lets you act on an entry immediately. An unsent draft clears itself under the draft-retention window; a reply that was sent keeps a copy in the conversation, so that hold clears when the conversation’s content is deleted. Your DPA carries all of this in full.
The embedding endpoint is pinned and cleared separately from the drafting one. An agreement covering drafting does not cover it, and until its own provider-readiness record is in place your workspace cannot index a knowledge base at all.
Terms with the model provider — not yet executed
The agreement covering model inference is required and has not been executed — on either path. Which agreement is required depends on which model your workspace is pinned to: on our Foundry-OpenAI path the required terms are Microsoft’s; on our Foundry-Claude path, because Anthropic is an independent processor, its own separate terms are required and are not satisfied by whatever covers the Microsoft-hosted path. Each must carry no-training-on-inputs-or-outputs and a separately verified retention commitment (zero-retention preferred), together with a transfer impact assessment — and, for the Foundry-Claude path, the assessment must additionally address the Trust and Safety exceptions-only human-review disclosure above and, where the workspace’s hosting option is “Hosted on Anthropic Infrastructure,” the out-of-Azure processing location.
This is enforced, not promised: until a provider-readiness record for a given
{workspace, provider, model, region} is marked ready — which requires the signed terms
reference and the assessment reference — the workspace receives and threads mail and does
nothing else with a model: neither drafting nor classification runs, because both are model
calls. No customer mail reaches a model endpoint whose terms are not in force, on either path.
Who is not a sub-processor, and why
These are named because their absence from the list above is a decision, not an oversight.
- Microsoft 365 / Microsoft Graph — your own tenant. This is your mail system and your system of record. inxo reads and sends through it under authority you grant. Microsoft is your processor there, not our sub-processor. It follows that when you ask us to erase data, we erase our copy; the copy in your mailbox is yours to erase — with one nuance about connect-time permissions that the Data Processing Addendum states in full.
- Webhook endpoints you configure. Delivering events to a destination you chose is a disclosure back to you, not onward processing by a vendor we engaged. Every delivery attempt and every redirect it follows is validated to prevent it being pointed at internal infrastructure.
- GitHub and Azure DevOps. Source hosting and CI/CD, build-time only. No production personal data is processed there; continuous integration runs on our own hosted agents against synthetic and fixture data.
A vendor that processes data on our own behalf, not yours
This one is different from everything above, and we are naming the difference rather than letting it blur: Azure Communication Services Email, which we use to send the mail inxo sends as itself — today, the one-time code we send to verify a signup address. It is not a sub-processor to you. It never carries mailbox content and never acts on your instructions; it is a vendor in our own relationship with a person.
We are not going to lean on our payment processor as the comparison, tempting as it is: whether that one is a sub-processor to you or a vendor to our own billing relationship is a question we have recorded as still open rather than answered, and borrowing it as an example here would quietly assert the answer.
The recipient address on this path belongs to someone who is not yet, and may never become, a customer — they are in the middle of signing up. We store only a salted, one-way digest of their address ourselves; but to route mail to them at all, the plaintext address necessarily passes to Azure Communication Services, a first-party Microsoft service, for delivery. That is a real disclosure of a real person’s email address to a vendor, even though it never touches a customer’s mailbox or a customer’s data — which is why we record it here for completeness even though it sits outside the register above.
What we determined, and the one question still open
Does the model vendor whose weights serve a Foundry endpoint receive your data, or does inference happen wholly inside the Microsoft boundary? This is now answered, and the answer is it depends on which model your workspace is pinned to — both of the following are true, for the respective path:
- Foundry-OpenAI: Microsoft hosts the model itself. Per Microsoft’s own published documentation for models it sells directly, your prompts, completions and embeddings are not available to the model’s original developer, are not used to improve that developer’s models, and the model does not interact with any service that developer operates. The Azure AI Foundry entry above already covers this path, and no further sub-processor exists on it.
- Foundry-Claude: Claude models on Foundry are sold and operated by Anthropic, PBC, not Microsoft. Anthropic is an independent processor for what is sent to it, and it has its own entry above.
We did not need the model-provider terms to be executed to answer this — the determination turns on how Microsoft’s two Foundry model-sale shapes work, which Microsoft documents whether or not we have signed anything. What the terms still gate is separate and unchanged: whether any mail may be sent at all, on either path — see “Terms with the model provider” above.
Two questions are still open. The first concerns our payment processor: whether it is a sub-processor to you, or a vendor in our own billing relationship with you, is a determination we have not made — which is also why we declined to use it as the comparison above.
The second concerns automated access rather than drafting: when a customer’s own AI agent calls our API with its own credential, whose model is in that agent’s loop? If it is always ours, the entries above cover it. If a customer can point their own, unvetted model at our API, that is a different arrangement and needs to be described as one. The determination will be written down either way rather than left silent.
Changes to this register
We notify account administrators in advance of adding a sub-processor, by email and in the Console, before the new sub-processor begins processing. You may object within the stated window; if you object, you may pause the affected processing or terminate without penalty.
A change here does not block your mail pending a fresh click. Requiring you to re-accept a whole bundle of documents over a routine register update would stop a paying customer’s sends over boilerplate — a worse outcome than the rule exists to prevent, and not what the advance-notice-and-objection right asks for.