An emergency-management coordination agent on Google Cloud reads incident PDFs from a handful of Cloud Storage buckets, and the security team wants its access limited strictly to those buckets and the read permissions it actually needs. Which approach best satisfies this requirement?
Select an answer to reveal the explanation.
Short Explanation
Think of a service account like a badge you hand an employee: the fewer doors it opens, the less damage a lost badge does. A dedicated, narrowly-scoped service account per agent means one compromised or buggy agent only ever touches its own buckets. Sharing one broad badge across every agent turns a single mistake into a citywide incident.
Full Explanation
Least privilege means an agent's identity carries exactly the permissions its job requires, nothing held in reserve for convenience. A dedicated service account scoped to the specific incident-PDF buckets, with read-only roles where write access is never used, keeps the blast radius of any bug or prompt-injection attempt confined to those buckets. Reusing a shared, broadly-scoped automation account fails because every agent riding on that identity inherits its full reach, so a flaw in one workflow exposes data far outside its own job. Granting a project-wide admin role fails the same test at a larger scale: it trades a rare future convenience for a permanent standing risk. Authenticating as whichever staff member deployed the agent conflates a human's personal access with an autonomous system's operational identity, which breaks audit trails and ties the agent's access to a person's role rather than its function. A scope caveat worth noting: permissions should be revisited whenever the agent's task set changes, not set once and forgotten. As an operational check, an architect can list the IAM bindings on the agent's service account and confirm every listed permission maps to a bucket the agent actually reads.