Art. 28(2), second sentence, GDPR gives the controller a right to object to any new sub-processor. The Commission’s own model text spells out what that costs: under Clause 7.7, Option 2 of Commission Implementing Decision (EU) 2021/915, the processor must give the controller express written notice of any intended change to the agreed list “at least [SPECIFY TIME PERIOD] in advance.” An assistant that picks its own tool at inference time has no lead time to give. That closes off the general-authorisation route for this kind of processing, and the contract needs a closed tool registry instead: what needs regulating is not the model, but the agent’s range of choice.

What the Clause Requires

Art. 28(2), first sentence, GDPR offers two routes: prior specific authorisation for each sub-processor, or general written authorisation for a list agreed in the contract. The European Data Protection Board has mapped out both in Guidelines 07/2020. The authorised list belongs in the contract or an annex (para. 154). Under specific authorisation, the controller’s silence counts as refusal (para. 155); under general authorisation, it counts as consent (para. 157) — the only difference between the two routes is what that silence means. The objection period has to be reasonable, measured against the nature and complexity of the processing (para. 158). For a provider running a catalogue of hundreds of tools, specific authorisation is a practical non-starter — every new integration would trigger a fresh contract negotiation. That leaves only the general route, and it requires a list that is already fixed at the moment authorisation is granted.

Footnote 54 of the same Guidelines closes the door the market has been trying to leave open. It is not enough to give the controller “a generalized access to a list of the sub-processors which might be updated from time to time”; the processor must actively notify each change. On this reading, the self-updating sub-processor page that practically every cloud and AI contract links to fails to satisfy Art. 28(2), second sentence, GDPR even for a static service.

The Circle of Recipients Is an Essential Means

Para. 40 of Guidelines 07/2020 separates essential means from non-essential means. Among the essential means reserved to the controller, the Board explicitly lists “the categories of recipients (‘who shall have access to them?’).” The circle of recipients is decided not by the model’s weights but by the tool registry. Whoever configures the range of choice determines an essential means; whoever leaves it open hands that determination to the processor.

An example makes the mechanics concrete. A support agent with access to forty connected tool servers independently picks a new translation service for a customer query because its description best fits the task. The operator of that service was not on the list the controller had authorised, and there was no chance to object, because the choice was only made at runtime. This is exactly the case Art. 28(10) GDPR addresses: a processor that determines the purposes and means of processing on its own, in breach of the Regulation, “shall be considered to be a controller in respect of that processing” — with its own accountability obligations that the original contract never provided for.

The fine bracket here is different from what market chatter suggests. Breaches of Art. 28 fall, under Art. 83(4)(a) GDPR, into the lower bracket of EUR 10 million or 2 percent of total worldwide annual turnover for the preceding financial year. The doubled rate under Art. 83(5)(a) only kicks in once no legal basis under Art. 6 GDPR still covers the disclosure to the tool the agent chose.

What Belongs in the Annex

A provider that takes Art. 28(2) GDPR seriously doesn’t just copy the clause out — it rebuilds it. The processing annex doesn’t list categories such as “translation services” or “search tools”; it lists individual operators by name, location, and purpose, which para. 31 of Opinion 22/2024 requires for the whole sub-processor chain anyway. Every extension of that list triggers the notice period under Clause 7.7, Option 2 — not a silent update to a web page. The agent’s technical approval space — the set of tools it is even allowed to invoke at runtime — is constrained in software to exactly that list: deny-by-default rather than allow-by-default. The difference from a standard subprocessor page is not a formality: it decides whether the provider keeps control over the circle of recipients or hands it over to the model.

The Protocol Knows the Notice, Not the Addressee

The MCP specification explicitly describes tools as “model-controlled”: the language model discovers and invokes them on its own. For the case where the tool list changes, the protocol even has its own notification, notifications/tools/list_changed. It goes to the client. Art. 28(2), second sentence, GDPR requires that it go to the controller, with notice. The final version of the specification, published on 28 July 2026, makes the drift even more visible: tools/list responses now carry ttlMs and cacheScope, modelled on the HTTP Cache-Control header, so clients know “how long a tools/list response is fresh” — and a persistent SSE stream is no longer the only way to learn that the list has changed at all. The protocol is built for ongoing, unpredictable changes to the tool list. Art. 28(2) GDPR is built for a list fixed at the time the contract is signed. Both architectures are internally consistent; they just don’t fit together.

A generously worded general authorisation doesn’t fix this, because the chain breaks somewhere else. Art. 28(4) GDPR requires that the further processor be bound “by way of a contract or other legal act” to the same data protection obligations; para. 160 of the Guidelines says it without hedging: “The whole chain of processing activities needs to be regulated by written agreements.” An endpoint the agent reaches with an OAuth token has terms of use. It does not have a contract under Art. 28(4). Under the last sentence of that same provision, the first processor is also liable to the controller for the further processor’s failure to fulfil its obligations — a liability no provider will accept for an endpoint it never chose.

What an Access Request Costs

On 12 January 2023, in Case C-154/21 (RW v Österreichische Post AG), the CJEU held that the controller must disclose the identity of recipients. It may fall back on categories only if “it is impossible to identify the recipients,” or if the request is manifestly unfounded or excessive within the meaning of Art. 12(5) GDPR. That impossibility is not a property of the technology — it is a consequence of how the system is configured. The Board already drew this connection in para. 31 of its Opinion 22/2024: the identity of all processors and sub-processors must be “readily available at all times” to the controller, not least so it can answer access requests under Art. 15 GDPR without undue delay.

So next week’s task isn’t the contract. Log every tool call with the tool identifier, the operator, and its link to the data subject, and tie the retention period of that log to the deadline in Art. 12(3) GDPR: one month, extendable by up to two further months. The contract annex comes after that, with name, address, and point of contact for each operator (para. 31), and the technical allowlist is set to deny-by-default and kept in lockstep with the annex. Anyone who tackles these three steps in the wrong order — annex first, logging second — will find out, at the latest when the first access request lands, that they’ve contractually named the recipients but can’t technically reconstruct which one actually processed which request.

The Swiss Layer

Art. 9(3) FADP permits onward transfer only with the controller’s prior authorisation; the FDPIC accepts a general authorisation for this too, paired with a duty to inform and a right to object. The harder bar sits two paragraphs up. Art. 9(1)(b) FADP allows outsourced processing only where no statutory or contractual duty of confidentiality bars the transfer — for a bank under Art. 47 BankG, or a law firm under Art. 321 StGB, this is not a balancing test but a condition of permissibility. An open-ended tool space makes that check impossible: if you don’t know where the data is going, you cannot determine whether a duty of confidentiality stands in the way of the transfer. And the check itself cannot be done retroactively — it has to happen before the transfer, not after, because a breach of Art. 47 BankG or Art. 321 StGB that has already occurred cannot be cured by a later fix to the contract.

What’s Settled, What’s Open

What’s settled is that Art. 28(2) and (4) GDPR require a named list and a chain that is documented in writing all the way through, and that paras. 154 to 160 of Guidelines 07/2020 and para. 27 of Opinion 22/2024 describe what both look like: approval before onboarding, not notice afterward. What’s open is whether a supervisory authority will accept a technically configurable allowlist as an “agreed list” within the meaning of Clause 7.7, Option 2, and whether it will read runtime tool selection as determining an essential means under Art. 28(10) GDPR. The first question will be answered sooner than contract templates suggest. The Board’s coordinated enforcement action, launched on 19 March 2026 with 25 supervisory authorities taking part, covers the transparency and information duties under Art. 12, 13, and 14 GDPR — and with them, the recipient disclosure required under Art. 13(1)(e). The authorities will pool their findings in the second half of 2026; the consolidated report then goes to the Board for adoption. Anyone still answering with “categories of recipients” by then should know that this exact answer is currently under scrutiny in 25 countries.