Before you adopt an agent-orchestration platform such as Amazon Bedrock Agents, on its own or combined with a third-party SDK, you need a data-flow map that names every downstream LLM sub-processor in both the primary and the failover path, and each vendor’s data processing addendum (DPA) and current sub-processor list to back it. The European Data Protection Board (EDPB) expects controllers to have the name, address and contact person of every processor and sub-processor in the chain readily available at all times, not just the first tier. These facts come from contracts and architecture documents, and no amount of runtime benchmarking will surface them.
TechnoLynx, through its AI Governance and Trust work, builds this kind of map as an engineering artefact. That means tracing which providers each agent configuration can actually reach and packaging the evidence a compliance owner can read and sign against, without giving legal advice or certification.
Who are the named sub-processors behind Bedrock Agents and the SDK on top?
AWS publishes its sub-processors under the AWS DPA, and which of them apply to you depends on the AWS Region you select and the services you use. The list covers four kinds of entity: AWS entities running the infrastructure, AWS entities supporting specific services, third parties AWS has contracted for specific services, and entities supporting the AWS European Sovereign Cloud.
The model developer does not see your Bedrock traffic. Bedrock runs a separate model deployment account per model provider in each Region, owned and operated by the Bedrock service team, and providers have no access to those accounts, the service logs, or customer prompts and completions. AWS states that Bedrock does not share prompts or model outputs with model providers. On the pure Bedrock path, then, AWS operates the inference service, whichever company trained the model.
With custom orchestration, a Lambda function you write decides when the agent invokes the model, when it calls action tools and what the final response is. The AWS page lists only sub-processors AWS has engaged. Anything outside AWS that this Lambda calls is therefore yours to map.
An SDK vendor such as LangChain engages its own sub-processors. LangChain’s customer DPA, for example, grants general prior authorisation for the sub-processors listed in its Annex III and published on its trust site. Those are processors engaged by LangChain itself.
When you call a provider directly, its own list applies. OpenAI’s sub-processor list names each entity, the products it supports and its processing location, along with the transfer mechanism used among affiliates. Anthropic’s DPA is incorporated automatically into its Commercial Terms of Service, but when you reach Claude through a third-party platform, that platform’s terms govern your use. The same model can sit behind two different contractual chains depending on the route.
One platform, four chains: a published example
Cap Orbit, a software vendor, publishes a sub-processor list that shows how much the chain depends on configuration. For sessions on Amazon Bedrock, AWS is the sub-processor for every Bedrock model, including those developed by Anthropic, OpenAI and xAI. Anthropic becomes a sub-processor only when the customer’s configuration uses Claude Platform instead of Bedrock, and that processing sits outside the Bedrock service boundary. Where a customer supplies its own API keys, the provider processes data under the customer’s own agreement. In a customer-controlled deployment, the infrastructure provider is not a Cap Orbit sub-processor for that processing, though an AI provider Cap Orbit engages stays on its list. The practical consequence is that a sub-processor map is drawn per configuration, never per product.
How far down the chain the identification has to go
EDPB Opinion 22/2024 answers the depth question: you identify the whole chain. In that Opinion, “identify” means the name, address and contact person (name, position, contact details) of each processor, plus a description of the processing and a clear split of responsibilities where several sub-processors are involved. The processor should proactively give the controller this information for every processor and sub-processor working on its behalf, and keep it up to date at all times. Before you authorise a new sub-processor, the EDPB expects a list of intended sub-processors showing their locations, what each will do and proof of the safeguards in place.
The decision stays with you. The initial processor should propose sub-processors with sufficient guarantees, but the ultimate decision to engage one, and the responsibility for checking its guarantees, remains with the controller.
Labels in the contract do not settle anyone’s role. EDPB Guidelines 07/2020 treat controller and processor as functional concepts, determined by what each party actually does, not by what a contract calls it. An entity called a “subcontractor” in a commercial contract is not a processor for that reason alone. If a provider in your path uses prompts for purposes of its own, the map has to record that party as something other than a processor acting on your instructions.
Why failover and fallback routes belong on the sub-processor map
Failover routes send the same prompt to a different provider or Region, usually without anyone deciding to at the moment the request is made. A map that shows only the primary provider therefore misses exactly the hops that run when something has gone wrong.
LiteLLM shows the mechanism clearly. When a call fails after its configured retries, LiteLLM falls back to another model group, so a failing model or provider fails over automatically to a backup. Fallbacks run in the configured order. There are separate fallback types for content-policy violations, context-window overflows and all other errors such as rate limits. So a content-policy violation or an over-long prompt can trigger a fallback, not just an outage. A default_fallbacks setting can send any failing model group to a model on another provider entirely: LiteLLM’s own example falls back from an Azure deployment to a Claude model called with an Anthropic API key.
Bedrock has a quieter version of the same thing. Cross-region inference routes traffic across multiple Regions, and AWS advises customers with strict residency or compliance requirements to check whether the feature fits their policies. Geographic inference profiles keep requests within a geography such as the US or EU. If your organisation blocks unused Regions with Service Control Policies, you must allow every destination Region in the profile or add an exception. The inference profile documentation lists every destination Region for your source Region. The map should record each one as a named processing location rather than “EU” as a single entry.
The EDPB makes the same link from the other side. It notes that controllers need chain information in case one sub-processor becomes unreachable, unwilling or insolvent and another has to be contacted.
One gap remains. For SDKs that route dynamically at request time, a static list only holds if the vendor commits contractually to the set of providers the router can reach.
Can we get a DPA that names every downstream LLM provider, including failover?
Partly. The AWS and LangChain DPAs each point to a list of that vendor’s own sub-processors. Providers you reach with your own keys sit under your own agreements with them, as Cap Orbit’s list states for customer-supplied Anthropic, OpenAI and xAI keys. For those hops, you hold the agreement directly.
The notice mechanics differ between vendors, as the table shows:
| Vendor document | Authorisation model | Notice before a new sub-processor | How you object |
|---|---|---|---|
| AWS DPA | General authorisation; list on the AWS website | At least 30 days, with a mechanism to get notice of the update | Terminate, stop using the affected service, or move the data to a Region where that sub-processor is not engaged |
| LangChain DPA | General prior authorisation; Annex III list | At least seven days, if you subscribe to updates | Written objection within seven days, on reasonable data-protection grounds |
| Cap Orbit sub-processor list | Changes announced on the list | At least ten business days, to subscribed customers | As set out in its DPA |
A notice mechanism needs one test applied to it. EDPB Guidelines 07/2020 state that general access to a sub-processor list that is updated from time to time is not enough: the processor must actively point to each new sub-processor it intends to engage. Every vendor in the table ties notice to a subscription, so subscribing, and checking that the notice names the new entity, is part of the adoption work.
Ask each candidate vendor for a signed DPA and a sub-processor list. If a vendor cannot name every sub-processor it engages in both the primary and failover paths, treat the platform as unready for regulated workloads until it can, or choose a platform that discloses fully.
Data processing agreement or data processing addendum: what actually differs
In everyday use the two terms mean the same thing, a contract satisfying GDPR Article 28(3), and neither term appears in the regulation. The difference is structural; it changes precedence, unilateral change, liability and what happens to data at the end.
Precedence. An addendum sits inside the parent agreement’s order-of-precedence clause, so check that the data protection terms win over conflicting commercial terms. LangChain’s DPA, for instance, states that it prevails over the main agreement on matters concerning personal data processing.
Terms that move. An addendum incorporated by reference to a web page can change when the supplier updates the page, so the terms binding you are whatever sits at that URL. The AWS DPA points to its sub-processor list at a URL it describes as where the list is “currently posted”. Anthropic’s DPA is accepted automatically along with its Commercial Terms. The operational duty is yours: capture the version you accepted, with a date, and notice when it changes. EDPB Guidelines 07/2020 add that a processor’s proposed change to processing terms in standard conditions should be notified directly to the controller and approved.
Content. Article 28(3) sets the required content and is silent on structure. The UK ICO lists the minimum terms as processing only on documented instructions, confidentiality, security, sub-processor conditions, data subject rights, assistance, end-of-contract provisions, and audits. The sub-processor conditions include prior authorisation, notice of intended changes with a chance to object, equivalent obligations flowed down, and the processor’s liability for the sub-processor.
Data flow mapping for an agent platform: what the map has to show
The ICO describes a data flow mapping exercise as documenting the data that flows into, around and out of information systems or services. Your record of processing activities (ROPA) is informed by that mapping, and for each processing activity it records the recipients of shared information, along with safeguards or adequacy decisions for international transfers. For an agent platform, every LLM provider, Region, SDK vendor and tool endpoint is a recipient, so the map feeds the ROPA directly.
The map is not lineage. Atlan’s comparison puts it this way: data lineage tracks the history and transformation of specific data elements for impact analysis and troubleshooting, while data flow diagrams give a system-level view of how data moves. The sub-processor map is the system-level view; lineage of individual prompts and outputs is the separate record you reach for in root-cause work.
Checklist: one row per hop, before compliance review
- Entity name, address and named contact for the party processing at this hop.
- What this hop does with the data, and where its responsibility ends and the next hop’s begins.
- Processing location, including every destination Region of any cross-region profile.
- Transfer mechanism where data leaves the EEA, backed by transfer mapping documentation from the exporter.
- Path type: primary, ordered fallback, default fallback, content-policy or context-window fallback, or cross-region route.
- Contractual instrument covering the hop, with the version you accepted and its date.
- Notice window and objection route for changes to the hop’s sub-processors.
- The log field that proves this hop served a given request.
Review it on a schedule. The ICO’s guidance is to repeat the information audit and review the flow map regularly to capture changes.
When an agent incident happens, the named chain says who answers
A named sub-processor map turns “something went wrong in the agent” into a specific party with a specific contractual duty. Processors have a direct GDPR duty to notify the controller without undue delay after becoming aware of a personal data breach, and that includes breaches affecting a sub-processor’s systems, along with helping the controller gather what the supervisory authority report needs. Your processor contracts must require that assistance. Where a breach is likely to put individuals at risk, the controller notifies its data protection authority within 72 hours of becoming aware of it. The EDPB ties ready access to chain identities partly to reacting quickly to breaches along the processing chain.
Liability follows the chain you mapped. Under Article 28(4), when a sub-processor fails its obligations, the initial processor remains fully liable to the controller. The AWS DPA makes a narrower commitment: AWS stays responsible for sub-processor acts or omissions that cause it to breach its DPA obligations.
Runtime logs show which hop served a given request. LiteLLM writes attempted_fallbacks and original_model_group into each spend log row, so a request for one model that was served by a fallback on another provider stays distinguishable afterwards. For Bedrock cross-region inference, AWS points to CloudTrail logs to check whether a request was re-routed to another Region. A log line naming a model group is not, on its own, a contracted entity; the map is what translates it into a party with a DPA and a notification duty.
The map also feeds the wider procurement evidence pack security reviewers ask for, which is a broader job than this checklist.
Who can build the sub-processor map and evidence pack for our agent platform?
TechnoLynx builds the engineering evidence behind adoption decisions like this one: the traceability of which providers an agent configuration and its fallback rules can reach, and the governance pack a compliance owner or model-risk committee can defend. TechnoLynx delivers that work through its AI Governance and Trust offer. Where the orchestration layer is still being designed, that build sits with TechnoLynx’s generative and agentic AI R&D work.
TechnoLynx’s part has clear limits. Reviewing and negotiating DPA terms, judging whether a transfer mechanism is adequate, and signing off compliance belong to your counsel and DPO; TechnoLynx produces the artefacts that review needs, not the legal opinion or a certification. If your platform uses a single provider with no fallbacks and no custom orchestration, the vendor’s trust-centre list and your own ROPA process may well be enough without outside help.
FAQ
Can I use Claude on Amazon Bedrock?
Yes. Models developed by Anthropic are offered through Bedrock, and on that path AWS operates the inference service. Anthropic states that when you access Claude through a third-party platform, that platform’s terms govern your use.
What is an Amazon Bedrock agent?
A Bedrock agent handles multi-step tasks by deciding when to invoke a model and when to call action tools before returning a final answer, and custom orchestration lets you define that logic in your own Lambda function.
