AgentGovernance
See the live demo

Engineering · MCP agents

The agent called the MCP tool. There is nothing to show for it.

Your coding agent proposed a Stripe refund via MCP, the tool ran, the money moved. Security asks for the approval chain. All you have is a chat transcript and a provider dashboard entry — no policy decision, no receipt, no way to prove who authorized the call.

Tool
ran
Money
moved
Receipt
missing
See the live demo Join waitlist

The failure mode platform teams recognize

MCP made it easy for agents to call real tools — sandboxes, ticketing, payments, deploys. That is the point. The failure mode is speed without evidence: the tool invocation succeeds, the side effect is real, and the only "audit trail" is a scrolling chat window that will be gone next session.

Prompt rules like "be careful with refunds" do not survive contact with a capable model under pressure. If the control plane cannot show propose → decide → prove for an MCP call, you do not have governance — you have a hope.

What AgentGovernance demonstrates

In the live control plane, MCP-class tool calls are governed actions: irreversible tools queue for a named owner, every decision writes a receipt, and a missing evidence bundle hard-blocks the call instead of trusting the prompt.

Propose before invoke

The agent states tool, arguments, and intended effect. That proposal is what a human (or policy) approves — not a vague chat summary after the fact.

Decide outside the model

Allow / queue / block lives in policy. The model cannot talk itself into a refund that policy forbids.

Prove with a receipt

Approved and blocked calls both leave a durable bundle: actor, tool, args hash, policy version, outcome. That is what incident review opens.

No receipt → no call

If the evidence path is down, irreversible MCP tools fail closed. Availability of the tool never overrides accountability.

The first policy to ship

  • Classify MCP tools: read-only (receipt + auto) vs irreversible (queue or block without approval).
  • Irreversible tools never run without a propose → decide record written before invoke.
  • Every invoke stores a receipt with tool name, args hash, policy version, and outcome.
  • Missing or failed receipt storage hard-blocks irreversible tools.
  • Weekly review: tools that repeatedly queue need a clearer mandate, not a quieter agent.

Related guides

MCP receipts sit next to destructive action blocks and CRM writes without rollback. For external sends that must never auto-run, see external-party actions.

Common questions

What is an MCP tool-call receipt?
A durable record of what was proposed, what policy decided, what tool ran, and what came back — tied to a timestamp and policy version. Without it, 'the agent called the tool' is a claim you cannot prove in an audit or an incident review.
Aren't MCP server logs enough?
Server logs show traffic. They do not show whether a human approved the call, which policy version allowed it, or whether the outcome matched the proposal. Governance needs the decision bundle, not only the wire log.
Should every MCP tool require a human?
No. Read-only and low-risk tools can auto-run with a receipt. Irreversible or external-effect tools (send, pay, delete, write production data) should queue — and no tool in that class should run without evidence you can replay.

Let employees use AI — with controls your team can run

No AI platform team required. AgentGovernance sits between Copilot, ChatGPT Enterprise, and the systems they reach — approvals, access control, and audit trails in plain business terms.

Try the demo Join waitlist