MCP Elicitation: What "User Explicitly Approved" Does and Does Not Record

The record of MCP elicitation approval can show that a user was drawn into a workflow. The Model Context Protocol Elicitation page says elicitation allows servers to implement interactive workflows by enabling user input, and the page was published on 30 August 2026. That does not make the resulting approval a durable authority record. The Model Context Protocol Blog said on 22 August 2026 that MCP authorization is built around a person approving access in a browser, which is a narrower claim than proving why a later tool call was allowed.

MCP elicitation approval in the specification text

The Elicitation page of the Model Context Protocol specification was published on 30 August 2026, and it frames elicitation as a way for servers to request user input during interactive workflows. That matters because approval is not treated as an abstract governance ceremony. It is part of a protocol exchange.

For a compliance reader, that is both helpful and insufficient. It is helpful because it names the point at which the user can be brought into the process. It is insufficient because the presence of a user in a workflow is not the same as a later record of who had authority to approve a payment release, a customer-record deletion, or a changed credit limit.

MCP authorization today is built around a person approving access in a browser.

— The New MCP Roadmap, 22 August 2026

Read that sentence closely. It says a person approves access. It does not say that the tool call carries a complete policy record. It does not say that the approval survives as evidence after the call has returned. It does not say that a reviewer can later see the policy basis, the approving actor, the requested action, and the permitted scope in one tamper-evident artefact.

The Tools page adds another constraint, because it says tools in MCP are designed to be model-controlled. That does not mean the model is the approving authority. It means the tool surface is exposed to the model, so the human approval question has to be separated from the model’s choice of tool.

The Tools page also tells implementers to provide a user interface that makes clear which tools are being exposed to the AI model. It separately tells implementers to show tool inputs to the user before calling the server. Those are sensible user-facing controls. They still do not, on their own, answer the evidence question.

A screen can warn the user. A button can record a local outcome. A server can proceed only after the workflow resumes. None of that proves that the approval was within the organisation’s policy, that the approver was the right person for that action, or that the record later presented to an auditor is complete.

This is the trap in the phrase “user explicitly approved”. It sounds like a conclusion. In practice it is only the beginning of the evidence analysis. Explicit to whom. Approved for what exact action. Bound to which user. Preserved where. Reviewable by whom. Those questions decide whether approval is merely an event or becomes evidence.

An MCP authorization example without an evidence model

The MCP Authorization page was published on 30 August 2026, and it says the Model Context Protocol provides authorization capabilities at the transport level. That is an important boundary. Transport authorization can establish access to the MCP server. It does not settle whether a particular tool call should release funds or alter a record.

The same Authorization page says the authorization server is responsible for interacting with the user, if necessary, and issuing access tokens for use at the MCP server. That gives a clear MCP authorization example. A user interaction can lead to server access. The server can then receive a credentialed request. That still leaves the runtime permission for a specific action to be decided somewhere else.

Clients acting on behalf of a user should attempt the step-up authorization flow, according to the MCP Authorization page. Step-up is useful when more assurance is needed. It is still not a substitute for an action record that states what was requested, which policy allowed it, and why it was within scope.

The Elicitation page draws the same line from another direction. It says URL mode elicitation is not for authorizing the MCP client’s access. It then states the server-side rule more bluntly.

MCP servers MUST NOT rely on URL mode elicitation to authorize users for themselves.

— Elicitation - Model Context Protocol, 30 August 2026

That sentence is useful because it prevents a common overread. URL mode elicitation can start an external flow. It is not a general-purpose authority system for the MCP server. If the server needs to know whether the person is the same person who began the interaction, the specification puts that burden on the server.

The Elicitation page says the server must ensure that the user who started the elicitation request is the same user who completes the authorization flow. That is a user-binding requirement. It is not a record-retention requirement. It says what must be true during the flow. It does not say what evidence must remain when the flow is over.

To prevent this attack, the server MUST ensure that the user who started the elicitation request (the end-user who is accessing the server via the MCP client) is the same user who completes the authorization flow.

— Elicitation - Model Context Protocol, 30 August 2026

That distinction is not pedantry. A payment release can be properly bound to the same user during the flow and still be hard to defend later if the evidence is split across a browser event, a server log, and a tool response. The runtime fact may have been true. The later proof may still be weak.

This is why identity is not authorization and authorization is not evidence. MCP authorization can answer access. MCP elicitation can bring the user into the interaction. Neither phrase should be stretched until it means a full audit record.

Who approves MCP tool calls

The short answer is that the model may select or drive the tool interaction, but the approval language points to a person or a host-mediated user consent step. The Model Context Protocol Blog says hosts can require explicit approval for UI-initiated tool calls, in a post published on 26 January 2026. That is not the same as saying every MCP tool call is approved by a person. It says hosts can require it for that class of call.

The Tools page tells implementers to show tool inputs to the user before calling the server. That gives the user a chance to see what is about to be sent. It does not prove the user had the authority to approve it.

Consider a changed credit limit. The user may see the tool input. The host may require an explicit approval. The server may receive the call. The missing question is whether that user was allowed, under the organisation’s policy, to approve that change for that customer at that time.

The answer may live outside MCP. It may live in a business rule, a segregation-of-duties control, a case-management process, or a review queue. MCP can carry the interaction. It should not be asked to become every organisation’s policy memory unless the implementation actually records that policy decision.

The Model Context Protocol Blog also warned on 22 August 2026 that a tools call response can carry the same output in more than one form, and that a server developer has no way to know which form a given client will put in front of the model. That statement is about presentation and model context, not evidence, but it reinforces the same operational point. The server cannot assume that what happened inside the client is enough for later accountability.

There is also a scale problem. The same roadmap post says connecting to a server with many tools means the model pays for the whole surface before the user asks a question, and tool selection tends to get worse as the list grows. That is a tool-surface warning. It does not create an approval trail. It makes the approval trail more important, because the wrong tool can become easier to invoke than the right review can become to prove.

Crelis has made the related distinction in who authorizes an MCP tool call. The approving user, the model-driven tool call, and the organisation’s permission rule are separate things. The worst implementation treats a click as if it settled all of them.

What this means if you have to produce evidence

Start with the document boundary. The MCP Elicitation page says form mode collects structured data through the MCP client. The same page says URL mode can start an authorization flow. The same page says the server must not rely on URL mode elicitation to authorize users for itself. Those are protocol statements. They are not an assurance report.

An auditor will not be satisfied by “the user approved it” if the contested action is a deleted record. The next question is which user. Then which action. Then which policy. Then whether the record was created at the time, or reconstructed after the dispute began.

A risk owner should also object to a weaker vendor claim. If a product says it records “approval”, ask whether it records the authority behind the approval. A person can approve something they are not allowed to approve. A model can call a tool the user did not understand. A server can complete a flow without preserving a record fit for review.

This is not an argument against MCP elicitation. It is an argument against inflating it. Elicitation is useful because it creates an interaction point. Authorization is useful because it controls access. Evidence is useful because it survives the argument.

The same separation is developed in runtime authorization versus runtime security. Security controls can reduce exposure. Runtime authorization decides whether a specific action may proceed. Evidence proves, later, that the decision was made and why.

Practical steps for MCP approval records

1. Separate access from action. Treat MCP transport authorization as server access, not as proof that a specific payment release or record change was allowed, because the MCP Authorization page describes authorization capabilities at the transport level.
2. Bind the user in the flow. For URL mode elicitation, require the server-side same-user check described by the Elicitation page before treating the completed flow as meaningful.
3. Do not rely on URL mode as server authorization. The Elicitation page says MCP servers must not rely on URL mode elicitation to authorize users for themselves.
4. Capture the requested action. Record the tool, the inputs shown to the user, and the business object affected, because the Tools page tells implementers to show tool inputs before calling the server.
5. Capture the policy basis. Store the rule or approval route that permitted the action, not just the fact that a user clicked through.
6. Capture the approving authority. Record why that user could approve that action, not merely that the user was present in the MCP flow.
7. Keep approval and execution together. A later reviewer should not have to infer authority by stitching together unrelated application events.
8. Test the dispute case. Pick one sensitive action and ask whether, after the tool call completes, the organisation can show who approved it, what was approved, and why that approval was valid.

Crelis’s position is narrower than the vendor market often wants it to be: GREENLIGHT is a permission step for sensitive agent actions, and the Model Context Protocol coverage keeps the protocol question separate from the evidence question. Crelis describes its runtime authorization work as allowing, requiring human approval, escalating, or blocking agent actions with tamper-evident proof.

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

Related reading

• Who Authorizes an MCP Tool Call? — the action-level permission question inside MCP.
• Identity Is Not Authorization Is Not Evidence — the separation between identity, permission, and proof.
• Runtime Authorization vs Runtime Security — the difference between deciding an action and protecting a system.
• Request a Demo — where Crelis asks teams to identify the systems their agents can affect.