Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Confidential Data Can Gemini Enterprise Agents Reach?

Everything the agent's service account can read: Google documents that deployed agents have access to all resources their service account has permission to access, so an over-scoped account exposes whole projects. Check each agent's service account grants, whether Agent Identity and VPC Service Controls narrow them, and what the model reads once a resource is in reach.

A central agent cylinder sends branching ribbons toward document stacks and storage objects across a broad platform.

Everything the agent's service account can read: Google documents that deployed agents have access to all resources their service account has permission to access, so an over-scoped account exposes whole projects. Check each agent's service account grants, whether Agent Identity and VPC Service Controls narrow them, and what the model reads once a resource is in reach. A note on names first: in April 2026 Vertex AI evolved, in The New Stack's words, into the Gemini Enterprise Agent Platform, and documentation written under the old name still describes much of the same machinery. This page uses the current name. The question itself is a Google Cloud question before it is an AI question. An agent deployed on the platform runs as a service account, and a service account's IAM grants are its reach; Google says so directly. Everything else on this page, Agent Identity, the extension of VPC Service Controls to agents, Model Armor and the access controls on Gemini Enterprise data sources, narrows or screens that reach, and none of it, in the pages reviewed, changes what the model reads once a resource is legitimately in reach. The page works through the rename, the service account rule, the perimeter controls, the screening and access controls, the public record on oversight, and what a buyer should verify. The frame is the one set out in mapping everything an agent can access.

Key findings

  • Google's documentation for managing access to deployed agents states that deployed agents have access to all resources that their service account has permission to access (Google Cloud, 2026).
  • Google's Agent Identity overview describes a strongly attested, cryptographic identity for each agent, granted permissions directly through IAM, which lets an agent be distinguished from the project's shared service accounts (Google Cloud, 2026).
  • Press coverage of a June 2026 update reports that Google added agent identities to VPC Service Controls ingress and egress rules, so a perimeter can be drawn around agents as well as users (IT Brief, 2026).
  • Google documents Model Armor as able to screen user prompts to and responses from AI agents on Gemini Enterprise, a control on text rather than on reach (Google Cloud, 2026).
  • The MIT AI Agent Index entry for Gemini Enterprise records no approval requirements found for any decision type, while noting that users can pause or stop an agent (AI Agent Index, 2026).
  • The platform's own name changed in April 2026, when Vertex AI evolved into the Gemini Enterprise Agent Platform, which means older documentation and newer controls describe the same deployments (The New Stack, 2026).

What was Vertex AI, and what is the Gemini Enterprise Agent Platform?

The rename matters because the controls that govern an agent's reach are spread across pages written under two names. The New Stack reported on April 22, 2026 that Vertex AI has now evolved into the Gemini Enterprise Agent Platform (The New Stack, 2026), and Google's announcement the same day describes the new Gemini Enterprise as one platform for agent development (Google Cloud, 2026). The agent runtime, deployment model and service account mechanics carried over; what changed is the name and the packaging alongside Gemini Enterprise, Google's end-user agent and search product.

Two things follow. An agent deployed under Vertex AI before April 2026 is governed by the same service account rule described below, whatever the console now calls it. And controls announced after the rename, such as the extension of VPC Service Controls to agent identities, apply to older deployments only if someone configures them. A rename does not re-scope a service account.

The phrase "Gemini Enterprise agents" also covers two populations: agents the organization builds on the Agent Platform, running under service accounts it created, and agents inside the Gemini Enterprise product that operate on connected data sources under access controls Google documents separately. The reach question differs for each, and the sections below treat the Agent Platform case first because the organization holds every lever there.

What decides a deployed agent's reach?

Google answers in one sentence: deployed agents have access to all resources that their service account has permission to access (Google Cloud, 2026). An agent on the platform is a workload, and a workload's reach in Google Cloud is the union of the IAM roles granted to the identity it runs as. If that identity is a project's default service account with broad roles, the agent can read whatever those roles cover, often everything.

Consider a single record type: a customer records table in a BigQuery dataset, inside a project that also holds the agent. The agent was deployed to answer product usage questions and given the project's default compute service account because the deployment wizard offered it. That account holds an Editor-class role granted years ago. The agent can now read the customer records table, the billing export, the support ticket dataset and a bucket of exported contracts, none of which the usage questions require. Nothing is misconfigured by the project's standards. The agent has the reach of its identity, and the identity was scoped for a different era.

Google's own best practices for service accounts warn against exactly this: they counsel dedicated service accounts per workload, minimal roles, and avoidance of the broad defaults (Google Cloud, 2026). Followed, that guidance gives each agent a dedicated identity with roles limited to the datasets its tasks use. Not followed, it leaves the agent with whatever the project accumulated. The title question is therefore answered, for Agent Platform agents, by an IAM report: list the service account each agent runs as and the roles bound to it, and that is the confidential data the agent can reach.

How do Agent Identity and VPC Service Controls narrow the perimeter?

Two newer controls address the problem from different sides. Google's Agent Identity overview describes a strongly attested, cryptographic identity for each agent, granted permissions directly through IAM (Google Cloud, 2026). An agent need not borrow a shared service account; with its own identity and grants, the IAM report answers the reach question per agent.

The second is the perimeter. VPC Service Controls draw a boundary around resources, and press coverage of a June 2026 update reports that Google added agent identities to ingress and egress rules (IT Brief, 2026). An agent can thus be allowed to read inside the perimeter and forbidden to move data out.

Dimension Google, per its documentation What a buyer should verify
Reach All resources the agent's service account can access The identity and roles bound to every deployed agent
Identity A cryptographic identity per agent, with IAM permissions granted directly Whether agents have their own identities or share project accounts
Perimeter Agent identities in VPC Service Controls ingress and egress rules (per press) Whether perimeters are configured for agents
Screening Model Armor screens prompts and responses What the policies test and what they let through
Values the model reads Not described in the pages reviewed Which fields the model receives from a permitted table

Both narrow reach; neither changes what the model reads inside the reach that remains. A tightly scoped agent that may read the usage dataset reads every column, including the customer identifiers joined into it, because the controls operate on resources, not values, a limit shared with network-level controls on data reaching AI tools.

What do Gemini Enterprise access controls and Model Armor do?

For the second population, agents inside the Gemini Enterprise product operating on connected data sources, Google documents access controls for custom data sources. The documentation states that access control limits the data that users can view in a search app's results (Google Cloud, 2026). The page addresses users, not agents. How an agent acting on those sources inherits or differs from that control is not described in the pages reviewed, and a buyer should ask rather than assume the user-level control applies unchanged when an agent is the reader.

Model Armor most resembles data protection, so it pays to be exact. Google documents it as able to screen user prompts to and responses from AI agents (Google Cloud, 2026). It is a filter on the conversation, applied to what the user sends and what the agent returns. What the agent reads from a data source in between, the customer records table it queried to compose the response, is not what the documentation describes it as screening.

That distinction is the one the title question turns on. Access controls decide which resources are in reach. Model Armor decides which text may pass between user and agent. Neither, in the pages reviewed, substitutes a token for a customer identifier before the model reads the table, so the model works with the real values and the controls try to catch them on the way out. A design that gives the model consistent tokens from the moment data is rendered addresses the step both controls leave open; whether anything comparable exists on the platform is not described in the pages reviewed. How that design relates to infrastructure controls such as confidential computing is set out in whether a confidential VM keeps data away from the AI.

What does the public record show about approval and oversight?

Reach is half the risk; what the agent does with it is the other. The MIT AI Agent Index entry for Gemini Enterprise records, for approval requirements across decision types, that none were found, while noting that users can pause or stop an agent (AI Agent Index, 2026). The index documents public information, so "none found" means the public record does not describe a built-in requirement that a person approve a class of agent decisions, not that no organization has built one. Pause and stop are controls a person exercises while watching, not gates an action must pass.

For the customer records example, an agent with reach into the table and a tool that can export data could do so without a documented platform-level approval step, subject to the perimeter and IAM constraints the organization configured. VPC Service Controls egress rules are the documented mechanism for stopping data leaving a perimeter; an approval by a named person before a specific action is not described in the pages reviewed. An organization that wants that gate must build it or bring it.

The general shape of the problem, an agent whose reach is defined by identity and whose actions are logged rather than approved, is the one described in how much enterprise data an agent can actually reach. Google's platform gives strong levers on identity and perimeter, and a text filter on the conversation. The levers on what the model reads within its reach, and on who approves what it does with it, are the organization's to supply.

What does a governed environment change?

In a governed environment, an agent's service account still defines how far it can reach, but the sensitive values on any screen it works through are replaced with tokens before the model reads them, so a correctly scoped reach no longer carries a reading exposure inside it.

The mechanism is a class of control that sits between the rendered application and the model. Sensitive values on the screen, such as customer identifiers a product usage task never needs, are replaced with consistent tokens before any model reads them, and the task runs on those tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions, including payments, submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This bears on the title question because Google's documentation places the answer in IAM: deployed agents have access to all resources their service account has permission to access (Google Cloud, 2026). Perimeters and agent identities narrow reach. Model Armor screens prompts and responses (Google Cloud, 2026), a control on text after the fact. None of them decides what the model reads once a resource is within reach, the test the previous section said the IAM report cannot run. The environment runs it on every screen and records the result.

The control does not change the service account, its IAM roles, the perimeter or the model, and it covers rendered screens the agent works through, not a query the agent's runtime issues directly against a dataset.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design addresses the last row of the table: what the model reads from a resource that is legitimately in reach. Work runs in a governed environment in the customer's cloud. When an agent opens a customer records table, a console page or a dataset view, substitution happens at the render layer before any model reads the screen, so identifiers appear to the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change under Supervised Delegation, which supplies the approval step the public record does not describe. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged, so IAM grants, Agent Identity and VPC Service Controls remain the reach controls beneath it.

Deployments are in pilot. For this page's question, a pilot on the reader's own Google Cloud workflow would show, for one agent and one dataset, which values the model received as tokens, which it never needed, and which actions reached a named approver, producing the record of model input that the IAM report and the perimeter cannot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on Google Cloud's own documentation: the Gemini Enterprise Agent Platform page on managing access for deployed agents, the IAM Agent Identity overview, the Gemini Enterprise page on access controls for custom data sources, the Model Armor integration page for Gemini Enterprise, the best practices for service accounts, and the Google Cloud blog announcement of the new Gemini Enterprise (vendor documentation). It also draws on press coverage from The New Stack of the April 2026 rename and from IT Brief of the June 2026 VPC Service Controls update (press), and on the MIT AI Agent Index entry for Gemini Enterprise (research dataset). All sources were read as of October 16, 2026.

No hands-on testing of the Gemini Enterprise Agent Platform, Agent Identity, VPC Service Controls or Model Armor was performed. "Not described in the pages reviewed" concerns the documentation consulted, not a claim that the product lacks a capability. The VPC Service Controls update is described from press coverage, not from Google documentation, and should be confirmed against current Google pages. The rename from Vertex AI is stated as the sources report it. Google's documentation changes frequently, and the page carries its date for that reason. Statements about RedactSure describe its current design, with deployments in pilot. The customer records table, BigQuery dataset and project examples describe record types and configurations, not any organization; no customer or prospect is described.

Whether a given set of IAM grants, perimeters, screening policies and approval mechanisms satisfies an organization's obligations is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Google states the rule plainly: deployed agents have access to all resources their service account has permission to access. The confidential data a Gemini Enterprise agent can reach is therefore an IAM question, answered by the roles bound to the identity each agent runs as, and an agent on a project's default service account can reach whole projects. Agent Identity makes per-agent scoping practical, VPC Service Controls can now, per press coverage, include agent identities in perimeter rules, and Model Armor screens prompts and responses. None of these, in the pages reviewed, changes what the model reads from a resource once it is in reach, and the public record documents no built-in approval requirement for agent decisions. The test is to name one agent and one dataset, pull the roles bound to the agent's identity, obtain the rows and columns the model received for one task, and ask which of them the task used.

Frequently asked questions

Is Vertex AI the same thing as the Gemini Enterprise Agent Platform?

Per the sources reviewed, yes in substance. The New Stack reported in April 2026 that Vertex AI has now evolved into the Gemini Enterprise Agent Platform, and Google's announcement describes the new Gemini Enterprise as one platform for agent development. Agents deployed under the Vertex AI name run under the same service account rule, and controls announced after the rename apply to them only when configured. Documentation under both names describes the same deployments, so a reader should check both when tracing a control.

What decides how much data a deployed agent can reach?

Its service account. Google's documentation states that deployed agents have access to all resources that their service account has permission to access. An agent on a dedicated identity with minimal roles reaches only the datasets its tasks need; an agent on a project's default service account with broad roles reaches whatever the project holds. Google's own service account best practices counsel dedicated accounts and minimal roles for exactly this reason.

What does Agent Identity add?

A strongly attested, cryptographic identity for each agent, with permissions granted directly through IAM, according to Google's overview. It lets an agent stop borrowing a shared service account, so grants can be scoped per agent and the IAM report can answer the reach question agent by agent. It narrows reach when used with minimal roles. It does not change what the model reads from a resource the agent is permitted to access.

Do VPC Service Controls stop agents from reaching confidential data?

They can constrain it. Press coverage of a June 2026 update reports that Google added agent identities to VPC Service Controls ingress and egress rules, so a perimeter can keep an agent from reaching resources outside it or from moving data out. The control operates on resources crossing a boundary. Within the perimeter, an agent permitted to read a dataset reads all of it, and the update should be confirmed against current Google documentation.

Does Model Armor protect confidential data from the agent?

Google documents Model Armor as screening user prompts to and responses from AI agents. It inspects conversation text in flight and can block or flag content matching its policies. What the agent reads from a data source while composing a response is not what the documentation describes it as screening, so it is a control on the conversation rather than on the model's input from the organization's data.

Does the platform require approval before an agent acts?

The MIT AI Agent Index entry for Gemini Enterprise records no approval requirements found for any decision type, and notes that users can pause or stop an agent. That reflects the public record rather than every deployment. Perimeter egress rules can stop data leaving; a named person approving a specific action before it happens is not described in the pages reviewed, so an organization that wants that gate has to build or supply it.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.