MCP gives agents tools. What gives agents trust?

MCP is genuinely good

The Model Context Protocol standardises how a language model calls external tools. Before it existed, every agent framework had a different convention for tool schemas, a different way of passing results back, and a different idea of what a "tool" even was. MCP flattened that. A server you write today works with Claude, Cursor, Windsurf, and whatever host ships next quarter. That is real, durable value.

The design is also deliberately narrow. MCP specifies how to describe tools, how to invoke them, and how to return results. It leaves authentication, authorisation, pricing, and audit entirely to the application layer. That narrowness is a feature - protocol scope creep is how you get a standard that nobody implements correctly. But it does mean that MCP alone cannot answer a question that matters a great deal the moment your agent starts doing things with real-world consequences: who authorised this, and to do what?

When a human books a hotel room on a website, the consent chain is visible and explicit. They searched, they compared, they clicked "Book", they confirmed the price, they entered their card. Every step is a deliberate act by a person who understood what they were agreeing to. The hotel has legal certainty that the transaction was authorised. The customer has a receipt. The bank has a record.

When an AI agent books a hotel room through an MCP tool call, the picture is murkier. The model decided to invoke the tool. The MCP host relayed the call. The server executed it. Somewhere upstream, a human told the agent to "plan a trip to Paris" - but did they authorise booking a specific room at a specific price at this exact moment? Did they cap how much the agent could spend? Can either side prove any of this after the fact?

MCP does not answer these questions. It is not designed to. The tool call arrives at your server with no verifiable proof that the human principal consented to this specific action, no cryptographic binding to a spend limit, and no tamper-evident record of what happened. That is the consent gap.

Why API keys do not close it

The reflex answer is to put an API key in the MCP server config and call it solved. Keys authenticate a client - they prove the caller holds a secret. But they say nothing about what the caller is authorised to do with that secret, on whose behalf, within what limits, or for how long.

A key handed to an agent is a key handed to every action that agent might ever take. If the agent books one hotel room, fine. If it books forty - because a prompt was ambiguous, or a loop ran longer than expected, or someone upstream crafted an injection - the key still works. There is no ceiling. There is no scope. And after the fact, your server logs show forty successful authenticated requests, with no way to determine whether any of them were intentional.

OAuth scopes help but do not solve it either. Scopes are coarse-grained and static - you grant bookings:write and it is valid until it expires or is revoked. They carry no information about the specific action being authorised, the price the principal agreed to, or the idempotency semantics the caller committed to.

What a trust layer actually needs to do

Closing the consent gap requires something richer than a key or a scope. It requires a credential that is bound to a specific action, signed by the principal's key at the moment of intent, and verifiable by the provider without calling back to the principal.

Action binding - the credential names the exact merchant and action it authorises. An IntentMandate for book_room at Lux Hotels cannot be replayed against cancel_room or a different provider. Scope is not a string; it is a cryptographic commitment to a specific call.
Spend caps - the principal sets a ceiling at mandate-mint time. The gateway enforces it at invoke time. The model cannot exceed it regardless of what the provider charges or how many times it retries. The cap is not a soft guideline; it is a hard ceiling enforced by the trust layer, not by the model's own judgment.
Time-bounded validity - a mandate minted now is valid for seconds, not hours. If the agent signs an IntentMandate and then sits idle for two minutes before invoking, the call is rejected. There is no window in which a stolen or replayed credential can be used.
Price lock - between the intent and the invoke, the provider signs a CartMandate committing to an exact price. The agent confirms that price with a PaymentMandate before the transaction proceeds. The principal sees the price they agreed to, not a post-hoc charge from a provider who moved their rate.
Tamper-evident audit - every invocation writes a hash-chained record. The principal can prove what their agent did, and the provider can prove they executed what was authorised. Neither side can alter the record after the fact without detection.

These properties do not emerge from MCP tool calls plus an API key. They require a dedicated trust layer sitting between the agent and the provider.

The payment problem

Payment compounds every trust gap. When an agent needs to commit real funds, the stakes of getting the authorisation wrong are no longer just inconvenient - they are financial and potentially legal.

Moving money through an AI agent requires that the payment credential is verifiable by the provider, that the amount is exactly what the principal agreed to, and that the settlement is atomic with the action. If the booking succeeds but the payment fails - or the payment succeeds but the booking fails - the state is inconsistent and someone needs to unwind it manually.

Card-based payment through a scraping or form-filling agent inherits all the scraping problems: it requires a session, a browser context, and active consent from the card holder in the form the card network expects. None of that is available to a headless model invoking an MCP tool. Purpose-built payment rails for agents - where the mandate carries the payment commitment and the gateway settles atomically - are not a nice-to-have; they are the only architecture that actually works at scale.

MCP at the call layer, trust on top

The right framing is not "MCP or Sgovr" - it is "MCP and Sgovr." MCP is excellent at what it does: standardising how a model discovers and invokes tools. Sgovr layers discovery, mandates, spend enforcement, payment settlement, and audit on top of that foundation, while remaining MCP-compatible at the call layer.

From the model's perspective, it is still invoking MCP tools. The tools are just backed by a gateway that verifies every mandate, enforces every cap, and writes every audit record before the call reaches the provider. The model does not need to understand the trust layer; it just needs to use the wallet sidecar to sign its credentials before calling.

Fail-open on capability, fail-closed on authorisation

The trust layer is designed to be strict in the right direction. If the fraud scorer is unavailable, the call proceeds - availability beats false negatives for anomaly detection. If the mandate is invalid or the spend cap is breached, the call is rejected - no amount of availability pressure overrides authorisation. The model always has tools to call; it just cannot call them outside its mandate.

What this looks like in practice

Register the Sgovr SSE server and the wallet sidecar in your MCP host. The model gains four tools: discover, get spec, get quote, and invoke. Before any transactional call, it uses the wallet to sign an IntentMandate - a sub-second operation that produces a short-lived JWT committing to the exact action. The gateway sees that JWT on every subsequent call and enforces the authorisation chain end to end.

The principal's spend cap is set once, in the wallet config. It applies across every session, every model, every conversation. The principal does not need to trust that the model will exercise restraint; the infrastructure enforces the limit regardless of what prompt the model received.

For the full flow - from discovery through mandate signing to payment settlement - the hotel booking walkthrough in How AI agents can book hotels without scraping covers every step end to end. The MCP server guide has the registration steps for Claude Code and Claude Desktop.

The broader point

MCP will keep getting better at what it does. The tool-calling layer is not the hard problem. The hard problem is making agent actions trustworthy enough that businesses are willing to give agents real authority - authority to spend, to commit, to act on behalf of a principal in ways that have irreversible consequences.

That requires mandates, not keys. Spend caps, not honour systems. Tamper-evident audit, not application logs. Price lock, not post-hoc billing. None of these properties emerge from the tool-calling layer alone. They require infrastructure that was designed from the start around the question that MCP deliberately does not answer: not "how does the model call a tool?" but "who authorised it, to do what, for how much, and can anyone prove it?"