MCP authorization: securing tool calls

    The Model Context Protocol connected agents to thousands of tools — but securing those tool calls lagged adoption. Authentication proves who is calling. Authorization decides whether this tool call, right now, should run at all.

    MCP adoption exploded, yet most servers still rely on long-lived static secrets or no authentication at all. Even with the protocol standardizing OAuth and scoped consent, a connected server still has to answer the runtime question every tool call raises: is this specific call, with these arguments, allowed?

    Authentication is not authorization

    Authentication identifies the caller. Authorization bounds what the call may do. Granting an agent broad tool access and trusting it to use those tools appropriately is the "excessive agency" failure the OWASP AI Agent Top 10 warns about. Real MCP server security means evaluating each tool call against policy before it executes.

    • Is this tool permitted for this agent and context?
    • Are these arguments within bounds — scope, amount, target?
    • Is the call within budget and rate limits?
    • Afterward, can you prove what was authorized?

    How Keel authorizes MCP tool calls

    Keel issues a permit before each governed action — including MCP tool calls — as a fail-closed decision against your policy. A tool call outside the agent's permitted scope doesn't get a permit and doesn't execute. Each decision is recorded as tamper-evident, independently verifiable evidence.

    • Per-call, not per-session — authorization is evaluated at each tool call, not granted once at connect time
    • Fail-closed — no permit, no execution
    • Provable — every allowed and denied tool call is a verifiable record, checkable by a third party without trusting Keel

    That turns "the agent can reach these tools" into "each tool call was authorized under this policy, and here is the proof."

    Frequently asked questions

    What is MCP authorization?

    MCP authorization decides whether a specific Model Context Protocol tool call is allowed to execute — by agent, arguments, scope, and budget — before it runs. It is distinct from authentication, which only identifies the caller. Keel issues a fail-closed permit per tool call.

    Why isn't MCP authentication enough to secure tool calls?

    Authentication identifies the caller but doesn't bound what each tool call may do. With agents choosing tool calls by inference, you need per-call authorization against policy. Most MCP servers have weak auth today, which makes this gap acute.

    Can I prove which MCP tool calls were authorized?

    Yes. Keel records each tool-call permit decision as tamper-evident, independently verifiable evidence, so you can demonstrate exactly what was allowed and what executed — without trusting Keel.