Map your subprocessors for procurement

Why this matters

Customers and procurement teams ask the same question on every contract cycle: list the subprocessors that touch our data. When you use Auxot, the answer is not “Auxot.” The answer is the providers downstream of Auxot: the cloud model vendor (OpenAI, Anthropic, etc.), the GPU host you run on, the MCP servers you wired, the OAuth integrations you authorized. Every one of those is a subprocessor from your customer’s point of view, and every one needs to land in their questionnaire.

The temptation is to skip the row or write “we use various AI providers” and hope nobody pushes back. Procurement teams push back. Modern DPAs require named subprocessors before they sign, and “various” extends the sales cycle by a week or kills the deal outright.

Auxot already centralizes the answer. Settings → Providers shows your providers (cloud + GPU + CLI). Settings → MCP servers shows the connectors that reach external systems. Settings → Credentials shows what you have authenticated to. The work is reading those pages once, naming the data categories that flow to each, and saving the list somewhere your sales lead and security lead can both find.

This one inventory feeds your customer-facing /trust page, your vendor questionnaires (Answer vendor security questionnaires from your own evidence), and your cyber insurance renewal. One source. One version per quarter. No guessing.

Nothing assembles itself: you read Settings, you name what flows where, you version the list.

Quick start

1. Open Settings → Providers: every connected provider (cloud, GPU, CLI) becomes one inventory row.
2. Open Settings → MCP servers: every connector that reaches external systems (CRM, Slack, GitHub, etc.) becomes a row.
3. Add Credentials providers: any OAuth or API-key integration that ships data out belongs on the list (Manage your Credentials).
4. Name the data categories per row: what content actually flows there (customer-support transcripts, sales emails, internal docs, code, PII). “Various” does not pass procurement.
5. Mark region and DPA status: where the vendor processes data, and whether you have a signed Data Processing Agreement on file. unknown is honest if you do not know yet.

Done? A markdown table (or context file, or wiki page) that answers “list your subprocessors” without scheduling a call. Include Inventory date: YYYY-MM-DD so the next refresh sits clearly against the last one.

The agent can do that?

1. Draft the inventory from a Settings export

Chat → Admin Agent:

Here are the provider names I see in Settings → Providers and Settings → MCP servers: [paste list]. Draft a subprocessor inventory table with columns: vendor name, data categories sent, region, DPA on file (yes / no / unknown), evidence pointer. Mark anything you cannot determine as `unknown`; do not guess.

Why it’s non-obvious: Pasted names beat memory. The agent maps each one to the canonical column shape; you fill data categories and DPA status against your actual contracts.

2. Flag rows missing DPA evidence

After the draft exists, paste it back:

Inventory draft: [paste]. List every row where DPA status is `unknown` or `no`. For each, suggest one specific evidence source I should check (vendor's trust page, our contracts repo, the procurement ticket where we signed) so the gap closes before the next customer asks.

Why it’s non-obvious: Procurement teams treat unknown as a deal-blocker. Naming the source to chase converts the gap into a 30-minute task instead of a vague worry.

3. Explain the list to a non-technical reviewer

Inventory: [paste]. Write one sentence per row that explains, in plain English, why this vendor is on the list and what they do with our data. Audience: a board member or a salesperson who needs to defend the list in a customer call.

Why it’s non-obvious: Procurement readers search the table; executives need the narrative. One-sentence explanations let the same inventory serve both audiences without two documents going out of sync.

Go deeper

What counts as a subprocessor

A subprocessor is any third party that processes your customers’ data on your behalf. In Auxot:

• Model providers (OpenAI, Anthropic, etc.): every prompt your agents send leaves your building. They are subprocessors.
• GPU hosts: if you run a worker on a cloud VM, the cloud vendor is a subprocessor of the workload that touches customer data on that machine.
• MCP servers: any external system the agent calls (Slack, GitHub, your CRM). Those vendors are already subprocessors of your business; the MCP wiring makes them subprocessors of the agent workflow too.
• OAuth integrations: same logic. Authorization scope tells you what data they can read; that determines categories on the row.

What is not a subprocessor: your own internal infrastructure (your VPC, your own database). Your hosting provider for that infrastructure might be, depending on what runs there.

Versioning cadence

Quarterly minimum. Plus a refresh whenever you connect a new provider or wire a new MCP server. The inventory date at the top is the contract: customers reading a six-month-old list are reading stale evidence.

Owner change

This inventory has a clear owner whether or not you’ve named one, and when that person leaves, the next person needs to know which rows were unknown on purpose vs forgotten. Hand off the audit narrative when your compliance lead changes covers the same handoff motion for the broader audit story; the subprocessor inventory belongs in that same handoff packet.

DPA reality

You will not always have a signed DPA with every vendor on day one. Mark unknown honestly, route the gap to legal, and revisit. Procurement respects a dated gap with an owner more than confident silence.

Region / data residency

Cloud providers list their regions in their docs. Pin the region you actually use, not the company headquarters. “US” is not enough when a customer asks about EU residency.

Troubleshooting

• A vendor on the list has no listed DPA template. Some small vendors do not publish one. Document the gap, escalate to legal, and decide whether you can use them at all for regulated data. Some you cannot.
• Same vendor appears twice (e.g. one cloud account for dev, one for prod). Treat them as one row unless data categories differ; note both accounts in the evidence column.
• You inherited an inventory and cannot find the dates. Mark it last reviewed: unknown and refresh from current Settings. Honesty beats inherited fiction.
• An MCP server is wired but nobody remembers what it does. Open it in Settings, read its description, and check audit logs (View your audit logs) for what it has actually been touched for in the last 30 days. If the answer is “nothing,” remove it before listing it.

Variations & edge cases

• Free tier and self-hosted both apply: the inventory work is the same; only the hosting row differs (cloud Auxot vs your own infrastructure).
• Multi-team setups (Business+): each team’s providers can be scoped separately (Set up multi-team isolation). The inventory should still be org-wide for procurement; note which team uses which subprocessor in an extra column.
• The inventory is shorter than you expected: good. A short, accurate list passes review faster than a padded one.
• The inventory is longer than you expected: worth a separate look at whether every connector still earns its keep (Replace an agent currently in use, Audit and clean up your agents).

Walkthrough

Step 1: Read Settings → Providers

Open Settings → Providers in Auxot. For each row:

• Vendor name: the company that runs the model (OpenAI, Anthropic, Mistral, etc.). Not Auxot; Auxot is the routing layer, not the subprocessor.
• Type: cloud model / GPU host / CLI provider. Useful context for the row.

If you run a GPU worker on a cloud VM, the cloud vendor that hosts the VM is the subprocessor for that row, not Auxot.

Step 2: Read Settings → MCP servers

Each MCP server is a connector to an external system. For each:

• Vendor name: the SaaS or platform behind the connector (Salesforce, Slack, GitHub, etc.).
• Authorization scope: what the connector can read or write. This determines the data categories on the row.

Step 3: Add Credentials integrations

Settings → Credentials shows the OAuth providers and API keys you have authenticated to. Anything not already covered by Providers or MCP servers goes on the list.

Step 4: Draft data categories per row

For each row, write what actually flows there. Be specific:

• “Customer-support transcripts (free text, may include PII)”
• “Outbound sales emails (no PII)”
• “Public-facing marketing copy”
• “Source code commits and diffs”

If you are not sure what flows, check Audit Logs (View your audit logs): the Threads and Jobs tabs show what has actually been sent in the last 30 days.

Step 5: Mark DPA status and region

Three values: yes (signed DPA on file), no (you do not have one yet), unknown (need to check). Same three values for region: pin the specific region (us-east-1, eu-west-3), not the country.

Step 6: Save versioned and link to the questionnaire workflow

Save the inventory as a context file (Add your first context file) titled Subprocessor inventory - YYYY-MM-DD. Attach it to the agent you use for security questionnaires (Answer vendor security questionnaires from your own evidence) so the same source feeds every answer.

When you refresh quarterly, save a new dated file and archive the old one. The audit trail matters for SOC 2 walkthroughs.

What’s next

• → Answer vendor security questionnaires from your own evidence. The inventory you built here is the source the questionnaire agent reads from.
• → Hand off the audit narrative when your compliance lead changes. The subprocessor inventory belongs in the same handoff packet as the audit narrative; both need to survive an ownership change without losing the why behind each row.
• → Run a data privacy review before you ship. Subprocessor inventory feeds DPIA-style reviews on the same evidence.
• → Plan for retention and deletion requests. Customer deletion requests fan out to every subprocessor; the inventory tells you who to notify.
• → View your audit logs. Confirm what is actually flowing to each subprocessor matches what the inventory claims.
• → Add your first context file. Where the inventory lives so agents read the current version.
• → Add an MCP server. Every new MCP wiring is a new inventory row; revisit the list when you connect one.

Reference

• Pages in Auxot: Settings → Providers, Settings → MCP servers, Settings → Credentials, Audit Logs
• Inventory columns: vendor name, data categories sent, region, DPA status (yes / no / unknown), evidence pointer
• Refresh cadence: quarterly minimum, plus on every new provider or MCP connection
• Inventory date format: Inventory date: YYYY-MM-DD at top of the file
• See also: Answer vendor security questionnaires from your own evidence, Run a data privacy review before you ship, Plan for retention and deletion requests, View your audit logs, Manage your Credentials, Add your first context file