Leadership1 publisher3 min readPublished
Google Cloud's security office says an agent ban pushes employees toward less secure automation
Two security advisers in Google Cloud's Office of the CISO argue that prohibiting AI agents drives staff into running their own, and they put identity and access management ahead of every other control.
The Board Room · Leadership desk
What happened
- Two advisers in Google Cloud's Office of the CISO name the 2026 threat actor as the helpful AI agent a lead developer gave administrator access to automate what they called some boring stuff.
- The first of its four recommendations is to define an agent's scope before it runs, covering the APIs it may call, the systems it may touch, the data it may modify, and whether it acts in dev, test or production.
- For enforcement the authors point to policy-as-code and rollback infrastructure, naming Google Cloud's Policy Controller and Config Connector as the tools to govern component interactions.
Compiled by The Board RoomSomething wrong?How this is made
Why it matters
- cost Permitting agents moves money and headcount into per-agent scoping and provisioning review, and the security team pays that before any productivity gain shows up in a business unit's numbers.
- constraint Once prohibition is ruled out, a team that cannot issue narrowly scoped agent credentials is left with detection after the action. Over unapproved software, that team held a stronger position.
- decision Somebody has to be named as the owner of permissions for an agent a single employee spins up. The workload-versus-workforce split forces that assignment onto an org chart that currently covers only the first kind.
- precedent When the enforcement layer in the advice is the advising vendor's own policy engine, agent governance starts getting bought as a platform feature, and the engine gets chosen before the governance model exists.
The prohibition question is the one operators have to answer this quarter, and the post answers it against the ban. Anton Chuvakin and Marina Kaganovich wrote that "Historically, banning new technology rarely succeeds, and banning AI is even riskier." [2] Employees bypass the blockade with alternative and often less secure automation, and the resulting shadow agents create blind spots that make data access harder to monitor [4].
That is a different failure from the one shadow IT produced. The post names one problem for the shadow IT era, data leakage, someone putting a spreadsheet where it should not be [5], and three for shadow agents: autonomous action, goal hijacking and remote code execution [7][17]. Shadow AI in between added intellectual property exposure and hallucinations [6].
The credential is where the trade-off sits. Permit agents and the cost is provisioning work. Scope has to be defined before the agent runs: the APIs it can call, the systems it can touch, the data it can modify, and whether it acts in dev, test or production [11]. Block them and the cost is agents nobody can see [4]. The post also asks for defined, unambiguous goals and measurable success criteria per agent [13]. It says misconfiguration in access provisioning is already a major pain point, and managing human and agent access rights together will amplify it [16].
The organisational question hides inside the two-model split. Agentic IAM divides into workload agents, which automate core enterprise business processes, and workforce agents, which improve one employee's productivity on individual tasks, and the authors write that the two models sometimes mix [10]. Workload agents land in territory that already has change control and a platform owner. Workforce agents do not. The post does not say who owns a workforce agent's permissions.
This is a cloud vendor's security advisory, and its enforcement path runs through the cloud vendor's own products: policy-as-code, with Policy Controller and Config Connector named for governing component interactions on Google Cloud [15]. Fair on the tooling. The sequencing is a separate matter, and it does not depend on who sells the policy engine. The recommendation is to govern and deploy agentic tools with the same rigor applied to human-managed accounts, cloud infrastructure and enterprise software [8], and to start with identity and access management [9].
The rest of the programme comes later. It covers integration points across multi-agent systems, runtime policy enforcement, and rollback infrastructure that automatically halts AI operations across systems when unexpected behaviour is detected [14]. Most organisations will start that build after they have decided who may issue an agent a production role. An agent given standing administrator rights this quarter is the agent whose scope somebody has to retrofit when the rollback design arrives. The post's own framing puts the developer who granted that access at the centre of the 2026 threat model [3].
What to watch
- Follow-on guidance covering agents that individual employees provision, the point where the post says the two IAM models mix.
- Whether other identity vendors adopt the workload-versus-workforce agent distinction in their own access products.
- A disclosed incident in which an agent's own production credential, not a stolen human one, was the entry point.