Vertex AI Agent Engine governs agent identity and authorization through Google Cloud IAM and service accounts, the same mechanism Google Cloud customers already use for every other workload. That gives agents built and run on Vertex AI a mature, well-understood permission model inside Google Cloud. It does not extend to what happens once an agent calls a system Google does not operate, which is where most enterprise governance gaps in a multi-cloud estate actually live.
What Vertex AI Agent Engine covers
Vertex AI Agent Engine is Google Cloud's managed runtime for deploying and operating agents built with Google's agent tooling, including the Agent Development Kit (ADK). Its native governance surface rests on infrastructure Google Cloud customers already run:
- Identity and authorization flow through Cloud IAM. An agent runs under a service account, and that service account's IAM bindings determine what Google Cloud resources — Cloud Storage, BigQuery, other Vertex AI models, Cloud Functions — the agent can reach. This is the same principle of least privilege Google Cloud applies to every other workload, not a bespoke system invented for agents.
- Logging and monitoring integrate with Cloud Logging and Cloud Monitoring, giving teams a familiar place to look for agent activity rather than a separate telemetry stack.
- Model and tool grounding is managed within the Vertex AI project boundary, so declared tools and data sources are visible to whoever administers that project.
- Data governance for structured data an agent queries typically runs through BigQuery's own access controls, which are themselves IAM-backed, keeping data access and agent identity on a consistent permission model within Google Cloud.
For an agent population that is built on Vertex AI, uses Google-native tools, and calls only Google Cloud and Google Workspace resources, this is a legitimately strong default. Building a parallel identity system for a genuinely single-cloud Google estate adds overhead without a governance benefit — the same logic that applies to a single-cloud AWS estate served well by AWS AgentCore Identity, or a single-cloud Azure estate served by Microsoft's own agent identity extensions to Entra ID.
A documented reminder that pipeline risk is separate from IAM
A disclosed flaw in the ADK repository's own CI automation, covered in the ADK privilege escalation GitHub issue, is worth knowing about specifically because it illustrates a distinction that matters for every agent platform, not just Google's: the vulnerability lived in ADK's repository CI workflows — GitHub Actions that processed untrusted public issue content with broad repository credentials — not in a customer-deployed ADK agent and not in a permission-handling defect in the shipped framework. It was a repository-automation issue, not a defect in a deployed agent, but the underlying pattern generalizes to any privileged pipeline that acts on untrusted public input, including CI/CD automation your own agents or agent-adjacent tooling touch. IAM governs what a service account is allowed to reach; it says nothing about what a privileged workflow sitting outside that boundary does with untrusted content, which is why both need independent review.
Where the cross-cloud and cross-SaaS boundary bites
The structural gap for Vertex-hosted agents is not a Google Cloud weakness — it is the same shape every hyperscaler's native agent tooling shares. IAM and Cloud Logging are excellent at governing and recording what happens to Google Cloud resources. They have no visibility into:
- Agents that call SaaS platforms with their own identity model. A Vertex-hosted agent calling a CRM, ERP, or HR platform interacts with a system governed entirely by that platform's own permission model, invisible from Cloud IAM's console. Securely sharing AI agents across orgs covers the general pattern of extending trust to a system your own IAM does not administer.
- Agents that call third-party MCP servers. Tool access mediated through an MCP server is a distinct control surface from Google Cloud resource access, and it needs its own vetting process regardless of which cloud invokes the tool. MCP server vetting and registry risk covers what that process should check.
- Agents that call resources on AWS or Azure. Multi-cloud is the norm rather than the exception for enterprises with more than one business unit, acquisition, or long operating history, and each cloud's IAM only accounts for activity on that cloud.
- Agents whose data touches non-Google jurisdictional requirements. Data residency for AI agents covers why the agent's hosting region and the actual processing location of every system it calls are separate questions that both need answers.
A service account's IAM bindings can be perfectly scoped, audited, and least-privilege by every measure Google Cloud provides, and the agent can still create governance risk the moment it acts on a system outside that IAM boundary — because nothing in Cloud IAM's design is meant to reach that far.
A cross-boundary risk checklist
| Question | Why it matters |
|---|---|
| Does the agent's tool list include any system Google Cloud IAM does not govern? | Each one is a boundary crossing Cloud Logging cannot see into. |
| Is there one inventory covering agents on Vertex AI, other clouds, and SaaS platforms, or three separate lists? | Fragmented inventories are how an agent's actual permission footprint goes unverified after ownership changes. |
| Can a security review trace a service account's IAM bindings all the way to whatever credential the same agent presents downstream? | Without that mapping, the agent's real access footprint is wider than the IAM console shows. |
| Is spend triggered by an agent's calls to non-Google APIs visible outside Google Cloud Billing? | Cloud Billing does not see spend an agent generates on a third-party platform's own metering. |
| Does your review of ADK-based agents cover the CI/CD and repository automation around them, not just the deployed agent's IAM bindings? | The ADK CI incident shows privileged automation reachable by untrusted public content is a separate risk surface from a deployed agent's IAM configuration. |
What's specific to Vertex, versus the generic cross-cloud layer
Most of what closes the gap here — a cross-platform agent inventory, identity mapping from a Google Cloud service account to whatever credential the same agent uses elsewhere, and a unified audit trail spanning Cloud Logging and non-Google systems — is the same shared control set for every hyperscaler, covered in what is an AI control plane.
What is specific to a Vertex/ADK deployment is narrower:
- Treat your own agent code and any CI/CD automation around it as a risk surface distinct from IAM bindings. A service account can be scoped correctly while the pipeline that builds, tests, or triages issues against that agent's repository runs with broader privilege than the deployed agent itself — the pattern the ADK CI incident illustrates.
- Reviewed trust extensions across clouds, since Vertex-hosted agents calling AWS or Azure resources cross a boundary Cloud IAM was never built to see. Cross-org agent federation and trust manifests covers how to make that an explicit, owned decision.
- Consistent egress policy regardless of which cloud initiated the call, since a data exfiltration risk from a Vertex-hosted agent calling an external API is the same risk regardless of which hyperscaler runs the agent.
What good looks like
- Every Vertex AI Agent Engine deployment is entered in an inventory that also covers agents hosted on other clouds — not a Google-only list.
- A service account's IAM role can be traced, without manual reconciliation, to every non-Google credential the same agent presents downstream.
- CI/CD and repository automation around any ADK-based agent is reviewed as its own risk surface, independent of the deployed agent's IAM configuration.
- An incident response team can produce one timeline spanning Cloud Logging and at least one non-Google target system for the same agent.
- Cross-cloud and cross-org trust extensions are logged as reviewed decisions, not discovered retroactively during an audit.
Cloud IAM and Vertex AI's native tooling are a sound foundation for agents that stay inside Google Cloud. For the multi-cloud estate most enterprises actually run, that foundation needs a governance layer above it that was never scoped to any one provider's boundary in the first place.
Common questions
Is Cloud IAM enough to govern a Vertex AI agent by itself? For an agent that only touches Google Cloud resources, IAM's least-privilege model, combined with Cloud Logging for an audit trail, is a legitimately strong answer. The evaluation changes the moment the agent's tool list includes a non-Google system, at which point IAM's visibility simply stops.
Does a well-scoped service account protect against a compromised CI/CD pipeline around an agent? Not entirely. IAM controls what a service account is authorized to reach; it does not review the security of the CI/CD or repository automation built around an agent framework. The documented ADK CI incident — a privileged workflow triggered by untrusted public GitHub content, not a defect in a deployed agent — is a concrete example of risk living in a pipeline layer separate from IAM, which is why both need independent review.
Do Cloud Logging and Cloud Monitoring capture what an agent does on another cloud or SaaS platform? No. They capture activity against Google Cloud resources and services that emit logs into Google's logging pipeline. An agent's actions on Salesforce, SAP, AWS, or a third-party MCP server are recorded, if at all, in that system's own logs, which is exactly the fragmentation a unified audit trail needs to resolve.
What is the first thing to check if agents run on both Vertex AI and another cloud? Start with the inventory question: is there one list of every agent, regardless of hosting cloud, with its owner and declared tool access, or does each platform maintain its own list that nobody has reconciled? That single question surfaces most of the downstream governance gaps described above.