What is missing between MCP tool selection and safe execution?

MCP makes tools discoverable and callable. A real business system must still prove that the right subject acted on the right object, under the right state, exactly once, with enough evidence.

A successful tools/call proves protocol delivery, not safe business completion. This is not a claim that MCP “has no security.” Interoperability and accountable business consequences are different layers.

Five responsibilities, not necessarily five products

Responsibility	Question	It cannot replace
Tool protocol / MCP Server	How is a tool described, called, and returned?	Record-level enterprise authorization
Agent Runtime	How is a goal understood, planned, and mapped to tools?	Business permission creation by model judgment
Shared execution governance	Which tools are visible, when to approve, how to deduplicate, recover, and audit?	Domain transaction commit
Enterprise identity and approval	Who is the subject and who may approve?	Per-domain object-state validation
Business system	May this subject produce this consequence on this object now?	Cross-agent discovery and orchestration

The responsibilities may coexist in one process or span several systems. Every responsibility still needs an authoritative source and a failure boundary.

“Authorized” contains at least three questions

Tool access: may this client or agent discover and call the tool?
Subject authority: which verified user, tenant, or store does the request represent?
Resource authority: may that subject act on this order, refund, employee, or deployment now?

An MCP token is not order-level authorization. A tool allowlist is not tenant isolation. Keeping final authority in the backend also does not justify exposing every dangerous tool to a model.

Five controls must span the path

Human approval

The UI may live in the Runtime, the pause and argument snapshot in a governance layer, approver eligibility in an enterprise system, and final authorization in the business backend. Approval should bind trusted subject, capability, normalized arguments, and task identity.

Idempotency and duplicate execution

The Runtime preserves request identity, the governance layer deduplicates dispatch, and the business system uses domain idempotency keys and uniqueness constraints to stop duplicates across entry points.

Retry and unknown finality

A timeout is not proof of non-execution. Query or resume the same task and reconcile against the system of record before creating another write.

Audit evidence

Evidence should distinguish requester, trusted subject, approver, executor, and final business outcome. A transcript or a Runtime’s self-authored approval record is not enough by itself.

Rollback and recovery

Reversibility, compensation, and irreversibility are domain or Workflow/Saga semantics. A shared layer may invoke a defined compensation action; it cannot manufacture atomicity from metadata.

A governed refund path

User asks for a refund
  ↓
Agent Runtime selects refund.preview
  ↓
Governance verifies subject, route, scope, and arguments
  ↓
Business system returns current refund eligibility
  ↓
Agent proposes refund.request.create or refund.execute
  ↓
High-risk call is frozen and sent to business approval
  ↓
Resume rechecks identity, policy, arguments, expiry, and business state
  ↓
Business system commits with a domain idempotency key
  ↓
Governance records invocation, approver, and final outcome

The model proposes an action, the protocol carries it, the Runtime coordinates it, enterprise systems establish identity and approval trust, and the business system authorizes and commits the consequence.

Safe failure behavior

Failure	Safe response
No trusted subject	Keep the tool hidden or reject the call
Route/scope denied	Reject before contacting the business API
Arguments drift after approval	Invalidate the approval
Tool call times out	Enter unknown finality and reconcile with the same business key
Audit write fails after dispatch	Do not reduce it to a blindly retryable tool failure
Final business authorization fails	Preserve the denial; do not bypass it in the hub or model

Where ACC and BailingHub fit

Agent Capability Contract (ACC) expresses portable, operation-level reach and governance intent. It does not execute tools, define enterprise identity, or replace final business authorization.

BailingHub is one self-hosted implementation that governs trusted subjects, capability filtering, approval binding, task state, dispatch, and tracing around business tool calls. The same responsibilities can be implemented by MCP servers, agent platforms, API gateways, workflow engines, or a combination.