Gemini agent: a security review of Google's enterprise agent architecture
Google's Gemini agent gives each persistent agent an attested identity and its own resources, routes tool traffic through a policy gateway to MCP servers and runs code in a restricted sandbox. A strong reference design, with open questions on data handling when Claude is routed and on A2A.
In brief
- Persistent coworker agents get their own Workspace account, mailbox, calendar and Drive, with a cryptographically attested identity.
- Agent Gateway enforces policy on agent traffic; Agent Sandbox runs code in isolated containers with restricted egress.
- Smart Routing picks between Gemini and Claude models; residency and retention terms for Claude routing aren't disclosed.
- MCP is the tool plane ('any MCP server'); A2A is absent from coverage.
What was announced
At Gemini at Work 2026, Google Cloud announced a single “universal agent for work” that runs across Workspace, Microsoft 365, Slack, the CLI and a headless API. Persistent coworker agents get their own Workspace account, mailbox, calendar and Drive, with a cryptographically attested identity. Agent Gateway enforces policy on agent traffic, Agent Sandbox runs code in isolated containers with restricted egress, and Smart Routing chooses between Gemini and Claude models. It’s in private preview, with no per-seat licence for coworker agents.
Architecture
Security assessment
The important shift is from an agent acting on the user’s OAuth token to an agent as a separate principal. The agent has its own directory entry, sees only what is shared with it, and every action is attributed to it. That’s the right model for audit and least privilege, and it mirrors how service accounts went mainstream.
| Control | What Google describes | Assessment |
|---|---|---|
| Identity | Own Workspace account, attested identity | Strong: actions attributable to a non-human principal |
| Data access | Sees only what’s shared with it | Least privilege by default, if sharing is managed |
| Tool egress | Agent Gateway applies policy on traffic | The chokepoint most agent deployments lack |
| Code execution | Isolated containers, restricted egress | Good; isolation technology not stated |
| Audit | Actions tied to the agent identity | Enables per-agent investigation and revocation |
| Model routing | Gemini or Claude per task | Residency and retention terms for Claude not disclosed |
| Agent-to-agent | Not mentioned | A2A absent; MCP is the tool standard |
It also creates a new problem: identity lifecycle for non-human coworkers. Provisioning, offboarding, permission drift and orphaned agents will need the same discipline as service accounts, at a larger scale. And routing to Claude inside a Google product shows model choice moving below the product layer; Google says prompts and documents stay inside Gemini Enterprise, but hasn’t published residency and retention terms for routed calls.
Where it fits
A2A, Google’s own interop protocol, is missing from the announcement coverage while MCP is front and centre. That suggests that in 2026 the tool-plane standard is settled and the agent-to-agent standard isn’t. The gateway-on-egress design is also the control that this week’s containment disclosure argues every agent deployment needs.
What to do
Recommendation (opinion): evaluate if you’re a Workspace shop. Ask for the preview, and ask specifically about the identity attestation format, the gateway’s policy language and data handling when Claude is routed. Everyone else should copy the pattern: identity per agent, a gateway on egress, a sandbox for code, per-project spend caps and action-level audit.