Accountability 14 August 2026

Who Authorizes an MCP Tool Call?

A tool call can be a payment release, a record deletion, a change to a customer's credit limit. Something has to decide that the call may proceed, and something has to be able to show, months later, that the decision was taken and on what basis. MCP does the first of those better than most commentary admits. It does not do the second at all.

Key Takeaways

MCP authorization reaches the individual call: a server may work out the permissions a request needs from that request's own arguments and challenge the client for them.
Revision 2026-07-28 lets a server answer a tool call by demanding input before it will complete, and a human decision can travel inside that exchange.
The specification says hosts must obtain explicit user consent before invoking any tool, and then says plainly that it cannot enforce that at the protocol level.
Nothing in the schema records which policy permitted an action, on what grounds, or by whose standing authority — and nothing carries that decision past the end of the call.
The gap is evidence, not access. Closing it is work you do outside the protocol, deliberately.

MCP authorization

MCP authorization is an OAuth 2.1 profile that runs at the transport layer, and as of revision 2026-07-28 it reaches the individual call. A server may work out which permissions a specific request needs from that request's own arguments and challenge the client for exactly those. What it does not do is record which policy allowed the call, or keep anything once the call returns. Two limits are worth stating. The specification marks this profile OPTIONAL, and writes it for HTTP-based transports; implementations over STDIO are told not to follow it and to retrieve credentials from the environment instead.

That first half is worth stating precisely, because a great deal of writing on this subject gets it wrong. The authorization section of the Model Context Protocol specification describes a challenge that is computed per operation, not per connection:

The required scopes may be determined dynamically based on the specific request arguments and context, but once determined, they should be emitted together.

The same revision goes further. Multi round-trip requests let a server answer a tools/call with an input-required result instead of a finished one, refusing to complete until the client comes back with what was asked for. What is asked for can be a human decision: an elicitation response carries an action field, and the value "accept" is documented as the user having explicitly approved and submitted with data. A person's approval can therefore ride on the wire, inside the very call it authorizes.

So the familiar formulation — that MCP authorizes the connection and not the call — is false for this revision, and any engineer who has read the schema knows it. Concede the point and move on. The real gap is narrower than that, and worse.

MCP server access control

Access control on an MCP server is a permission decision, and permissions are the wrong shape for the question an enterprise actually has to answer. A scope can say that a caller may write files. It cannot say that this caller was permitted to move this amount to this counterparty at this moment because a named rule allowed it, and that a named person stood behind that rule.

The protocol also declines to remember. Its own guidance on stateful tools is explicit about this, and it is a deliberate design choice rather than an oversight:

MCP has no protocol-level session, so a server cannot rely on implicit per-connection state to relate one tool call to the next.

That is sound engineering and a real constraint on evidence. Each call stands alone. Whatever was established when the first call was permitted — who was asked, what they were shown, which rule applied — is not carried forward by the protocol to the second. If you want the second call to know about the first, you build that yourself, and you build the record of it yourself too.

None of this is exotic. OWASP's Top 10 for Agentic Applications for 2026 exists to give builders and defenders an operational starting point for reducing agentic AI risks, which is a reasonable description of the problem an engineer inherits the moment an agent is handed a tool that moves money.

Who approves MCP tool calls?

You do. Not the protocol — the host application you are shipping. The specification is unambiguous about the duty and equally unambiguous that it cannot discharge that duty on your behalf. Under its tool safety principles, hosts must obtain explicit user consent before invoking any tool. Its tools chapter carries a warning to the same effect:

For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.

And then, in the implementation guidelines that follow its security principles, it says the quiet part out loud:

While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD:
1. Build robust consent and authorization flows into their applications

Read those two together and the answer to the question in this heading is uncomfortable but clear. The specification asks for a human decision on consequential tools, and then tells you, in its own words, that it will not enforce that request on the wire. The consent flow is your code. The evidence that the consent flow ran is also your code, and that is the part teams discover late.

Model Context Protocol security in the enterprise

An enterprise security review asks a question the protocol was never written to answer: six months from now, can you show which rule permitted this action and who stood behind it? The specification's advice to client implementers on this point is a single line in a list of security considerations.

Log tool usage for audit purposes

That is the whole of it. It is a SHOULD, addressed to the implementer, with no defined content. There is no field in the schema for the policy that permitted an action, none for the grounds on which it was permitted, and none for the standing authority of whoever allowed it. Two competent teams can both follow that line and produce records that cannot be compared with each other, or tested by a third party a year later.

This is the part that gets overstated in both directions, so it is worth being exact. MCP is not insecure. It has a real authorization model, that model reaches individual calls, and a server can stop mid-call to put a question to a person. What it lacks is durability. The decision happens, the call completes, and the protocol keeps nothing that a reviewer could later test. An approval can occur and leave no verifiable trace that it occurred.

Restricting what an MCP agent can do

Restriction and evidence are two different problems, and they are usually attacked by the same team on the same afternoon with the same tool. Scopes restrict reach: they settle which tools a caller can touch at all. They do not settle whether this particular action, with these particular arguments, was permitted on this particular occasion — and they leave nothing behind that says so.

The restriction most engineers actually want is narrower than a scope and shorter-lived than a connection. It is a permission for one action, on one system, that stops being valid almost at once. That is the shape of the permission GREENLIGHT issues: single-use, expiring in seconds, locked to one specific action for one specific system.

A permission of that shape answers a different question from a scope. A scope describes what an agent may reach at all. A single-use permission describes what was allowed to happen once, and then it is spent. Stolen, it is worth very little, because it cannot be reused, redirected, or stretched to cover a second action. The restriction and the record of the restriction are the same object, which is the property that matters when somebody comes to check.

What this means if you have to produce evidence

None of the following requires buying anything. It requires deciding, before the server is connected to something that matters, that some calls are consequential and will be treated differently from the rest.

Name the consequential calls first. Write the list down. Anything that moves money, changes an entitlement, deletes a record, or contacts a customer belongs on it. Everything else can stay ordinary.
Record the decision outside the protocol, at the moment it is taken. Capture the identity that permitted the action, the rule that permitted it, and the arguments the call was actually given. The wire will not carry this for you, and reconstructing it afterwards from application logs is guesswork wearing a suit.
Make the record tamper-evident rather than merely stored. A record the approver can quietly edit later is not evidence. The honest standard is not that a record cannot be altered; it is that alteration cannot happen without detection. Any vendor promising you more than that, including this one, is selling you a word rather than a property.
Bind the permission to the action, not to the connection. A permission that survives the call it was granted for is a permission you will one day have to explain.
Test the reconstruction before someone else does. Pick a call from a month ago. Using only your own records, answer three questions: who permitted this, under what rule, and were they entitled to? If answering needs a conversation with the engineer who built it, you do not have evidence. You have logs.
Re-read the revision you are actually pinned to. Revision 2026-07-28 changed what a server may do in the middle of a call. Check the schema you are running against before you design around anything written here, including this article.

Steps two and three are where a structured review workflow stops being paperwork and starts being useful, and they are also the steps that decide how a firm answers for an action nobody meant to authorize. Crelis exists for that second half: sensitive requests are routed through a permission step, and what comes out is a tamper-evident record of the decision — which rule allowed it, who stood behind it, and precisely what it was allowed to do. You can see the permission step and the record it produces in the product demonstration.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.