Gemini Enterprise Security Controls for AI Agents, Data and Agentspace Migrations

If you are researching this now, there is a fair chance you did not pick Gemini Enterprise so much as get moved into it. The naming has changed twice in eighteen months and both changes had commercial deadlines attached.

The operational risk really is close to zero, which is exactly why the security risk is easy to miss. A rename gets filed as a marketing event. Nobody reopens the threat model for a marketing event. Meanwhile the thing being renamed absorbed a broader set of capabilities: an agent that used to answer questions over an index now registers MCP servers, holds its own identity, calls third-party connectors into Drive, Jira, Confluence and Salesforce, and can act on behalf of the person who asked. The blast radius grew while the approval that covered it stayed the same.

Three questions are worth asking against the current deployment rather than the one you signed off. First, which connectors are live, and what can the service account behind each one read? Connector scopes tend to be set once, generously, by whoever ran the pilot. Second, which agents can take a write action, meaning create, send, update, refund or delete, rather than only read? That list is usually shorter than people fear and different from what they expect. Third, when an agent acts on behalf of a user, does your audit trail record which human that was, or only that an agent did something? The answer to the third question decides whether an incident review takes an hour or a fortnight. The same re-review pattern applies on the other clouds, and we walk through it for Microsoft Foundry agent security and Bedrock AgentCore security.

This is the most interesting control Google has shipped for agents, and the one buyers most often assume is finished. It is worth reading closely because it targets exactly the problem that platform controls usually cannot reach: not who called the tool, but whether the call made sense.

Google describes it directly. Semantic Governance functions as a security check layer on agents operating across your enterprise, and it evaluates each proposed tool call, allowing only tool calls that do not violate specified policies or deviate from user intent. Two checks run: one verifies that an agent's proposed tool calls match the original semantic intent of the user prompt, and one verifies that proposed actions comply with any applicable organizational constraints. The verdict is ALLOW, in which case the action proceeds, or DENY, in which case the action is blocked.

That is a well-aimed control and the design is right. The limits are documented in the same place, and they are the reason it is not yet the whole answer.

None of that is a criticism of Google. Publishing the accuracy caveat in the product documentation is more honest than most of this category manages. It does mean that if your requirement is a deterministic, auditable, GA-supported gate on irreversible actions inside a VPC Service Controls perimeter, Semantic Governance in Preview does not yet close it on its own. A deterministic policy layer in front of the tool call handles the cases you can state as rules, and a model-based check handles the ones you cannot. Running both is not redundancy. It is the difference between a control you can explain to an auditor and one that gives you a probability.

Google is clear about the boundary, and unusually specific about prompt injection. Its guidance states that because of the inherent risks of autonomous agents, mitigating vulnerabilities like prompt injection requires a shared responsibility model, combining platform controls with secure application design. For agent-only deployments it goes further and says robust application-level defenses against prompt injection are required, because injected text tries to override the system prompt and the system prompt is yours.

Read what Google actually recommends and the shape of the work becomes obvious: the recommendations are things you build, not switches you flip. If your team builds those agents with the Agent Development Kit, the framework side of the same work, including the ADK 2.0 upgrade and where tool confirmation stops, is on our Google ADK security page.

This is a reasonable place for a cloud provider to draw the line, and Microsoft and AWS draw it in almost the same spot. The mistake is on the buyer side, not the vendor side: reading "Gemini Enterprise handles security and governance" in a launch post and concluding that agent behavior is covered. Identity, isolation, encryption and content screening are covered. Judgment is not. If you want the vendor-neutral version of the same reasoning, it is on AI agent guardrails, and the injection problem specifically is covered on prompt injection protection.

Comparison tables in this category are usually written so the vendor wins every row, which is worthless if you are the one signing the purchase order. This one marks the rows where the Google native control is the right answer and we are not. Three of six go to Google.

The honest summary: if every agent you run lives inside Gemini Enterprise, your risk model is unauthorized access rather than misdirected action, and you are comfortable waiting for Semantic Governance to reach GA, configure Google properly and stop reading. If you have agents that can spend money, change records or contact customers, or you run agents on more than one cloud, the gap is real and it is narrow and specific. It is not that Gemini Enterprise is insecure. It is that the last control, the one that decides whether this particular action should happen right now, is the one Google has explicitly not finished.