Misplaced Tool Trust: Authenticated Is Not Authorized

A very common way agents go wrong is a quiet assumption: that a tool is safe to call because it is authenticated, because it is internal, or because it was approved once. None of those facts answers the question that actually matters, which is whether this specific call, initiated by this specific request, should run with these specific rights. Authenticated is not authorized, and a harness that conflates the two hands an agent more power than it should ever have.

Authenticated is not authorized

Authentication answers who are you. Authorization answers are you allowed to do this, here, now. They are different checks, and passing the first says nothing about the second. A tool the agent can reach with valid credentials may still be a tool it should not be invoking for this task.

Naive harnesses collapse the two. Because the tool is wired up and the token works, the call goes through. That is exactly the gap an attacker, or an honest mistake, walks through.

Four kinds of tool trust

Lay the two questions on a grid. A call can be authenticated or not, and authorized or not. Three of the four cells are easy. The dangerous one is the call that is authenticated but not authorized, because it looks legitimate and sails past a harness watching only for valid credentials.

That quadrant is where misplaced tool trust lives. Everything about the call seems fine, and it should still be refused.

The trap is the authenticated-but-not-authorized call that looks legitimate and still must be refused.

Every call must answer

Before a tool runs, the harness should be able to answer a short set of questions, and a no to any of them stops the call. Who initiated it? Is that identity allowed to use this tool for this purpose? Is the token scoped to exactly this action? Are the arguments valid?

Model it as a gate, not a habit. Only a call that clears every check proceeds; anything else is denied and recorded, not quietly retried with a shrug.

A call runs only if the caller is allowed and the arguments are valid; otherwise it is denied.

Trusted because is not actually safe

The reasons harnesses trust tools are seductive precisely because they feel like safety. The tool is authenticated. It is internal. It was approved in review last quarter. None of these establishes that this call, right now, is within bounds.

Real safety comes from properties enforced per call: a token scoped to exactly this action, least privilege, and a fresh check that the caller is entitled. The difference is between a feeling and a control.

Reasons a tool feels trustworthy are not the properties that make a call safe.

Capability-based tool design

The structural fix is to design tools as narrow capabilities rather than broad powers. Separate read tools from write tools, internal from external, low-risk from high-risk. Give each the minimum authority it needs, and mint credentials scoped to the task, the tool, the identity, and a short lifetime.

With capabilities, the authenticated-but-not-authorized call has nowhere to go: even if it reaches a tool, the tool cannot exceed the tiny authority it was granted.

The confused deputy

A classic version of this failure is the confused deputy: a tool that holds high privilege acts on behalf of a lower-privilege caller, using its own rights instead of the caller's. The agent becomes an unwitting proxy for actions the requester could never perform directly.

Guarding against it means the tool acts with the caller's scoped authority, never its own ambient power, and the harness checks entitlement on every call rather than trusting the deputy.

⚠️

Beware the deputy. If a privileged tool acts with its own rights on a caller's behalf, it can be tricked into doing what the caller never could.

What a practitioner decides

Fixing misplaced tool trust is a set of deliberate choices: to separate authentication from authorization, to check entitlement on every call, to scope credentials to the exact action, and to design tools as narrow capabilities rather than broad powers.

The test for any tool call is not does the token work. It is: is this caller authorized to do exactly this, right now, with exactly these rights?

Key takeaways

Authentication proves identity; authorization proves permission. Passing one is not passing the other.
The dangerous call is authenticated but not authorized, because it looks legitimate.
Check on every call: who initiated it, is the identity entitled, is the token scoped, are the args valid.
Trusted because authenticated, internal, or approved is a feeling, not a control.
Design tools as narrow capabilities with least-privilege, task-scoped credentials.
Guard against the confused deputy: a privileged tool must act with the caller's scoped authority, not its own.

Glossary

Authentication: Verifying who a caller is.
Authorization: Verifying whether a caller is allowed to perform a specific action in a specific context.
Capability-based design: Granting narrow, specific authorities to tools rather than broad, ambient power.
Scoped credential: A short-lived token that grants access only to the exact action, tool, and identity it was minted for.
Least privilege: Giving each tool or identity the minimum authority needed to do its job.
Confused deputy: A privileged component tricked into misusing its authority on behalf of a less-privileged caller.
Ambient authority: Power a component holds by default, independent of the specific request, which capability design avoids.