A transit agency's trip-planning agent needs to read public schedule data, but the same Google Cloud project also stores internal HR records for agency employees. How should the architect scope the agent's Agent Identity to prevent the trip-planning agent from ever touching HR data?
Select an answer to reveal the explanation.
Short Explanation
Think of Agent Identity like a keycard system: you don't trust an employee to just not walk into the server room, you make sure their card simply doesn't open that door. Scoping the trip-planning agent's identity to explicit read access on schedule data - and no granted access to HR resources - means there's no door to walk through in the first place, not just a policy telling the agent to behave. A system instruction asking it nicely, or a shared dataset, doesn't create that same hard boundary.
Full Explanation
Least-privilege scoping through Agent Identity works by granting explicit permissions to exactly the resources a task requires and leaving everything else ungranted, so the trip-planning agent's identity should carry read access to schedule data and nothing more - it should have no path to HR records no matter what it's asked to do, because the permission boundary itself, not the agent's judgment, is what prevents the access. Relying on the system instruction to tell the agent not to answer HR questions is a behavioral request layered on top of whatever the underlying identity can technically reach; a prompt injection, a reasoning error, or a tool call outside the intended flow can bypass an instruction in a way it can't bypass a missing grant. Co-locating HR and schedule data under one dataset with a single shared permission policy actually works against isolation, since it makes it harder to grant access to one without also granting access to the other. Configuring Agent Gateway to log HR-endpoint traffic is a useful detective control for spotting unauthorized attempts after the fact, but logging doesn't prevent the access - it only reveals when the preventive boundary already failed. The scope caveat: least-privilege scoping needs revisiting whenever the agent's task set grows, since a new tool added later can silently widen its effective reach if its identity isn't re-scoped. A concrete check: attempt to have the trip-planning agent query an HR resource in a test environment and confirm the request is denied at the identity layer, not merely declined by the model.