A successful tools/call is not a safely completed business action
Once a tool creates refunds, changes inventory, disables accounts, sends notifications, or triggers deployments, protocol success only proves that a request reached an accessible tool service. It does not prove that subject, object, approval, idempotency, business state, and evidence were correct.
Protocol success
Was a well-formed request delivered to an MCP server the current client may access?
Business completion
Did the right subject perform the right action once, on the right object and state, with the required evidence?
This is not an argument that MCP “has no security.” MCP provides tool semantics, an HTTP authorization specification, and security guidance. Protocol interoperability and end-to-end business consequences are simply different layers.
Five responsibilities, not necessarily five products
The separation is semantic, not a deployment prescription. One process may own several responsibilities, but colocating them does not remove the boundary between their claims.
| Layer | Primary responsibility | It does not replace |
|---|---|---|
| Tool protocol and MCP server | Discovery, schemas, invocation, protocol authorization, tool interface | Final authorization for business objects |
| Agent runtime | Task interpretation, tool selection, arguments, workflow state, human interaction | Trusted business identity or final permission |
| Shared execution control | Reach, trusted context, approval binding, task state, deduplication, dispatch, traces | Enterprise identity, approval authority, transactions, or all business policy |
| Enterprise identity, policy, and approval | Trusted identities, organization policy, qualified approvers | The business operation itself |
| Business system | Tenant boundaries, object authorization, current state, invariants, transaction, final execution | A passive backend that trusts upstream claims |
“Is it allowed?” contains at least three decisions
A valid MCP token is not an order-level refund decision. A capability allowlist is not tenant isolation. Keeping final authority in the backend does not justify exposing every dangerous tool to the model.
Five controls must compose across the execution path
Human approval
The UI may live in the runtime, pausing and request snapshots in an execution layer, approver qualification in enterprise systems, and final authorization in the backend. Evidence should bind trusted subject, capability, canonical arguments, and task identity.
Idempotency
The runtime preserves a stable request identity, an execution layer deduplicates dispatch, and the business system prevents duplicate domain effects across every entry path.
Retries and partial failure
A timeout does not prove non-execution. Resume or query the same task instead of creating a fresh write. Retry safety ultimately depends on business-boundary idempotency.
Audit evidence
Evidence should distinguish requester, trusted subject, approver, executor, and final result. A runtime that authors both the approval claim and the only log still produces a self-report.
Recovery
Reversal, compensation, and irreversibility are domain semantics or workflow concerns. A shared layer can invoke defined compensation; it cannot create atomicity with a label.
A refund request, end to end
User requests a refund -> runtime selects refund.create and proposes arguments -> MCP client calls an authorized server -> execution control checks reach and resolves trusted subject -> approval pauses on an exact request snapshot when required -> the same task resumes with evidence and stable idempotency -> backend rechecks subject, tenant, order, amount, and state -> backend commits or rejects -> result and evidence remain attached to the same task
The model proposes an action. The protocol carries it. The runtime coordinates it. Enterprise systems establish identity and approval trust. The business system authorizes and commits the consequence.
What happens on failure matters more than “supports governance”
| Failure | Conservative behavior |
|---|---|
| Trusted subject is missing or unverifiable | Do not dispatch a subject-required action |
| Approval does not match the exact request | Reject or require new approval |
| Execution state is unknown after timeout | Query the same task; do not create a fresh write |
| A retryable write has no idempotency identity | Refuse automatic retry |
| Business authorization fails | Return final rejection; upstream approval cannot override it |
| Audit storage is unavailable | Use an explicit fail-open or fail-closed rule; never claim evidence was persisted |
| No compensation exists | Report irreversible or manual-recovery state; do not claim rollback |
Where ACC and BailingHub fit
Agent Capability Contract (ACC) explores a portable, operation-level declaration of capability reach and governance intent. It does not execute tools, define enterprise identity, or replace final authorization.
BailingHub explores a self-hosted shared execution control plane for reach, trusted-subject handling, approval binding, task state, dispatch, and traceability. It is one implementation, not the only architecture.
The same boundaries may be implemented in an MCP server, agent platform, API gateway, workflow engine, shared control plane, or a combination. The important part is that every responsibility can be named and independently verified.
MCP references
MCP Tools specification
Tool discovery, schemas, invocation, and protocol semantics.
MCP Authorization specification
Protected resources, OAuth flows, and token audience constraints for HTTP transports.
MCP Security Best Practices
Guidance for scopes, sessions, credentials, sandboxing, and per-call authorization.
MCP Tasks utility
Protocol support for long-running work, state queries, and delayed results.