Guide · Updated October 2026 for MCP and A2A
Edge vs Cloud AI Gateway
Same trust layer, two deployment topologies. Run the gateway in the operator's cloud or in your own VPC. The choice is rarely about features. It is about who is on the data path, what crosses your perimeter and which regulator you are answering to. That question used to be about prompts. Agents now send tool calls over MCP and messages to other agents over A2A, and each protocol puts different data on the wire. This guide is a decision framework for all three, with the technical deltas that matter for regulated and multi-region deployments.
Two topologies
Same gateway code, two deployment shapes. The line that matters is the customer perimeter.
Three protocols, one perimeter question
Each protocol carries different data across the gateway. The deployment choice has to hold for all of them.
LLM
Model calls
On the wire
Prompts, conversation history, system prompts, model responses and the documents sent for embedding.
Most sensitive part
The prompt body. It is where people paste customer records, source code and contracts.
Cloud or edge. The edge serves OpenAI- and Anthropic-compatible endpoints and routes to public providers or to private models in your network.
MCP
Tool calls
On the wire
Tool arguments and tool results, plus the resources and prompts an MCP server exposes.
Most sensitive part
The tool result. A query against your CRM, ticketing system or database returns the records themselves, often far more than anyone typed.
Cloud or edge. The edge runs the MCP gateway with per-tool policy, DLP on results, step-up and signed audit, for SaaS MCP servers and for MCP servers inside your network.
A2A
Agent-to-agent calls
On the wire
Messages, task state, artifacts and files exchanged with another organization's agent.
Most sensitive part
Everything in the message. The remote agent decides what to do with it, and it is not yours.
Cloud today, in both directions. An A2A agent configured for edge routing is refused, not sent through the cloud instead.
MCP raises the stakes for the edge. A prompt carries what a person chose to type. A tool result carries whatever the tool returned: a page of CRM records, a customer's ticket history, rows from a production database. An agent can make dozens of tool calls to answer one question, so on a cloud gateway the volume of regulated data crossing your perimeter follows the agent's behavior, not the user's. The tool servers that hold the most sensitive data are also often internal, which a cloud gateway cannot reach without exposing them.
A2A is different in kind. An LLM call goes to a model you chose under a contract you signed. An MCP call goes to a tool you registered. An A2A message goes to another organization's agent, which decides for itself what to do with it. The payload crosses an organizational boundary by design, so the sovereignty question moves from where the gateway runs to what is allowed into the message. Ferentin governs A2A on the cloud gateway in both directions, with per-skill permissions, approvals and DLP on every message and every reply. A2A cannot be routed through a customer-private edge yet. An agent configured for edge routing is refused, rather than quietly sent through the cloud.
In practice, a regulated tenant that uses all three runs both planes: LLM and MCP on the edge, A2A on the cloud with DLP and skill permissions deciding which data classes may reach an outside agent.
At a glance
How the two topologies compare across the dimensions that drive the decision.
| Dimension | Cloud Gateway | Customer-Private Edge |
|---|---|---|
| Protocols on this plane | LLM, MCP and A2A. A2A runs in both directions: your agents calling third-party agents and outside A2A clients calling yours. | LLM and MCP. A2A is served by the cloud plane today, so a tenant that uses A2A runs both planes. |
| Data path | Customer → public internet → managed gateway → LLM provider, MCP server or A2A agent. Prompts, tool calls and agent messages transit the gateway operator's cloud. | Customer VPC → in-VPC edge → LLM provider or MCP server. Prompts, tool arguments and tool results never pass through the operator's cloud. |
| Egress shape | Full request and response bodies plus headers cross the customer boundary by design. For MCP that includes every tool result. | Only signed telemetry leaves the perimeter: token counts, model, latency, MCP server and tool, SHA-256 hashes of tool arguments and results, policy decisions and audit hashes. No prompt, response or tool payload unless explicitly enabled. |
| Upstream credentials | LLM API keys and MCP server credentials are stored and decrypted in the gateway operator's cloud at request time. | LLM API keys and MCP server credentials arrive encrypted to the edge's own key and are decrypted inside the customer VPC, never logged. Bedrock and Vertex can use the workload's own cloud identity, so no key is stored at all. |
| Private upstreams | Reaches only what the operator's cloud can reach. An internal MCP server or a self-hosted model has to be exposed to the internet, or given a network path from the operator, before the gateway can call it. | Sits next to internal MCP servers and private models (vLLM, Ollama, Bedrock in your account). Nothing internal is exposed to reach the gateway. |
| Audit log location | Hosted log in the gateway operator's cloud. Customer pulls or streams it back. | Local audit buffer in the customer VPC. Signed receipts mirrored to the control plane. The full payload, if recorded, stays customer-side. |
| Failure mode (control plane unreachable) | Gateway is the data path. A control plane outage stops LLM, MCP and A2A traffic. | Edge keeps serving LLM and MCP traffic with the cached policy bundle. Telemetry buffers locally and ships when reachability returns. |
| Latency | Adds one network hop to the gateway region. Cross-region calls pay full RTT, once per model call and once per tool call. | In-region or in-VPC. Latency overhead is sub-10ms when co-located with the calling agent or the MCP server. |
| Multi-region | Bound to the gateway operator's region map. Data crosses regions to reach the gateway. | One edge per region (EU, US, India, AU, etc.). Each region is self-contained for data path and local audit. |
| Compliance posture | Customer inherits the gateway operator's SOC 2, ISO and BAA scope. Data residency is whatever the operator offers. | Customer keeps the data residency story. The trust-layer SOC 2 covers the control plane. The customer's own controls cover the in-VPC plane. |
| Operational ownership | Operator runs and patches the gateway. Customer runs nothing. | Operator ships the edge image and the control plane. Customer runs the edge in their VPC. Updates are policy-driven, not code-driven. |
| Subprocessor footprint | The gateway operator is a data-processing subprocessor for every LLM call, tool call and agent message. | For LLM and MCP traffic the control plane is a metadata-processing subprocessor only. The data path has no third-party processor besides the upstream you chose. |
Delta 1
Egress shape
A cloud gateway is on the data path. By construction, every prompt, every tool call and every agent message crosses the customer perimeter to reach it. That is the price of admission. The operator is now a data-processing subprocessor for every LLM call, MCP tool call and A2A message your enterprise makes. The prompt body, the tool result and the agent message are the assets that cross the boundary.
The customer-private edge inverts the topology for LLM and MCP traffic. The gateway runs inside the customer VPC. Prompts, responses, tool arguments and tool results flow between the agent, the edge and the upstream without ever touching the operator's infrastructure. What does cross the customer boundary is signed telemetry. For model calls that is token counts, model identifier, provider region and latency. For tool calls it is the MCP server and tool with SHA-256 hashes of the arguments and result. Both carry the policy decision and the hash of an audit receipt. The hashes let an auditor verify that a receipt matches a call without the content ever leaving. The control plane processes metadata, not content.
This is the difference between a data-processing subprocessor and a metadata-processing subprocessor. The downstream impact on your DPIA, your subprocessor disclosures and your customer-facing data-flow diagrams is significant. For workloads where the prompt body itself is regulated (PHI in clinical workflows, source code under export control, financial records subject to bank secrecy), the egress-shape difference is the entire reason to choose edge.
Delta 2
Failure mode
When a cloud gateway is unreachable, your AI traffic stops. The gateway and the policy plane are the same thing. There is no local fallback, because the gateway never had a copy of your policy bundle on your premises. The blast radius of a gateway-side incident is your entire AI surface, and for agents that is larger than it sounds: an agent that loses its tools mid-task fails differently from a chat window that cannot reach a model.
The edge is structured as a stateless data plane that pulls from a control plane. The policy bundle is cached locally and signed by the control plane. Identity claims are validated against a cached JWKS. Audit receipts are written to a local buffer that drains to the control plane when reachable. When the control plane is unreachable, the edge keeps serving with the last-known-good bundle and queues telemetry. From the application's perspective, nothing changes.
This is the same pattern a CDN edge uses for origin-shield outages. The data plane is decoupled from the control plane. The trust boundary is the signature on the bundle, not network reachability to the control plane. The practical consequence is that an outage in the operator's control plane does not become an outage of your application. The same holds for MCP: the edge keeps evaluating tool policy and serving tool calls from the cached bundle. A2A traffic runs on the cloud plane, so it follows the cloud's availability.
Delta 3
Private upstreams
LLM traffic mostly goes to public providers, so where the gateway runs matters for what crosses your perimeter on the way out. MCP adds a second question: where do the upstreams live? The MCP servers that matter most are often internal. A tool over your data warehouse, a self-hosted GitLab or Jira, an in-house API that knows your customers. They were never meant to be reachable from the internet.
A cloud gateway can only call what the operator's cloud can reach. To put an internal MCP server behind it, you either publish the server to the internet or open a network path from the operator into your environment. Both widen your attack surface to govern a tool that was safe because it was private. The same goes for self-hosted models.
The edge removes the trade-off. It runs next to the internal MCP server and the private model, so the tool call never leaves your network and nothing internal is exposed to reach the gateway. Identity, per-tool policy, DLP on results, step-up and signed audit are the same as for a SaaS MCP server. For workloads that mix both, a single edge reaches internal and SaaS MCP servers through one endpoint and one policy bundle.
Delta 4
Compliance posture
A cloud gateway transfers a meaningful fraction of your compliance work to the operator. The operator's SOC 2, ISO 27001 and BAA cover the data path. That is convenient for general workloads. It is also a hard ceiling: you inherit whatever residency the operator offers, whatever regions they support and whatever subprocessors they use. If your regulator is stricter than your operator's baseline, you have a problem.
The customer-private edge keeps the compliance story on your side of the line for the data plane. The operator's SOC 2 covers the control plane (metadata processing). Your existing controls, attestations and residency commitments cover the in-VPC plane. EU GDPR strict-residency tenants, HIPAA-covered clinical workflows, FedRAMP boundaries, India DPDP cross-border restrictions, China PIPL workloads and high-risk EU AI Act systems all become tractable, because the prompt body and the tool results never leave the regime in question.
A2A needs its own line in the data-flow diagram. Sending a message to an outside agent is a disclosure to that agent's operator wherever the gateway runs, so the control that matters is what is allowed into the message. DLP on outbound messages and per-skill permissions keep regulated data classes away from agents that are not cleared to receive them, and every call is recorded with the skill, protocol version and acting user.
Multi-region is the same pattern. One edge in the EU, one in the US, one in India, one in Australia. Each is self-contained for data path and local audit. The control plane sees telemetry from all of them. The customer-facing data-flow diagram has one fewer cross-border arrow per region.
Regimes that often force the edge
- HIPAA covered workflows touching PHI
- FedRAMP Moderate / High boundaries
- EU GDPR strict residency (DE, FR public sector)
- India DPDP cross-border data restrictions
- China PIPL data-export scrutiny
- EU AI Act high-risk system audit trails
- Bank secrecy regimes (CH, SG, financial services)
- Source-code export-control workloads
Regimes the cloud usually handles
- SOC 2 Type II for general developer workloads
- ISO 27001 / 27701
- GDPR for non-special-category data with SCCs
- CCPA / CPRA
- Standard BAA for low-PHI exposure
- Commercial customer-data flows with a DPA
Decision framework
Which topology should we run?
Two questions get most teams to the right answer. The first is regulatory: does any reasonable read of your data classification or residency obligation require prompts or tool results to stay inside a specific perimeter? Answer it for your MCP servers as well as your models, because tool results usually carry more regulated data than prompts do. The second is operational: do you have an SRE function that can run a stateless container alongside your other services? If you use A2A, add a third: which data classes may reach an outside agent at all?
Cloud Gateway
No regulated data class on the prompt or tool path, and every MCP server you use is reachable from the internet. SOC 2, ISO and a DPA cover your obligations. Pick this when speed-to-deploy matters and the operator's residency map is sufficient.
Hybrid
Most workloads on the cloud gateway. Edge only for tenants tagged with regulated data (PHI, classified, special-category personal data) or for internal MCP servers. Also the shape for any regulated tenant that uses A2A, which runs on the cloud plane today. Tenant-routing is policy-driven and the same identity, RBAC and audit semantics apply on both planes.
Customer-Private Edge
Regulated workloads, internal MCP servers, residency-bound regions or multi-region with sovereignty constraints. The LLM and MCP data path stays in your VPC, telemetry-only egress, per-region. The SOC 2 and BAA boundaries stay where you want them.
FAQ
Signed telemetry. For LLM calls: token counts, model identifier, latency, policy decision outcomes and audit-receipt hashes. For MCP calls: the server, the tool, the decision, any DLP or sanitization rules applied and SHA-256 hashes of the tool arguments and result, so a receipt can be verified without the content. The prompt body, the response body and tool payloads do not leave the perimeter unless you explicitly enable payload mirroring for a tenant or workload (e.g. for centralized eval). The default is metadata-only egress.
Related reading
Guide
MCP Server Access: Direct vs Gateway-Brokered
Why tool calls belong behind a trust layer at all.
Security
OWASP Agentic Top 10 Coverage
How A2A, MCP and agent goals are governed across the ten risks.
Security
ISO/IEC 42001 Control Mapping
The records LLM, MCP and A2A traffic contribute to an AI management system audit.
Compare
Ferentin vs OSS AI Gateways
LiteLLM, Portkey, Helicone and where each lands.
Blog
Zero Trust for LLMs Explained
Why every prompt and tool call needs to be authorized.
Security
Security & Compliance Overview
SOC 2, encryption, tenant isolation and continuous monitoring.
Keep the data path in your perimeter
Same trust layer for models and tools. Run it in your VPC. Telemetry-only egress to the control plane. Per-region by design.