A housing authority casework agent needs Cloud SQL write access, but the design must limit that access to only the specific tables it manages, not the full database used by other city departments. Which approach satisfies this?
Select an answer to reveal the explanation.
Short Explanation
Handing an agent write access to the whole database and trusting its own code to behave is like giving someone the master key to every office and just asking them nicely to only open their own door. Scoping permissions to exactly the tables the agent manages removes the need to trust that promise at all. A shared cross-department account or a content filter on the agent's replies don't touch the actual permission boundary in the database.
Full Explanation
Scoping the agent's data-layer permissions to only the specific tables it manages enforces the boundary where it actually matters, inside the database's own access controls, so a bug, a bad prompt, or unexpected agent behavior cannot reach tables outside its job even if it tries. Granting broad write access to the whole database and relying on application logic to self-restrict puts the entire safeguard inside code the agent itself runs or is influenced by, which is exactly the kind of soft boundary that a reasoning error or injected instruction can defeat, since nothing outside that logic stops an out-of-scope write. Reusing a shared cross-department service account solves a provisioning convenience problem but does the opposite of what's asked: it grants this agent access to whatever that shared account can reach city-wide, which is broader, not narrower, than its own casework tables. A Model Armor content filter screens conversational content for problems like manipulation or leakage; it has no connection to database write permissions and wouldn't prevent or even necessarily notice an out-of-scope write actually happening at the data layer. A scope caveat: table-level scoping needs to be revisited whenever the agent's managed table set changes, since a stale grant list either blocks legitimate work or leaves unused access lingering. As an operational check, an architect can attempt a write from the agent's identity against a table outside its managed set and confirm the database rejects it.