Does it matter which AI client a compliance team picks if they all speak MCP?

Less than vendors imply, and more than the spec sheet shows. Any client that implements the Model Context Protocol with OAuth can connect to the Ansvar gateway and call the same tools — search, get_provision, the workflow engine — and get the same cited answers, because the grounding happens server-side. What differs is the surrounding posture: whether the client supports OAuth 2.1 cleanly or wants a static token in a config file, whether your admin can govern which servers a user connects, and whether the vendor trains on your prompts. The model answers; the client decides who else sees the question.

Which clients does the Ansvar gateway work with today?

Any MCP client that supports remote servers over OAuth. That includes Claude Desktop and Claude Code, VS Code's Copilot agent mode, Microsoft Copilot Studio, and Cursor. The gateway is a single OAuth 2.1 MCP endpoint at gateway.ansvar.eu, so connecting is a two-minute setup regardless of client — point it at the endpoint, complete the OAuth flow, and the tools appear. We are vendor-neutral on the client by design: the value is in the cited corpora and deterministic validation behind the gateway, not in any one app's chat window.

What are the two non-negotiable requirements when picking a client?

OAuth-based MCP and a no-training guarantee on your data. OAuth means access is scoped, revocable, and tied to an identity your admin controls — not a long-lived API key pasted into a JSON file that leaks the day someone commits it. A no-training guarantee means the vendor will not use your prompts or the regulatory questions you ask to improve a model that competes with you or exposes your posture. Everything else — UI polish, IDE integration, agent autonomy — is a preference. Those two are requirements, because a compliance team's questions are themselves sensitive.

Where does the data actually go when we run a workflow?

Your prompt goes to whichever model your chosen client runs — Anthropic for Claude, the model behind Copilot or Cursor for those. The regulatory grounding goes to the Ansvar gateway, hosted in the EU on Hetzner, which returns cited provisions from the law and framework corpora. The gateway holds no server-side model and stores no client documents beyond a workflow's lifetime. So the model vendor sees your question; Ansvar sees the regulatory lookups. Read your client vendor's data-processing terms for the first half — that is the half this article is about.

Choosing an MCP client for a compliance team: Claude, Copilot, Cursor

A compliance officer evaluating AI tooling gets pitched the model. Claude is good at reasoning, Copilot is in everyone's IDE already, Cursor writes code fast. All true, and almost beside the point for the decision in front of you. If the plan is to put an AI client in front of a regulatory-intelligence gateway and have it run gap analyses, DPIAs, and threat models, the model is the part you change least often. The client — the app that holds the OAuth token, talks to your admin's identity provider, and ships your prompts somewhere — is the part that decides whether the arrangement survives your own data protection review.

We work with all of them. The Ansvar gateway is a single OAuth 2.1 MCP endpoint, and Claude, Copilot, and Cursor all reach it and get the same cited answers, because the grounding happens on our side. So this is not a "buy our client" piece — we do not sell one. It is the comparison we would run if we were the compliance team doing the procurement, opinionated on the two requirements that actually matter and neutral on the rest.

The two requirements, before the feature grid#

Start with what is non-negotiable, because it collapses the choice faster than any feature matrix.

OAuth-based MCP, not a token in a config file. The Model Context Protocol can authenticate two ways in practice: a proper OAuth flow, where the client redirects the user to log in, gets a scoped and revocable token tied to an identity, and refreshes it; or a static secret pasted into a JSON config. The second is the same anti-pattern as a long-lived API key, and it fails the same way — it ends up in a dotfile, a screenshot, a committed .mcp.json, a synced settings backup. For a tool that can read your regulatory posture and your uploaded documents, a static token is a standing finding waiting to be written up. Insist on OAuth.

No training on your data. A compliance team's prompts are sensitive in a way that is easy to miss. The questions you ask — "does this vendor arrangement trigger a DPIA," "are we late on a breach notification," "which of these CVEs is exploitable on the payments path" — describe your weak points. If the client vendor trains on prompts, those questions become training signal. You want a contractual no-training guarantee on inputs and outputs, in the data-processing terms, not a blog promise. This is the same accountability logic the GDPR builds in: under Article 5 GDPR a controller has to be able to demonstrate compliance, and you cannot demonstrate control over data you have handed to a model trainer on default terms.

Everything below is downstream of those two. A client that nails OAuth MCP and gives you a no-training enterprise tier is a candidate. One that wants a static token or trains on your prompts by default is not, however good the model is.

Claude — Desktop and Code#

Claude ships in two shapes a compliance team will care about: Claude Desktop, the chat app, and Claude Code, the terminal/agent client engineers live in. Both are first-class MCP clients with real OAuth support for remote servers. Connecting to the gateway is the canonical two-minute flow — add the remote server, complete the OAuth redirect, and the gateway's tools appear in the tool list. No static token, no manual header juggling.

For enterprise controls, the relevant surface is the Anthropic enterprise/Team plans and the admin features around them: SSO, user management, and — the one that matters here — the data-handling commitment. Anthropic's commercial terms do not train on your inputs or outputs by default. That is the posture you want stated, and you should still read your own contract, but the default is the right way round.

Where Claude fits: teams that want the strongest reasoning on the workflow itself — walking a STRIDE or LINDDUN threat model, reading a tender, drafting a gap analysis — and that are comfortable with a dedicated AI client rather than living inside an IDE. Claude Code in particular is a strong fit for the engineer who is also doing the compliance plumbing, because it can drive the gateway and edit the repo in the same session. The model's willingness to refuse rather than confabulate also pairs well with the gateway's refusal discipline — a question it cannot ground comes back as "unresolved," not invented.

VS Code Copilot agent mode#

GitHub Copilot's agent mode in VS Code is an MCP client, and for a lot of engineering-heavy compliance teams it is the path of least resistance — the editor is already open, the seats are already bought. It supports remote MCP servers, and recent versions handle the OAuth flow for them rather than forcing a static token, which clears the first requirement.

The enterprise-controls story here is genuinely good, because it rides on the GitHub/Microsoft enterprise machinery your org may already run: organization policy over which features are enabled, audit surfaces, and — the control specific to MCP — the ability for an admin to govern which MCP servers users may connect, rather than leaving it to each developer's local config. That governance layer is the thing a CISO asks for and most consumer chat apps do not have. If you already manage GitHub at the org level, Copilot agent mode lets you treat MCP server access as one more thing policy decides.

The data posture is the part to read carefully, because Copilot has consumer and business/enterprise tiers with different commitments. The business and enterprise tiers carry a no-training-on-your-content commitment; the free/consumer tier does not give you the same guarantee. For a compliance team, that means the requirement is not "use Copilot" but "use Copilot Business or Enterprise, with the no-training term confirmed in your agreement." On the right tier it qualifies; on the wrong tier it fails the second requirement.

Where it fits: engineering orgs standardized on GitHub Enterprise who want compliance workflows to live where the code does, with MCP server access governed centrally.

Copilot Studio#

Microsoft Copilot Studio is a different animal — it is the low-code agent-builder, not a chat client. You use it to build an agent (a "copilot") that your non-technical colleagues then talk to, and that agent can call MCP servers as tools. For a compliance team this is the option that turns the gateway into something a procurement officer or a privacy analyst uses without ever seeing a tool call.

Its MCP support has matured to where you can register a remote server and have the studio-built agent call it. OAuth is supported through the connector/authentication configuration, so you are not stuffing a static secret into the agent definition. The trade is that you are now operating inside the Power Platform governance model — environments, data-loss-prevention policies, connector governance — which is heavyweight but, for a regulated enterprise, often exactly the control surface you are required to have anyway. Admins can constrain which connectors and which MCP servers an agent may use, and that lines up with how a compliance function wants to deploy a shared tool.

Data posture follows the Microsoft enterprise commitments for the tenant the agent runs in, which for business tenants includes the no-training-on-your-data stance. As with Copilot in VS Code, confirm it against your tenant's agreement rather than the marketing tier.

Where it fits: a compliance function that wants to publish a governed, self-serve agent to colleagues — "ask the compliance copilot whether this needs a DPIA" — and is already inside the Microsoft 365 / Power Platform world. The build cost is higher; the distribution to non-technical users is the payoff.

Cursor#

Cursor is the AI-first code editor, and it is a capable MCP client with OAuth support for remote servers. For a compliance team it sits in the same slot as Copilot agent mode — engineer-facing, IDE-resident — with a more aggressive agentic posture out of the box.

Two things to weigh. First, model choice: Cursor lets you route to several underlying models, which is flexible but means your no-training guarantee depends on which model and which Cursor plan you are on, not on "Cursor" as a monolith. You have to pin the data commitment to the specific configuration, and Cursor's business/enterprise plan with a zero-data-retention or no-training mode is the configuration that clears the bar. Second, enterprise governance over MCP servers is less mature than the GitHub/Microsoft org-policy machinery — it is improving, but if central control over which servers users connect is a hard requirement, verify it for your version rather than assuming it.

Where it fits: engineering-led teams who want the most autonomous agent loop and are willing to do the configuration work to lock down the data posture explicitly. The capability is there; the governance is more on you.

The part the client does not change#

Here is the load-bearing point, and the reason we can be neutral on the client. The regulatory grounding does not live in any of these apps. It lives in the gateway. When the agent — whichever one — asks "what does DORA require of an ICT third-party contract," it calls search and get_provision against the corpora, and the answer comes back as a structured provision with a stable identifier and a validated citation. The DPIA trigger resolves to Article 35 GDPR because the gateway read it, not because the model recalled it. The 72-hour breach-notification clock in Article 33 GDPR, the records-of-processing duty in Article 30 GDPR, the ICT third-party contractual requirements in Article 28 DORA — each comes back from the corpus, deterministically validated, identical no matter which client window the question was typed into.

That is the design property worth paying for: cited answers instead of a confident guess. The client you pick changes who sees your prompt and how your admin governs the connection. It does not change whether the citation is real. So you can choose the client on the two requirements and the fit notes above, and trust that the compliance substance — the coverage across 28 audited law jurisdictions, 262 security frameworks, and the EU regulations corpus — is constant.

text

Your client (Claude / Copilot / Cursor)
  │  OAuth 2.1 (no static token)
  ▼
gateway.ansvar.eu  ── EU-hosted, no server-side model
  │  search / get_provision / workflow engine
  ▼
28 audited law jurisdictions · 262 frameworks · 102 EU-regulation instruments
  → structured provisions · validated citations · refusal on the ungroundable

A short procurement checklist#

If you are running the evaluation, these are the questions that decide it, in order:

Does the client support remote MCP servers over OAuth? If it wants a static token in a config file, stop. Claude, Copilot agent mode, Copilot Studio, and Cursor all clear this on current versions.
What does the data-processing agreement say about training on your inputs and outputs? Pin it to the specific plan and tier, not the brand. Several of these clients pass on business/enterprise tiers and fail on consumer tiers.
Can your admin govern which MCP servers users connect? This separates the GitHub/Microsoft enterprise options from the consumer chat apps. If central control is a requirement, the org-policy clients win it.
Where does each hop go? Model vendor sees the prompt; the gateway, EU-hosted with no server-side model, sees the regulatory lookups. Map both against your data-residency and sub-processor obligations.
Does it actually run the workflow you need? Connect a free-tier gateway account (100 searches a day, no card) and run one real gap analysis or AI Act readiness check end to end before you commit a seat budget.

How we would call it#

For an engineering-led team already on GitHub Enterprise, VS Code Copilot agent mode on a business tier is the least-friction qualifying option — the governance is there and the editor is already open. For a compliance function that wants a governed self-serve agent for non-technical colleagues, Copilot Studio inside an existing Microsoft 365 tenant is the one that distributes. For the strongest reasoning on the workflow itself and the cleanest default data posture, Claude — Desktop for analysts, Code for the engineer-compliance hybrid. Cursor for teams who want the most autonomous loop and will do the configuration to lock the data commitment down.

None of those is a wrong answer. All four speak OAuth MCP, all four can be put on a no-training tier, and all four reach the same cited corpora through the gateway. Pick on your two requirements and your org's existing rails, connect it to the gateway, and run one real workflow before you decide. The model is the part you will change least; the client is the part your data protection review will read most closely. Choose it like the compliance decision it is.