Here is a failure that looks fine right up until it is a headline. A team builds a tool that lets an agent query the customer database. To make development easy, the tool runs with a credential that can read every customer record. The agent is only supposed to look up the one customer in front of it. Nothing in the setup enforces that limit. The day an agent, through a clever prompt or a chained mistake, asks the tool for everything, the tool happily complies, because the credential it holds was never scoped to the task. The control failure was not in the agent. It was in handing the tool more power than the job required.
This is the credential-scope problem, and it is one of the sharpest risks MCP introduces. Tools connect to real systems with real credentials, and if those credentials are broad, then calling the tool means borrowing all of that breadth.
Two access decisions, not one
The fix begins with separating two questions that are easy to blur. The first is whether an agent may use a tool at all. The second is what the agent may do with the tool on this particular call. Most setups answer only the first and treat the second as unlimited. Governed tool calls answer both.
Deciding whether an agent may use a tool is identity and policy work: the request is evaluated against the user and agent identity, their role, and their purpose, against the tool's risk. That gets you to "yes, this agent may call this tool." Scoping the call is the second decision: given that the call is allowed, the credentials, the resources, and the parameters are constrained to what the approved purpose actually needs. The agent that should look up one customer gets a call scoped to one customer, not a credential that could read the table.
Scoping the parameters, not just the credential
It is worth being precise about what gets scoped, because credentials are only half of it. The credential controls which system the tool can reach and with what standing. The parameters control what the specific call asks for. A governed tool call constrains both. Even if the underlying credential could in theory reach more, the call is shaped so that it asks only for what the purpose justifies. This is the difference between trusting the agent to ask nicely and enforcing the boundary regardless of what the agent asks.
This is least privilege applied at the finest grain available: not per user, not per agent, but per call. And it maps directly onto purpose-based access control, because the scope of the call is derived from the purpose of the request. The purpose is what tells the system how narrow the credential and parameters should be.
Centralizing credentials instead of scattering them
There is an operational dimension that makes scoping practical rather than theoretical. If every tool and every project holds its own provider credentials, scoping is impossible to enforce consistently, because the credentials are everywhere and controlled nowhere. Centralizing credentials, holding them in one governed place rather than embedding them across applications, is what gives you a single point to apply and enforce scope.
This is the same architectural instinct behind the LLM gateway, which centralizes model credentials and routing so that access to models is controlled in one place rather than scattered across projects. Tools deserve the same treatment. When credentials live in one governed vault and calls are scoped at the point of use, you get least privilege you can actually prove, instead of least privilege you merely hope for.
Why this is worth the effort
Scoping credentials and parameters is more work than handing a tool broad access and trusting the agent to behave. The payoff is that you remove an entire category of incident from the table. An agent cannot exfiltrate a whole database through a tool that is scoped to one record per call. It cannot take a broad destructive action through a credential that only permits a narrow one. The blast radius of a mistake or a manipulation shrinks to the size of the approved purpose, which is exactly where you want it.
The registry tells you which tools exist and how risky they are, which is covered in the tool registry. Scoping is how you make sure that even an approved call stays inside its lane. Together they are most of what makes agent tool use safe, and the full picture is in the complete guide to MCP governance.