A data-analysis agent is given one tool, `query_database`, so it can answer questions about sales figures. Rather than issuing that tool a database credential with full read-write access to every table, the team instead issues it a credential scoped to read-only access on just the sales tables it actually needs, with no permission to modify data or read unrelated tables such as employee records. The agent was already going to be given this one tool either way. What additional protection does scoping the underlying credential provide, beyond simply defining only one tool?
- None -- once a tool is defined at all, the credential behind it is irrelevant to what damage a manipulated or mistaken call could cause
- It prevents the model from ever generating a request to modify data, since a model cannot produce text describing an action its credential doesn't support
- It makes the tool's schema-validation step unnecessary, since a scoped credential automatically rejects any malformed tool call before it reaches the database
- It limits what a manipulated, hallucinated, or simply mistaken query_database call can actually do even after it reaches the real system, because the tool's own underlying access is capped to read-only sales data, so a call that somehow requested a write or reached for employee records would still be blocked by the credential itself, not merely discouraged by the tool's definition or the model's instructions
Why D? And why not the others?
Correct answer: D. It limits what a manipulated, hallucinated, or simply mistaken query_database call can actually do even after it reaches the real system, because the tool's own underlying access is capped to read-only sales data, so a call that somehow requested a write or reached for employee records would still be blocked by the credential itself, not merely discouraged by the tool's definition or the model's instructions
Defining only one tool scopes what the model is offered to ask for, but it doesn't by itself limit what that one tool is capable of doing once a request reaches the real system; scoping the credential behind the tool to read-only access on just the needed tables adds a second, independent layer of containment, so that even a call that was somehow malformed, manipulated, or wrongly generated still can't write data or reach unrelated tables, because the credential itself lacks that permission regardless of what the request asked for. The option claiming the credential is irrelevant once a tool is defined is wrong and is exactly the gap this defense-in-depth layer closes -- a defined tool can still be misused unless its actual access is separately capped. The option claiming a model literally cannot generate a write-style request is wrong: a model can still produce text requesting an action beyond what its credential allows; the credential is what blocks that action from succeeding, not what stops the model from asking. The option claiming schema validation becomes unnecessary is wrong: a scoped credential restricts what the query can affect once it runs, but it doesn't check whether the call's structure matches the tool's expected arguments in the first place, so validation is still a separate, still-needed step.
Source: OWASP Gen AI Security Project, LLM06:2025 Excessive Agency (genai.owasp.org/llmrisk) -- recommends per-tool permission scoping (read-only vs. write, specific resources) as a mitigation distinct from limiting which tools are exposed