In the first part of this series, we mapped the structure of an enterprise agentic architecture: the difference between desktop and cloud agents, why the harness — not the LLM — is the hard engineering problem, and how the stack organizes around experience, reasoning, memory, protocol and data concerns. We also noted that CData Connect AI handles data connectivity through Model Context Protocol (MCP).
This post makes that concrete. Here is how those planes map to specific Google Cloud services, how CData Connect AI fits into a GCP-native agent runtime, and what the trust boundaries between GCP-managed infrastructure and CData-managed connectivity actually look like in production.
Agentic architecture on Google Cloud
Here is how the pieces fit together on Google Cloud Platform (GCP). Read the diagram top to bottom: a user enters through the Experience Plane, their intent flows through the Reasoning and Memory Planes, crosses a protocol bridge, and executes against enterprise data in the Data Plane.
Figure 1. Agentic Architecture on Google Cloud Platform — layered view showing the Agent Trust Boundary (GCP-managed), the MCP protocol bridge, the CData Trust Boundary, and the two cross-cutting strips for Security & Governance and Observability & Evaluation.
The architecture is organized into five horizontal planes plus two vertical cross-cutting layers:
Experience Plane — Apigee, Cloud CDN, Cloud Run app, App Session Store
Reasoning Plane — Agent Supervisor, Agent Registry, four Specialist Agents, Vertex AI, Model Armor
Memory Plane — Agent Engine (Sessions, RAG Engine, Memory Bank), Secret Manager
Protocol Plane — MCP Servers (CData, third-party). The MCP Client straddles this plane and the Agent Trust Boundary above it.
Data Plane — CData Connect AI, Workspaces, Connections, Configurations, Auth0, Toolkits, Tool Registry
The two vertical layers on the right — Security & Governance and Observability & Evaluation — run as parallel cross-cutting concerns. Each layer is itself divided into an upper Agent Trust Boundary zone (GCP-managed) and a lower CData Trust Boundary zone.
The Agent Trust Boundary
Everything above the Protocol Plane sits inside the Agent Trust Boundary. This is the zone Google Cloud manages on the enterprise's behalf: Agent Engine runs the orchestration, ADK defines the agent structure, Gemini does the reasoning, Model Armor screens for prompt injection and PII, Agent Engine Sessions holds the short-term conversation, Memory Bank holds cross-session preferences, and Secret Manager holds the credentials the agent needs to talk outward.
A few implementation details matter here:
The Agent Supervisor is the root agent. In ADK terms it is a workflow agent that receives the decomposed intent and decides which specialist to hand it to. Specialists are individual Cloud Run services, each scoped to a domain (sales, support, data quality, reporting). The Agent Registry is Firestore-backed metadata about which agents exist and what they can do — the Cloud API Registry preview adds tool governance on top.
Model Armor sits inline with Vertex AI. Every prompt going into Gemini and every response coming back gets screened. Floor Settings apply at the organization level; Templates apply per project. This is where responsible-AI policy becomes enforceable infrastructure rather than something the prompt engineer has to remember.
Agent Engine Sessions and Memory Bank are the agent's working memory. Sessions is short-term — the chronological event log for a single conversation. Memory Bank is long-term — topic-extracted user preferences that survive across sessions. Both went GA in late 2025 and are backed by Firestore underneath.
Everything in this zone is reachable over Google Cloud network fabric. VPC Service Controls draws the perimeter, and PSC-I lets the Agent Engine reach privately-hosted services inside a VPC without traversing the public internet.
The Protocol Plane
The MCP Client is the boundary crossing. It runs inside Agent Engine — so architecturally it belongs to the Agent Trust Boundary — but its entire purpose is to speak the Model Context Protocol outward to MCP servers that live beyond GCP.
On every tool call, the MCP Client:
Serializes the agent's tool invocation into an MCP JSON-RPC payload
Pulls the appropriate bearer token from Secret Manager
Attaches auth headers and dispatches over HTTP
Handles streaming responses (SSE or chunked HTTP)
Routes to the correct MCP server based on which tool was called
The MCP servers themselves are external. The MCP Server (CData) endpoint is CData-hosted and workspace-scoped. MCP Server (Other) covers third-party tool providers like Slack, GitHub, Jira. The agent's ADK configuration declares which MCP servers it can reach; the Cloud API Registry governs the fleet centrally.
The significance of this layer: the agent never writes Salesforce API calls, never writes Jira REST requests, never handles pagination or auth refresh for SaaS platforms. It writes tool calls. The MCP protocol abstracts all of that.
The CData Trust Boundary
Below the MCP bridge, a different trust domain begins. The CData Trust Boundary is where enterprise data virtualization happens — the layer that turns 350+ heterogeneous data sources into a single SQL-shaped interface the agent can reason against.
The components:
CData Connect AI is the virtualization engine. It takes SQL queries from the MCP server and federates them against the underlying sources.
Workspaces isolate connection sets. A sales workspace contains Salesforce + HubSpot. A support workspace contains Zendesk + ServiceNow. An agent configured for workspace A cannot see connections in workspace B. This is infrastructure-level isolation, not prompt-level.
Connections are the individual source bindings — Salesforce org, Jira site, SAP instance. Each connection has its own auth context.
Configurations are reusable SQL templates, custom tools, and toolkit definitions.
Auth0 handles authentication and authorization into the CData platform itself.
Toolkits are domain-scoped tool bundles. Each toolkit maps to an agent. The Sales toolkit exposes Salesforce account and opportunity tools; the Support toolkit exposes ticket tools; the Customer Health toolkit exposes multi-source joins across Salesforce, Jira, Zendesk, and Snowflake. When an agent connects to the CData MCP endpoint, it only sees the tools in its assigned toolkit.
Tool Registry enforces schema validation — the MCP tools that get exposed are derived from the connection metadata, not hand-written.
The key architectural property: the agent's LLM never sees raw API schemas from downstream sources. It sees clean, semantically-named SQL-shaped tools. The CData layer absorbs the impedance mismatch between how SaaS APIs are designed and how LLMs are good at reasoning.
Where security and governance live
Security is a vertical concern, not a horizontal layer. The Security & Governance strip runs parallel to the main architecture and touches every plane.
Inside the Agent Trust Boundary, the security stack is pure GCP:
Cloud IAM handles workload identity and service accounts. Agent Engine uses Context-Aware Access (CAA) for agent identity by default.
Cloud Armor provides WAF and DDoS mitigation at the edge, sitting in front of Apigee and any Load Balancer.
VPC Service Controls draws the perimeter. Data exfiltration out of the agent zone to the public internet is blocked at the network layer.
Model Armor Policies enforce prompt injection and PII guardrails. Floor settings at the org level prevent any team from configuring a weaker template.
Cloud Billing provides cost attribution — which agent consumed how many tokens becomes a line item.
Outside the Agent Trust Boundary, inside the CData Trust Boundary:
RBAC, Access Control enforces workspace and toolkit-level permissions at the data layer. The agent cannot query a connection it has not been granted access to — not because the prompt says so, but because the query will not execute.
The separation matters. Agent-level IAM decides what the agent can do; CData RBAC decides what the agent can see. Both are required. Neither is sufficient on its own.
Where evaluation and observability live
The Observability & Evaluation strip is the mirror image of the security strip. Same vertical structure, different concerns.
Inside the Agent Trust Boundary:
Cloud Logging & Monitoring captures structured logs, metrics, and alerts. Cloud Managed Prometheus handles custom metrics.
Cloud Trace provides distributed tracing with OpenTelemetry support. Agent Engine has native Cloud Trace integration — every agent call, every tool invocation, every LLM request becomes a span.
Cloud Audit Logs records admin activity and data access on an always-on, hardened trail.
SCC Threat Detection (Preview) monitors for attacks on deployed agents specifically.
Evaluation Pipeline is where intent lineage, A/B testing, and feedback loops live. Vertex AI Evaluation Services feed into this.
Inside the CData Trust Boundary:
Audit Log (CData) records every query the agent executed, against which workspace, against which toolkit, with which credentials. This is the data-layer audit trail that complements the GCP-side audit logs.
Together, the two audit trails give full intent-to-outcome traceability: a user's prompt, the agent's reasoning, the tool calls it made, the SQL that got executed, the rows that came back, and the response that went out. That trail is what makes an agent system debuggable when it misbehaves — and auditable when regulators ask how a decision was reached.
The pattern is consistent: Google Cloud handles everything from the user's click through to the MCP boundary. CData handles everything from the MCP boundary through to downstream enterprise data. Security and observability span both domains as parallel concerns. The Agent Trust Boundary and the CData Trust Boundary meet at a protocol — MCP — not at an API integration.
That separation is what makes the whole thing composable. Swap Gemini for Claude. Swap Agent Engine for a LangGraph deployment on GKE. Because CData Connect AI surfaces connectivity through established protocols (and established connectivity based on an organization's existing security and identity policies), you can swap whichever components you want, and the other pieces keep working. With Connect AI as the data layer, your architecture is no longer bound to a single product; it is simply bound to the interfaces between them.
Start with Connect AI on Google Cloud
Ready to wire up the data plane? CData Connect AI integrates with Gemini, Vertex AI, and the rest of your Google stack — governed, live, and MCP-ready. Connect your data on Google Cloud.
Your enterprise data, finally AI-ready.
Connect AI gives your AI assistants and agents live, governed access to 350+ enterprise systems — so they can reason over your actual business data, not just what they were trained on.
