Identify the principal, action and enforcement evidence together
The same visible agent can act under different authority. This matrix distinguishes the current per-agent platform principal from the separately announced Workspace coworker account after rechecking Google identity and gateway documentation on October 14; it does not claim that every Workspace surface exposes these Agent Platform controls or that an enforcement test has been run.
| Authority record | Action represented | Administrator control or evidence | What the record proves |
|---|---|---|---|
| Agent acting as itself | A per-agent Agent Identity principal performs a permitted platform action | Google documents a unique SPIFFE-formatted workload principal and role-based authorization | Attribution to the agent principal; not universal Workspace availability or business approval |
| Workspace coworker account | The announced Workspace coworker can receive an account, email, calendar and Drive presence | This is a separate Workspace surface; it does not establish that every Workspace action uses Agent Platform SPIFFE identity | Account provisioning is not proof of a completed permitted action or universal rollout |
| Agent acting for a user | A tool request uses user-delegated access | Authentication Manager brokers credentials; documentation describes OAuth delegation and revocation | Which user's authority was used; access still does not prove the action was approved for this workflow |
| Internal proposal | The agent drafts or suggests a change without applying it | Human review and a system-of-record status remain necessary | A proposed next step, not execution or completion |
| Audit-only gateway | Traffic is permitted while the configured gateway records it | IAP does not enforce IAM policies in audit-only dry-run mode | Observation and attribution; not evidence that a prohibited request would be blocked |
| Enforce-policies gateway | A request lacking an explicit Allow policy is refused | Administrator-configured enforcement plus the retained refusal result | Evidence of that configured boundary for that request; not a blanket security or compliance guarantee |
| Project spending cap | Agent API calls pause when the documented project cap is reached | Project-specific billing configuration, resume and overage choices | A scoped cost control; not a universal cap, rollout entitlement or savings result |
By Inquory Research
Published October 9, 2026. Sources checked October 9. AI-assisted research and drafting; editorially reviewed. Inquory has not tested the announced agent, a customer account or its enforcement controls.
Google announced a universal Gemini agent for enterprise work on October 8, describing a service that can carry out delegated tasks in the cloud and act as a Workspace coworker under its own identity. For a team deciding whether to hand over a workflow, the immediate distinction is between assigning an outcome and establishing the authority used to perform it.
What Google announced October 8
The Google Cloud post, adapted from CEO Thomas Kurian's Gemini at Work keynote, presents one agent for questions, knowledge work, media creation and coding. Google says tasks can continue after a laptop closes. Its Workspace account describes personal assistance, suggested delegation and a coworker agent with its own account; for that coworker, Google says access follows what the team shares. These are vendor descriptions, not observed behaviour in an Inquory test. October 8 announcement
The announcement also describes attributed agent activity, role-based authorization, sandboxing and a network gateway. It says project spending caps can pause an agent. We have not verified account rollout, Canadian availability, contractual scope or those controls in operation.
Inquory interpretation: a persistent worker creates an accountability question that a chat answer does not settle. Someone must identify the acting principal, approve the intended actions and review the resulting changes, including work completed while that person is away. A recognizable agent name in a conversation is a starting point for that record.
An agent identity and delegated user access are separate records
Google's Agent Platform documentation describes Agent Identity as supporting both an agent acting as itself and an agent acting on behalf of a user. Its authentication manager brokers outbound credentials, supports OAuth delegation and records access attribution. The guide also describes revocation of user-delegated permissions. This is documentation for the platform's identity mechanism, not confirmation that every announced Workspace surface exposes the same configuration. Agent Identity overview
For a team, the useful question is which authority a particular action uses. A file edit under an agent's own account, a tool request made with a user's delegated access and an internal proposal awaiting human acceptance should have separate entries in the team's record. Access to one source does not by itself establish approval to send its contents elsewhere. This distinction is our analysis, not an additional Google product promise.
A log does not demonstrate that a restriction was enforced
Google's Agent Gateway setup guide explicitly distinguishes two configurations. Audit-only permits traffic and generates logs without IAP enforcing IAM policies in that dry-run mode. Enforce policies blocks requests without an explicit Allow policy and is recommended there for production. The guide carries an October 8 UTC update. Gateway setup documentation
That is a distinction within an administrator-configured platform gateway. It does not establish a contradiction with the October 8 managed-agent announcement or prove the configuration of any company's Workspace agent.
Inquory interpretation: evidence of a recorded action answers an observation question. Evidence that an attempted action was refused answers an enforcement question. An approved evaluation should record both an expected allowed action and an expected refused action using fictional, non-sensitive material. These are proposed acceptance criteria; Inquory has not performed either test. This article provides no permission-change or deployment instructions.
Product eligibility and spending controls need their own scope
The developer-tool guide, updated October 8 UTC, has separate edition, invoiced-billing and regional conditions. It also says the Gemini Enterprise Admin role alone does not grant use of AI developer tools. Those requirements concern that feature; they are not a universal eligibility list for everything announced October 8. Developer-tool scope
The October 8 post links to billing background published August 26. That older article still qualifies pay-as-you-go app access as available to selected customers with broader rollout ahead, and deferred execution pricing as coming soon. It describes project caps that pause agent API calls, with separate resume and overage choices. Treat that page as background and obtain the terms applicable to the actual project before relying on a spending limit. Billing background
Fictional example: a draft estimate stays an internal task
Amina coordinates a fictional Canadian repair business. She wants an assistant to turn an internal job note into a draft estimate. Her proposed acceptance record identifies the approved test folder, the identity expected to produce the draft and the person who reviews it. It also specifies that the evaluation must not contact a customer or change a live record.
She separates three questions: did the draft reach the reviewer, did the record attribute its actions to the expected identity, and did the designated restriction refuse an out-of-scope request? A plausible draft leaves the latter checks unfinished. This is a fictional decision aid, not a customer result, available Canadian rollout or tested configuration.
For a small service business, this helps keep responsibility attached to the handoff: drafting, approving and communicating are different actions. No time savings, failure rate or traffic improvement is measured here.
What remains unresolved
All five sources are Google publications. They support an announcement and documented component behaviour; they do not independently establish reliability, an enabled account or successful enforcement. We have not established a complete edition-by-edition or region-by-region rollout schedule for the newly announced agent.
Google's enterprise-agent description should not be used to rewrite the separate personal-account, Workspace skills or Studio migration notices covered in our earlier report. The product and surface must be identified before treating a notice as applicable. A document's update date does not establish feature activation.
Related reading
- Account and flow boundaries in the Gems-to-skills migration.
- Test a CRM handoff before relying on an AI workflow.
- Keep a record of workflow changes and retesting.
Planned image credit: AI-generated editorial illustration — Inquory. The image is a conceptual depiction of identity, logging and a permission boundary, not Google software or a tested system.