A coworker agent’s own email address is not an access-control model
Google’s Gemini agent can work across business systems and spawn coworker agents with their own identities. Teams still need task-scoped grants, expiry and replayable action logs.
What happened
Google Cloud introduced the Gemini agent on 8 October as a universal work agent that can plan tasks, use tools and return finished work inside enterprise applications.
Why it matters
An agent identity helps attribution, but it does not by itself limit what the agent may read, change or send. Delegated work needs a narrower control envelope than a standing employee account.
Google Cloud introduced the Gemini agent on 8 October, saying it can plan work, use tools, connect to business systems and return finished outputs in documents, inboxes and developer environments. Reuters reported that the service works across Google Workspace, Microsoft 365 and Slack, and that users can create “coworker agents” with their own email address and access to assigned information. The release establishes product scope, not proof that these controls prevent over-broad delegation or mistaken actions in production.
Bind authority to the task
Treat the agent’s identity as the start of the control model, not its conclusion. For each delegated job, issue a task-sized grant that names permitted systems, fields and actions; require a separate approval for external messages, payments, deletions or changes to authoritative records. The grant should expire when the job ends, even if the coworker identity persists.
Log the plan, tool calls, retrieved records, model choice, approvals and final side effects in one replayable trace. A mailbox alone can show who appeared to send a message, but not which evidence the agent used or which intermediate action changed the outcome. Test revocation, stale permissions and a compromised upstream source before admitting the agent to consequential work.
The counterargument is that granular grants slow automation. That trade-off should be measured, not assumed: compare completion time with the frequency and cost of exceptions. A useful pilot passes only when the team can reconstruct one action, revoke access without disabling the whole service and prove that a completed task cannot silently retain broader authority.