Capability
Tool and API controls
Tool and API controls govern which tools an agent may call, with what arguments, against which resources. The distinction that matters: giving an agent a tool is not the same as granting it a permission, and most deployments conflate the two until something goes wrong at the boundary between them.
A tool list is not a permission model
The common pattern is a list: this agent has the search tool, the ticket tool and the email tool. That list is silent about the three questions that decide how much damage is possible.
Which arguments
The email tool can send to a colleague or to an external address. Same tool, very different blast radius. A permission model that stops at the tool name cannot express the difference.
Against which resources
A database tool scoped to one schema and the same tool scoped to the instance are the same entry on a tool list and are not the same grant.
Under what conditions
A refund tool might be fine during business hours at low values and require a human at any other combination. Conditions are where most real policies live, and they have nowhere to go in a flat list.
The useful mental model is that a tool is a verb and a permission is a sentence. Most agent deployments have written down the verbs.
The three failure modes
| Failure | How it happens | What catches it |
|---|---|---|
| Over-broad grant | A tool is added with the credentials it shipped with, because narrowing them was extra work on a Friday | Comparing granted scope against observed use — most agents use a fraction of what they hold |
| Capability drift | A tool server adds a capability in an update. Nothing in the agent changed, and it can now do more than when it was reviewed | Detecting when a server offers something it did not offer before |
| Chained reach | Two individually reasonable tools combine into something neither grant anticipated — read customer records, send external email | Reviewing tools as a set rather than one at a time. This one is genuinely hard and largely manual |
The second is the one that defeats a review-at-onboarding process entirely. A control reviewed once is accurate until the next release of something you do not control.
What good looks like
Three properties, in the order they pay off.
1 · Deny by default, with named grants. An agent reaching a tool it was never granted should fail, not succeed quietly. This sounds obvious and is frequently not the case, because tools are often reachable by virtue of network position rather than by grant.
2 · Grants expressed as conditions, not booleans. "May
call refund where amount ≤ 50 and currency = GBP" is a policy.
"Has refund tool" is a note.
3 · Change is an event. The set of tools an agent can reach should be something that produces a record when it changes — including when it changes because a third party shipped an update.
The measurement that tells you where you stand
Before tightening anything, produce one number per agent: the proportion of its granted scope it has actually exercised over the last month. That single figure tends to reframe the conversation, because it is usually small, and because it converts an argument about hypothetical need into a question about observed use. Grants nobody has touched in a month are the safest thing in the estate to narrow, and narrowing them costs no capability at all.
Where Agent Trust Cloud fits
| Need | What the platform does |
|---|---|
| Per-tool risk view | MCP Security classifies tools by risk rather than treating a tool list as flat |
| Catch capability drift | The same module detects permission drift — when a server quietly adds a capability it did not ship with, which is the failure a one-time review cannot catch |
| Know the server is who it claims | Publisher verification, so a tool server's identity is established rather than assumed |
| Conditions on the call itself | Policy Engine holds the conditions; Runtime is where they are applied |
| Spot dangerous tool combinations | Only partly. Per-tool risk is visible; reasoning about what two safe tools compose into is still a human review, and the most common real gap |
Common questions about tool and API controls
What is the difference between a tool and a permission?
A tool is a verb; a permission is a sentence. "Has the email tool" says what the agent can invoke. "May call send where recipient is internal and no attachment is present" says what it may achieve. Most agent deployments have written down the verbs and assumed the sentences, which is why the blast radius is usually larger than the tool list suggests.
How do I find out what an agent actually uses?
Compare granted scope against observed calls over a few weeks. The gap is almost always wide — agents typically exercise a small fraction of what they hold, because tools arrive with the credentials they shipped with. Narrowing a grant to observed use costs nothing in capability and is the highest-value first action in this area.
What is capability drift?
A tool server adding functionality in an update, so the agent can do more than when it was reviewed, without anything on your side changing. It defeats review-at-onboarding entirely, because the review was accurate on the day and the software moved underneath it. Detecting it requires comparing what a server offers now against what it offered before.
Why are tool combinations harder than individual tools?
Because risk is not additive. A tool that reads customer records is reasonable. A tool that sends external email is reasonable. Together they are an exfiltration path that neither grant anticipated. Per-tool risk scoring will not surface this; it needs someone reasoning about the set, and it remains one of the genuinely manual parts of the problem.
Should agents share tool credentials?
No, though it is common because it is easier. Shared credentials destroy attribution — after an incident you can see what was done but not which agent did it — and they make narrowing a grant impossible, because tightening it for one agent breaks the others.