Google’s October 8 Gemini announcement is less about a smarter chatbot than about who is allowed to act inside a company. In a Google Cloud blog post adapted from Thomas Kurian’s keynote, Google said Gemini can operate inside Workspace and that its security layer includes identity and policy management. TechCrunch reported that Google said the agent will have its own Workspace account and email address, plus an audit trail as it takes action.
Why identity matters
The important shift is that agent capability now depends on the same question enterprises already ask about humans, service accounts and robots: what can this entity access, and who can stop it? A model that can write, search and schedule is useful; a model with delegated authority is operational. Once an agent can read calendars, open documents and trigger downstream work, its identity becomes the boundary between assistance and automation. That boundary determines whether a task is merely recommended or actually executed.
This is why Google’s framing matters more than any single benchmark. A company can compare models on answer quality all day, but deployment breaks on access control. If an agent borrows a human credential, it becomes hard to revoke cleanly, hard to audit and easy to overprivilege. If it gets its own account, the enterprise can apply least-privilege access, track action ownership and isolate the blast radius when something goes wrong. The operator also needs a queue for requests that exceed those permissions, with an owner assigned to approve or reject them.
What enterprises should test
A rollout team does not need to believe vendor claims to evaluate the architecture. Four concrete tests would tell you whether the system is ready for real work. First, try to make the agent read a file outside its project scope and confirm that access is rejected. Second, revoke the agent account while a task is in progress and verify that execution stops rather than hanging on inherited permission. Third, delegate a task to a sub-agent and check whether the child action inherits only the intended context, not the parent user’s full workspace. Fourth, inspect the logs to see whether the action is attributed to the agent identity, not the human who triggered it. Those are not performance tests; they are governance tests.
That distinction will matter most to finance, legal, operations and IT teams. These groups do not need every AI system to be autonomous. They need systems that can be bounded. A procurement review should ask whether the agent has a named identity, whether that identity is revocable without breaking other workflows, and whether the audit record is detailed enough to reconstruct what happened after the fact. If the answer to any of those is unclear, the right deployment pattern is a supervised assistant, not a coworker-like agent.
There is also a strategic implication in the business-first rollout. TechCrunch reported that Google is initially focusing on businesses rather than consumers because the harder problems are security, scale and performance. That is plausible, but our interpretation of the product bet is this: if companies accept identity-aware agents inside their systems, Google can use enterprise workflows as the proving ground for more autonomous behavior later. The upside is cleaner governance and better attribution. The trade-off is that every new permission tier becomes a new policy decision, which slows deployment and raises the cost of mistakes.
So the core change is not that Gemini can now do more work. It is that Google is trying to make the agent itself a governed workplace actor, with identity as the mechanism that turns AI output into accountable action. A pilot should record which connector actions are enabled, who owns permission changes, and how the team will respond to a denied request.
A useful pilot would also define the failure response before connecting production data. For example, a task that drafts a purchase request could use a test account and a mock approval queue. The team could record the expected destination, permitted fields and authorized approver, then compare the attempted action with those limits. A missing or ambiguous authorization should leave the request pending. This is a proposed evaluation design, not evidence that Gemini passes it. Its value is a clear acceptance record: the organization can distinguish a successful draft from an authorized submission, and an authorized submission from a completed purchase.
Before approving a Gemini rollout, test whether the agent can be granted, revoked and audited like a real account; if it cannot, keep it in a narrow pilot.
