CLOUD TOOLS · IAM · LEAST PRIVILEGE
Cloud tools: keep the agent service role least-privileged
Give an agent service account a role, let an injected instruction ask for destructive calls, and see what the role allows beyond the job.
Your experiment
The agent must read one input object and write one report. Start with the owner role and an injected instruction in the input, then step down through project-wide storage roles to bucket-scoped grants, and switch the overwrite and the injection on and off.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Teaching model of IAM decisions, not a Google Cloud client. It checks only storage.objects get, list, create and delete per bucket and setIamPolicy on the project, and treats each predefined role as that subset; real roles contain more permissions, and conditions, deny policies and inheritance are omitted. No project is contacted.
An owner role runs whatever it is asked
The agent reads gs://acme-data/input.csv and writes a summary into the acme-reports bucket, replacing the existing summary.csv. With Role granted to the agent service account set to roles/owner on the project both tasks succeed, but input.csv contains an instruction to delete a customer file in acme-prod and to grant roles/owner to an outside account. The model turns it into two tool calls and the owner role allows both: OVER-PRIVILEGED EFFECT with 2 injected effects and 5 unneeded write grants.
Narrower roles that are still too broad
storage.objectAdmin on the project has no project IAM permission, so the setIamPolicy call is denied, but the delete in acme-prod still runs: 1 injected effect and 4 unneeded write grants. objectViewer plus objectCreator cannot delete anything, so both injected calls fail; but replacing summary.csv also needs storage.objects.delete, because Cloud Storage requires delete permission to overwrite an existing object. The report write is denied: REQUIRED TASK DENIED. Clear The report replaces an existing object and the job succeeds, yet create on acme-data and acme-prod remain 2 unneeded write grants: EXCESS WRITE ACCESS.
Scope the grant to the buckets
Per bucket: viewer + creator, objectViewer on acme-data and objectCreator on acme-reports, still cannot overwrite. Per bucket: viewer + objectUser keeps objectViewer on acme-data and gives objectUser on acme-reports, which grants get, list, create and delete on acme-reports only: both tasks succeed, both injected calls are denied and there are 0 unneeded write grants: LEAST PRIVILEGE HELD. Without the overwrite, delete on acme-reports becomes the one unneeded write, and the creator-only scope is exact instead.
No injection, same verdict
Clear input.csv carries injected instructions. The owner role now causes no harmful effect in this run, yet the review still fails with 5 unneeded write grants: EXCESS WRITE ACCESS. Least privilege is judged by what the account could do, not by what one run happened to do; the injection only demonstrates the consequence.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through the grant, the injected input, each tool call, the permission review and the verdict across sixty inspection seconds; the table lists every call with the permissions it needs and the decision. The model checks get, list, create and delete on three buckets and setIamPolicy on the project, and treats each predefined role as that subset. Real roles contain more permissions, and IAM conditions, deny policies and inheritance from folders are omitted. Check the IAM roles reference before granting.