Google Gemini Agent and the Boundaries of Enterprise Authority

Asking an assistant to summarize a project update is one kind of delegation. Letting the same assistant read the project history, create a spreadsheet, write code, schedule follow-up work, and ask temporary sub-agents to finish parts of the job is another.

Google’s newly announced Gemini agent brings those activities into one persistent work agent. Google describes a system that can answer questions, run code, use enterprise tools, continue tasks for hours or days, and move between Workspace, Microsoft 365, Slack, command-line tools, desktop applications, and headless integrations. Google’s Gemini agent announcement

The product idea is appealing: one place to delegate an outcome instead of repeatedly briefing separate assistants. It also concentrates context, identity, memory, and authority in a way that deserves closer examination.

This analysis is based on public Google material available on October 8, 2026. It is not a hands-on product test, tenant configuration review, or vulnerability assessment. Product behavior may depend on edition, administrator policy, connector, channel, and later documentation.

One agent across many surfaces creates one large trust boundary

Gemini agent is presented as a single agent available through web and mobile apps, desktop systems, command-line tools, Workspace, Microsoft 365, Slack, and third-party applications. The same context and personalization follow the user between those surfaces.

Continuity removes friction, but it also connects environments that organizations often govern differently. A conversation in an internal Workspace document, a request from Slack, and a headless event from an external application do not necessarily deserve the same data access or ability to act.

The security question is therefore larger than whether each connector authenticates correctly. It is whether the agent can preserve the origin, audience, and policy context of a request as work moves from one surface to another. A valid identity does not automatically make every request equally trusted.

Persistent memory changes what “disconnect” needs to mean

Google describes four forms of memory: session memory for current work, semantic memory built from documents and interactions, procedural memory for how work is performed, and episodic memory of earlier activity. It also says the agent can keep working after the user’s device is closed.

Those capabilities are useful precisely because the system does not start from zero each time. They also make revocation more complicated than ending a chat. When a connector is removed or access to a document changes, the relevant question is not only whether a future fetch will fail. Earlier content may already have influenced a project, a generated skill, an active task, or a delegated sub-agent.

This is not evidence of a Gemini defect. It is a lifecycle question for any agent that combines long-running work with learned context: which derived state remains, which queued work stops, and how quickly a permission change reaches every copy of the task?

A sub-agent identity improves attribution, not judgment

Gemini can create temporary, task-specific sub-agents. Google also describes persistent coworker agents with their own company email address, storage, and organizational presence. Dedicated identities are a meaningful improvement over an agent silently acting as a person; logs can show which agent performed an action, and permissions can be attached to that identity.

Identity alone does not settle whether a delegated action was appropriate. A parent agent may divide one objective into many smaller tasks, pass context to a sub-agent, or increase the number of systems involved. The resulting risk depends on what was delegated, how long the delegated authority lasts, and whether the parent can grant access it should not be able to extend.

The useful audit record is therefore more than “agent B sent the message.” It also connects agent B to the parent objective, the context it received, the policy in force, and the person or team responsible for that delegation.

Tools, skills, and MCP turn configuration into a supply-chain question

Google says Gemini agent can use an enterprise tools registry, shared and personal skills, common business systems, databases, desktop files, Git, Jira, and MCP servers inside or outside the company network. Skills may contain instructions and workflows, and the system can build procedural knowledge from earlier work.

This flexibility makes the tool catalog part of the production trust boundary. A connector can be correctly authenticated and still expose an operation whose scope is too broad. A skill can be useful when created, then become unsafe after a downstream API or business process changes. An external MCP server adds another implementation, operator, and update path to the chain.

Central registries make discovery and administration easier, but registration is not the same as validation. Provenance, version changes, requested permissions, data destinations, and revocation behavior determine whether a tool remains safe to use after it enters the catalog.

Agent Gateway and Sandbox are meaningful architectural claims

Google describes a dedicated identity for each agent, fine-grained role-based permissions approved by security administrators, OAuth-based identity propagation, and audit trails attributed to the agent. It also says tasks execute inside an Agent Sandbox with a network boundary and that traffic between agents and external systems passes through Agent Gateway. The platform update describes Model Armor protection for prompt injection, tool poisoning, and data leakage. Google’s governance description · Agent Platform update

These controls address the right layers: identity, authorization, execution isolation, network policy, and inspection. Their effectiveness still depends on configuration and coverage. A gateway can only enforce the policies it receives, and a sandbox boundary does not decide whether an approved business action is sensible.

For example, sending an email may be allowed. Sending it to a recipient introduced by untrusted document content may not be. The difficult control is often bound to the details of the action — recipient, destination, amount, repository, or data classification — rather than the tool name alone.

A spend cap controls cost, not every form of blast radius

Google says a project-level spend cap can pause an agent when token and sandbox costs reach a configured limit. That is a concrete operational boundary and especially relevant for persistent or multi-agent work.

Financial cost is only one dimension of blast radius. A low-cost action can still send sensitive information, overwrite a record, merge the wrong change, or contact a large audience. Long-running agents add other dimensions such as action count, duration, fan-out, destination scope, and repeated external effects.

A project can remain under budget while causing a consequential business error. Cost limits and action limits answer different questions; mature deployments need visibility into both.

Model routing makes the agent more stable than its underlying model

Google separates the Gemini agent from the model used for each task. The platform can route work across Gemini models and Anthropic’s Claude models, with more model choices planned. This can improve cost and task fit while allowing the user’s context, tools, and skills to remain in place.

It also means the named product is not a single, fixed inference behavior. Two tasks within the same project may be handled by different models, and routing can change over time. A regression may come from the model, the routing policy, a skill, a connector, or the orchestration layer.

Google’s Agent Platform offers evaluation and observability on a shared engine, including online monitoring and execution traces. For those records to support incident analysis, they need to preserve which model and policy version handled each step, not only the final agent name.

Audit trails matter most when something was blocked

Google says every action is written to an audit trail and attributed to the agent identity. That can answer an important question after an incident: which non-human actor touched a system?

The more difficult reconstruction includes attempted actions, gateway denials, approval changes, sub-agent creation, tool arguments, and the context that shaped the action. Successful calls alone show what happened, but blocked and abandoned calls often reveal what nearly happened.

Retention and export matter as well. If the evidence needed to investigate an event lives only inside the same administrative boundary being reviewed, organizations may struggle to preserve it during a serious incident.

The adoption question is about authority, not intelligence alone

Gemini agent’s public architecture is unusually explicit about identity, sandboxing, centralized policy, observability, and cost controls. That is a stronger starting point than treating an agent as a chat interface with a collection of API keys.

The unresolved questions are deployment-specific. They include how permission changes reach active tasks and memory, how destructive approvals are bound to the exact action, how sub-agent delegation is limited, how external MCP tools are governed, and how retries avoid duplicate side effects. Public architecture material can identify these questions; only tenant configuration and execution evidence can answer them.

The central product decision is not whether a universal agent is intelligent enough to complete more work. It is how much authority should remain continuous across devices, applications, models, memories, and delegated agents — and whether that authority can still be narrowed, observed, and withdrawn when the situation changes.

Related resources: Production Guardrails for AI Agents, the Production Readiness Checklist, and the Agent Production Starter for customer-owned tool adapters.