Agent Tools Need Authorization, Not Just Descriptions

Agent Tools Need Authorization, Not Just Descriptions

MCP tools and A2A Agent Cards make agent capabilities easier to discover. That is good. It also creates a trap.

A tool description can say “read-only.” An agent card can advertise a skill. A prompt can tell the model to be careful. None of those things decide whether this caller, in this tenant, with this token, should be allowed to perform this action right now.

That decision belongs in a server-side authority plane.

Agent Setup treats MCP and A2A discovery as an authority-design problem, not a naming problem. If an agent can discover tools or delegate to another agent, the production question is: what enforces the boundary after discovery succeeds?

The short answer

Use descriptions and Agent Cards for discovery. Use server-side authorization for permission.

A production authority plane should inventory every MCP tool and A2A skill, then bind each capability to:

• caller identity
• tenant and resource boundary
• token audience and scopes
• action class and risk tier
• backend policy check
• approval requirement
• rate, spend, and fan-out limits
• audit-log event model
• negative tests for denied paths

Without that layer, the system is relying on convention. With it, tool discovery can expand without silently expanding authority.

If you are still choosing which tools to enable first, start with the AI agent tool rollout order. This post covers the next question: once a tool is visible, what makes it safe to call?

MCP tool metadata is not the permission boundary

The Model Context Protocol tools spec says tools are model-controlled: the model can discover and invoke them automatically based on context.¹ That is the whole point of the protocol. It is also why metadata cannot be your only control.

The MCP tools spec is direct about trust:

“clients MUST consider tool annotations to be untrusted unless they come from trusted servers.”

— Model Context Protocol, Tools specification¹

That quote is about annotations, but the lesson is broader. Tool names, descriptions, schemas, annotations, and return values help the client and model understand what exists. They do not prove that a caller is authorized.

For HTTP-based MCP servers, the authorization spec frames the protected MCP server as an OAuth resource server when authorization is supported.² That means a production review should ask concrete questions:

• Does the server publish OAuth Protected Resource Metadata?
• Does the token audience match this MCP server?
• Are upstream API tokens rejected if they are passed straight through?
• Does each tool map to required scopes?
• Does the server return an insufficient-scope challenge instead of broadening access silently?
• Does the server enforce authorization on every request, not only at session start?

MCP’s security guidance calls token passthrough an anti-pattern because it blurs accountability and can turn the MCP server into a confused deputy.³ OWASP’s MCP Security Cheat Sheet points to the same operating shape: least privilege, server isolation, human-in-the-loop controls for sensitive actions, input/output validation, transport security, and logging/auditing.⁴ In practice, that means the inbound token should authorize the client or user to call the MCP server. Any downstream SaaS, database, or cloud API token should be a separate credential acquired and scoped by the server-side implementation.

A2A Agent Cards advertise capabilities; they do not grant them

A2A has the same pattern at the agent-to-agent layer.

An Agent Card tells clients how to discover and interact with a remote agent. A2A’s discovery docs describe cards as including identity, service endpoint, capabilities, authentication requirements, and skills.⁵ That is useful discovery metadata. It is not permission.

A secure A2A deployment should review each advertised skill like this:

• Which callers can see the skill?
• Which callers can invoke it?
• Which auth scheme and scopes are accepted?
• Which tenant, resource, or data class can it touch?
• Which backend action will run?
• Which approval or step-up rule applies?
• Which audit event proves allow, deny, and execution?

A2A’s enterprise guidance puts authentication at the HTTP layer and authorization in the server implementation. It calls for granular control, skill-based authorization, data and action-level checks, least privilege, tracing, logging, and auditing.⁶

That distinction matters. An Agent Card can say “invoice reconciliation.” The authority plane decides whether this client can reconcile invoices for this account, whether it can only read mismatches, whether it can create adjustments, and whether a human must approve the final action.

Sensitive cards also need their own boundary. A2A discovery guidance recommends authenticated extended cards, endpoint access controls, and selective disclosure for cards that expose sensitive URLs or skills.⁵ If the card itself leaks too much, authorization is already starting late.

Build a capability inventory before adding more tools

A practical authority plane starts as an inventory.

For every MCP tool or A2A skill, record:

• Capability name and version.
• Owning server or agent.
• Transport and endpoint.
• Data classes it can read or write.
• External side effects it can create.
• Required caller identity and scopes.
• Required tenant, workspace, channel, or resource boundary.
• Approval and step-up rule.
• Rate, retry, spend, and fan-out caps.
• Audit fields and retention rule.
• Denied-path tests.

This is the artifact Agent Setup wants to see in a review. Not “the model knows to only use safe tools,” but “this tool call fails closed when the token is missing, wrong-audience, wrong-scope, expired, copied from another session, or used against the wrong tenant.”

Pair that with the broader AI agent security checklist and channel access policy so the capability boundary matches who can reach the agent in the first place.

Approvals must bind to the exact action

Human approval is part of the authority plane, but only if it is precise.

A weak approval says, “Allow the agent to continue?” A useful approval says, “Allow agent X to call tool Y against resource Z with these normalized parameters before this expiry time?”

The daily research behind this post found the same pattern across AI-agent and transaction-authorization guidance: high-impact approvals need exact-action previews, approver identity, expiration, replay protection, and execution-side validation. The executor should check the approval record immediately before action, not trust the agent’s next message.

Use approval gates for actions like:

• deleting or overwriting data
• sending external messages
• changing roles or permissions
• spending money
• exporting customer data
• invoking a downstream agent with broader authority
• deploying or changing production systems

For the highest-risk actions, add step-up authentication. Approval is not a vibe; it is a scoped, one-time authorization artifact.

Delegation needs scoped child authority

Multi-agent systems make this harder because the first agent may not be the one that performs the final action.

OpenAI’s Agents SDK represents handoffs as tools, and the handoff mechanism can carry custom inputs and filters.⁷ Its tracing docs describe traces and spans that can include LLM generations, tool calls, handoffs, guardrails, and custom events.⁸ Those features are useful, but they are not a substitute for authority design.

A multi-agent workflow needs a delegation graph:

• Which parent agents can call which child agents?
• Which task types can be delegated?
• What context is passed, filtered, or redacted?
• What credentials does the child get?
• What tools can the child see?
• What budget, depth, and fan-out caps apply?
• Who owns the final action and audit trail?

OWASP’s AI Agent Security guidance calls for least-privilege tools, explicit authorization for sensitive operations, trust boundaries between agents, and monitoring of decisions and tool calls.⁹ The practical version is simple: do not let a supervisor agent pass broad credentials to every subagent just because delegation is convenient.

Every child task should receive the minimum authority it needs, for the shortest useful time, with traceable output and a clear return condition.

Negative tests are the proof

The authority plane is only real if denied paths fail.

Before widening access, run tests like these:

• Missing token cannot list or call protected tools.
• Wrong-audience token is rejected by the MCP server.
• Wrong-scope token receives a narrow challenge or denial.
• Upstream SaaS token cannot be passed through as an MCP token.
• Expired approval cannot execute the action.
• Approval for one resource cannot be replayed on another.
• A2A stale Agent Card does not allow removed skills.
• Sensitive Agent Card details are not visible to unauthorized callers.
• Tool output that contains instructions is treated as data, not policy.
• Child agent cannot inherit parent credentials unless explicitly scoped.
• Cross-tenant session reuse fails closed.
• Audit-log write failure blocks high-impact execution or triggers a safe stop.

These tests are more useful than a long policy document. They prove the implementation is enforcing the boundary where the action actually happens.

What teams should build first

Start with a small set of capabilities and make the boundary boring.

For a first MCP or A2A rollout, Agent Setup recommends this order:

1. Inventory visible tools, skills, cards, servers, agents, and endpoints.
2. Classify each capability as read-only, internal write, external send, credential, financial, admin, or destructive.
3. Map each capability to identity, scopes, tenant/resource rules, approvals, and audit fields.
4. Remove tools or skills that do not have an owner or a testable policy.
5. Require scoped short-lived credentials where possible.
6. Add exact-action approval for high-impact calls.
7. Add rate, spend, retry, and delegation caps.
8. Run denied-path tests before adding more callers.
9. Review traces and logs for secrets before retaining them.
10. Revisit the matrix whenever tools, prompts, models, cards, scopes, or connected accounts change.

If your deployment also stores long-term context, align this with your AI agent memory policy. If you are still at the first install stage, use the private AI agent setup guide before exposing more channels or tools.

The takeaway

MCP and A2A make agent ecosystems more composable. They also make permission mistakes easier to hide behind friendly descriptions.

The safe pattern is not “write a better prompt.” It is: advertise capabilities clearly, authorize them server-side, scope credentials narrowly, require exact approval for high-impact actions, cap delegation, and log enough evidence to reconstruct both allowed and denied paths.

Agent tools need authorization, not just descriptions. Agent Setup can help teams design that authority plane before the agent can reach more tools, more data, and more people.

Sources