How Veza Models Every Vertex AI Reasoning Engine, Service Account, and IAM Binding in a Single Access Graph
When we launched AI Agent Security for Google Cloud Vertex AI in December, we promised customers one thing: that every Vertex AI Reasoning Engine in their GCP project would show up in the Access Graph as a first-class non-human identity — with the service account it runs as, the IAM bindings that service account inherits, and every BigQuery dataset, Cloud Storage bucket, and Cloud SQL instance it can reach traced end-to-end.
Five months in, the most common question we get from cloud security architects is “show me exactly how it works.” This post is that walkthrough.
Key takeaways
- Every Vertex AI Reasoning Engine is a non-human identity. Veza captures it as VertexAiReasoningEngine and treats it as an NHI in the Access Graph alongside humans, service accounts, and other automation.
- The service account is where the real blast radius lives. Reasoning Engines don’t hold permissions — they run as a GCP service account, and that account’s IAM bindings become the agent’s reachable surface across BigQuery, GCS, Cloud SQL, Pub/Sub, and beyond.
- Discovery is automatic. If Vertex AI is enabled in the project, Veza picks up Reasoning Engines, the service accounts they run as, IAM bindings, models, and endpoints on the next extraction.
- The HAS_SERVICE_ACCOUNT edge is non-transitive. Delegation is modeled as a distinct, auditable hop — not silently merged into the agent’s identity.
- Inbound and outbound are both modeled. Who can invoke or manage each Reasoning Engine (inbound) and what GCP resources each one can reach (outbound) live in the same graph.
Why Vertex AI Agents Need Identity-First Governance
AI agents built on Google Cloud Vertex AI are not abstract experiments. They are production Reasoning Engines orchestrating tool calls, querying foundation models, and acting against the rest of your Google Cloud project — BigQuery datasets, Cloud Storage buckets, Cloud SQL instances, Pub/Sub topics, anything a service account can touch.
Each one runs as a Google Cloud service account. Each one inherits whatever IAM bindings that service account has been granted. And in most organizations, no one can answer the basic governance question:
What can each Vertex AI agent actually reach in our Google Cloud environment — and who can invoke it?
That’s the gap Veza closes. For every Reasoning Engine in your GCP project, Veza answers the question we were built to answer:
What can take what action on what data — across every AI Agent in Vertex AI?
What Veza Discovers in Vertex AI
Veza extends the existing Google Cloud integration to model Vertex AI as a first-class non-human identity surface. Discovery is automatic on the next extraction — Reasoning Engines, the service accounts they run as, the IAM bindings on those service accounts, and the model and endpoint configurations come in together.
The following entities and relationships are visible:
- Vertex AI Reasoning Engines — every stateful agent deployed in Vertex AI, captured as VertexAiReasoningEngine and treated as a non-human identity in the Access Graph
- Service accounts — the Google Cloud service account each Reasoning Engine runs as, linked through a non-transitive HAS_SERVICE_ACCOUNT edge so delegation is explicit rather than implied
- Foundation Models — Gemini and other pre-trained models available on the platform, captured as VertexAiFoundationModel
- Custom Models — fine-tuned models registered in the Vertex AI Model Registry, captured as VertexAiModel
- Endpoints — deployed model endpoints serving predictions, captured as VertexAiEndpoint
- IAM bindings — VertexAiPolicy and VertexAiRoleBinding resources tying Google Cloud principals to Vertex AI resources
A Worked Example: A Finance Reasoning Engine on BigQuery
Picture a Reasoning Engine named finance-insights-engine running in production for a financial-services org:
- It runs as the service account vertex-finance-sa@project.iam.gserviceaccount.com
- That service account holds roles/bigquery.dataViewer on the finance_prod dataset (regulated revenue data)
- It also holds roles/storage.objectViewer on the finance-reports Cloud Storage bucket
- It calls gemini-1.5-pro as its foundation model and one fine-tuned model from the Vertex AI Model Registry
- It is deployed behind a single endpoint at scale
- 23 GCP principals across 3 folders hold aiplatform.reasoningEngines.query on it
Before Veza, surfacing all of that required pulling from the Cloud Console, IAM Recommender, BigQuery audit logs, and Vertex AI Model Registry — and even then, no one could traverse it. With Veza, a security architect opens the Access Graph, types “show me what finance-insights-engine can read in BigQuery,” and gets the answer in one query — including the human invokers upstream and the service account hop in between.
That’s the difference identity-first modeling makes for AI agents on regulated financial data.
Answering Critical Security Questions
How do I see what a Vertex AI agent can actually reach in Google Cloud?
Vertex AI agents do not hold permissions directly. They run as a Google Cloud service account, and that service account is where ambient and delegated permissions actually live. Veza models the delegation as a clear graph path:
Vertex AI Reasoning Engine → HAS_SERVICE_ACCOUNT → Service Account
→ IAM Role Binding → Project / Folder / Resource
→ HAS_EFFECTIVE_PERMISSION → BigQuery / GCS / Pub/Sub
Questions answered in a single query:
- Which Reasoning Engines can read or write specific BigQuery datasets, Cloud Storage buckets, or Cloud SQL instances?
- Does any agent’s service account hold roles/owner, roles/editor, or other broadly privileged roles at the project level?
- Which agents share a service account, and therefore share blast radius?
- If a service account is rotated or replaced, which Reasoning Engines are affected?
The HAS_SERVICE_ACCOUNT edge is intentionally non-transitive in the Access Graph, so the delegation is auditable as a distinct hop — not silently merged into the agent’s identity.
Who can invoke or manage a Vertex AI Reasoning Engine?
In Google Cloud, the right to invoke a Reasoning Engine is itself an IAM permission on the resource. Veza wires those bindings directly into the graph:
Google Cloud Principal → IAM Role → Vertex AI Resource Binding
→ ON_RESOURCE → Reasoning Engine
Questions answered:
- Who in the organization can invoke each Vertex AI Reasoning Engine?
- Which agents are exposed broadly via project-level roles versus locked down with resource-level bindings?
- When a user moves teams or leaves, which agents do they retain — or lose — the ability to invoke?
What models, endpoints, and registry entries are running under the hood?
The model layer matters as much as the access layer. Veza inventories the foundation models, custom models, and endpoints configured on the platform so you can see what is actually deployed and serving traffic:
- Which Gemini and foundation models are available on this project?
- Which custom-tuned models are registered, and where did the training data come from?
- Which endpoints are live, and at what scale?
- When a model is deprecated or retired, which endpoints and engines are impacted?
What This Unlocks for Security and IAM Teams
For every Vertex AI Reasoning Engine, Veza surfaces:
- The agent and the service account identity it runs as
- The IAM roles and bindings the service account inherits across the Google Cloud project hierarchy
- The BigQuery, Cloud Storage, and other GCP resources it can effectively reach
- The foundation models, custom models, and endpoints configured on the platform
- The Google Cloud principals — humans, groups, and other service accounts — that can invoke each engine
That visibility plugs into everything Veza already does:
- Access Reviews — Reasoning Engines become reviewable entities alongside humans and service accounts
- Blast Radius — over-privileged agents surface against the same risk model as any other identity in Google Cloud
- Rules & Alerts — trigger on a new agent without an owner, an engine running under a service account with roles/editor on the project, or a service account suddenly granted access to a sensitive BigQuery dataset
- Access Graph search — natural-language and graph queries traverse the full chain from human invoker to Reasoning Engine to data
Frequently Asked Questions
Do I need a new connector to enable Veza for Vertex AI? No. If you already have the Veza Google Cloud integration in place, Vertex AI discovery is automatic on the next extraction. There’s no separate connector, no additional datasource, and no agent runtime to deploy.
How does Veza handle the service account a Reasoning Engine runs as? The HAS_SERVICE_ACCOUNT edge is intentionally modeled as a distinct, non-transitive hop rather than silently merging the service account’s permissions into the agent’s identity. That makes the delegation auditable — you can answer “which Reasoning Engines share this service account” and “what does this service account grant” as separate questions.
Does Veza model fine-tuned and custom models in the Vertex AI Model Registry? Yes. Both foundation models (VertexAiFoundationModel) and custom-tuned models (VertexAiModel) are inventoried and linked to the engines and endpoints that consume them. So you can ask “which engines depend on this model” before you deprecate it.
Can I run access reviews on Reasoning Engines the same way I do for human users? Yes. Reasoning Engines become reviewable entities in Veza Access Reviews, with the same campaign cadence, reviewer assignment, and risk-based prioritization you already use for humans and service accounts.
Does Veza alert when a Reasoning Engine runs under an over-privileged service account? Yes. Rules & Alerts can trigger on engines whose service accounts hold roles/owner, roles/editor, or any custom risk pattern your team defines — including service accounts newly granted access to a regulated BigQuery dataset.
Does Veza model invocation permissions on each Reasoning Engine? Yes. The IAM bindings that grant aiplatform.reasoningEngines.query and related permissions are wired into the graph, so you can answer “who can invoke this engine” without leaving the Access Graph.
Getting Started
Veza AI Agent Security for Google Cloud Vertex AI is generally available for existing Google Cloud integrations. Once Vertex AI is enabled in the project, Veza picks up Reasoning Engines, service accounts, models, and endpoints on the next extraction.
- Existing Veza for Google Cloud customers — reach out to your account team to confirm enablement.
- New customers — request a demo to see the full Access Graph in action, including a live walkthrough of a Reasoning Engine traced from service account to BigQuery dataset.
- Want to go deeper? Read the Veza AI Agent Security overview and the Veza for Google Cloud solution brief.
Related Reading
Veza Expands AI Agent Security to Azure AI Foundry (launch blog)
Inside Veza’s AI Agent Security for Amazon Bedrock Agents (deep dive)
Inside Veza’s AI Agent Security for Microsoft Copilot Studio (deep dive)
Inside Veza’s AI Agent Security for Salesforce Agentforce and Einstein Bots (deep dive)
