cMCP Goes Open Source: Giving Agent Refusals a Paper Trail

Recently, the AgentTrust team open-sourced cMCP. Its purpose is highly specific: when an AI Agent initiates an MCP tool call that should not be executed, has not yet been approved, or exceeds policy boundaries, the system can reject the call and generate a cryptographically signed denial credential that can be verified afterward.

When a conventional gateway encounters an unauthorized request, it usually returns only 403 Forbidden; cMCP aims to attach a tamper-resistant “receipt” to that 403: who requested what, when it was denied, which policy justified the denial, and whether the record came from a trusted decision-maker.

This may look like nothing more than signing a log entry, but it points to an increasingly practical problem in Agent deployment: models can call tools, but enterprises need to prove that a particular tool call did not actually occur.

cMCP Fills the Evidentiary Gap After a Denial

MCP has been gradually standardizing how models connect to external systems. Through a unified protocol, Agents can discover tools and then read databases, send emails, modify tickets, execute deployments, and even initiate purchases and payments.

Once the connectivity problem is solved, the permissions problem immediately emerges.

Current safeguards generally fall into three categories:

• Using OAuth, API keys, or service accounts to determine whether an Agent can access a given service;
• Setting allowlists, quotas, parameter ranges, and role permissions in a tool gateway;
• Adding human confirmation for sensitive operations such as transfers, deletions, and publishing.

These mechanisms can answer “Is this allowed?” but cannot necessarily answer “Why exactly was it not done at that time?” In multi-Agent systems, cross-organization services, and asynchronous tasks in particular, an ordinary log entry is difficult to treat as reliable evidence: logs may be overwritten, denial reasons may be rewritten, and the caller and tool provider may each tell a different story.

The core idea behind cMCP is to elevate a denial from a runtime error into a verifiable object. Its basic process can be summarized as follows:

Agent generates a tool call
        ↓
cMCP / policy boundary checks the caller, tool, parameters, and authorization
        ↓
Allow: Forward to the actual MCP tool server
Deny: Terminate the call without reaching the actual tool
        ↓
Generate a signed credential for the denial
        ↓
Agent, user, or audit system independently stores and verifies it

The most important point here is not merely that “there is a signature,” but that the credential must be bound to the original request. Otherwise, an attacker could take a receipt stating that “the deletion operation was denied” and attach it to a different deletion request that was actually executed.

From an engineering perspective, a meaningful denial credential should cover at least the following information:

• A hash of the request or canonicalized request;
• The tool name, a summary of key parameters, and the target resource;
• The identity of the caller, session, or authorized principal;
• The denial time, a nonce, and the credential’s validity period;
• The policy version matched and the reason for denial;
• The signature algorithm, signer, and key identifier.

The following is only a conceptual structure, not a field-by-field reproduction of the cMCP repository’s interface:

{
  "decision": "deny",
  "tool": "payments.transfer",
  "request_hash": "sha256:...",
  "principal": "agent:procurement-bot",
  "policy": "finance-prod@2026-08-01",
  "reason": "amount_exceeds_delegated_limit",
  "issued_at": "2026-08-04T09:30:00Z",
  "nonce": "...",
  "key_id": "policy-gateway-07",
  "signature": "..."
}

The verifier does not need to fully trust the Agent’s own account. As long as it possesses a trusted public key, it can check whether the credential was issued by the designated decision boundary, whether its contents were tampered with, and whether it truly corresponds to that specific tool call.

Why “Proving It Was Not Executed” Is Becoming Important

In the chatbot era, if a model produced an incorrect statement, the user could usually identify and correct it. In the Agent era, errors become side effects in the external world: an email has already been sent, a database has already been updated, a cloud resource has already been deleted, or an order has already been paid for.

Therefore, enterprises care about more than tool-call success rates. They need every side effect to be explainable, authorized, and traceable.

Consider a more practical example. A procurement Agent has delegated authority to spend “no more than RMB 5,000 per transaction.” After discovering a service priced at RMB 7,800, it attempts to invoke a payment tool. The policy engine denies the request, and the Agent then switches to requesting human approval.

If there is only an ordinary error message, downstream systems will struggle to confirm the following facts:

1. Whether the amount submitted by the Agent was actually RMB 7,800;
2. Whether the denial occurred before or after the payment service was reached;
3. Which version of the budget policy was used as the basis for denial;
4. Whether the Agent tampered with the error message to conceal a different payment that had already been completed.

A signed denial credential can at least turn the first three items into verifiable records while significantly increasing the cost of the fourth type of tampering. It can also be passed to another Agent as trusted input for a workflow branch: instead of asking the downstream model to believe the natural-language statement “the payment failed,” the runtime can first verify machine-checkable evidence.

This type of mechanism is especially valuable for cross-organization calls. The caller, the MCP service provider, and the policy host may belong to three different companies. They may be unable to share complete logs and should not be expected to trust one another by default. A signed credential can expose only the necessary summary, proving the denial without disclosing the full context.

It Is Not the Same as OAuth or MCP Authentication

cMCP cannot replace OAuth, nor is it a new identity system.

OAuth handles authorization delegation: whether an Agent may access a resource on behalf of a user. MCP authentication and authorization mechanisms establish identity, tokens, and permission boundaries between clients and remote servers. cMCP is closer to a post-decision “evidence layer”: once the system has denied a request based on identity and policy, it needs to package that outcome into an independently verifiable credential.

The three can be understood as three stages of entering an office building:

• OAuth is like an access card, indicating which areas the cardholder is generally permitted to enter;
• A policy gateway is like a security guard, deciding whether to allow entry on this particular occasion based on the time, floor, and items being carried;
• A cMCP signed denial credential is like a stamped interception record proving that a person was indeed stopped at the door at a particular time.

It is also clearly different from Agent payment protocols such as AP2 and x402. Payment protocols focus on authorization, settlement, and value exchange, while cMCP focuses on the verifiable state produced after a tool call is denied. However, the two can easily intersect in real-world systems: after an over-budget x402 payment request is blocked by the policy layer, a denial credential can be used to trigger a new quote, human approval, or a switch to another service provider, rather than forcing the model to guess the next step by parsing an error string.

The Real Challenge Is Not the Signature, but the Boundary

Digitally signing a piece of JSON is not difficult. Whether cMCP can enter production depends on whether it can answer a more difficult question: Where exactly is the signer positioned in the call chain?

If the denial credential is generated by the Agent itself, its evidentiary value is weak because the Agent is both the requester and the recordkeeper. If the credential is generated by a policy gateway but the Agent can still bypass that gateway and connect directly to the actual MCP server, the credential likewise cannot prove that the tool was not executed through another route.

A reliable deployment will generally need to meet several conditions:

• All high-risk tool calls must pass through the same non-bypassable execution boundary;
• Signing keys must not be exposed to the model process or ordinary business logic;
• Tool servers should verify that calls originate from a trusted gateway, rather than merely checking a static key;
• Requests must be canonicalized and protected against replay so that the same credential cannot be applied to different parameters;
• Policy versions must be traceable; otherwise, saying a request was “denied according to policy” does not identify which policy was applied;
• Credential storage must address privacy concerns and avoid exposing complete sensitive parameters merely for the sake of auditing.

Another common risk is TOCTOU—a mismatch between the state at the “time of check” and the state at the “time of use.” A system may first deny a call and issue a credential, only for the same request to later succeed under a different authorization. Therefore, a denial credential should prove that “a specific request was denied at a specific decision point,” rather than making the overly broad claim that “this never happened.”

This is a semantic boundary that users must preserve. A signature can prove that data was not tampered with, but it cannot automatically prove that the signer was honest or that the gateway was not bypassed, nor can it replace execution logs from the actual tool.

cMCP Is Useful, but Not for Every Tool Call

Our assessment is that cMCP addresses a real and rapidly growing need, but it is better viewed as infrastructure for high-risk Agents than as a default requirement for every MCP application.

Weather queries, public web searches, and side-effect-free knowledge base reads do not need signatures, key management, and credential storage for every denial. Doing so would merely increase latency and operational costs.

Signed denial credentials are highly valuable, however, in the following scenarios:

• Financial transactions, procurement payments, and budget controls;
• Production deployments, database writes, and resource deletions;
• Automated workflows in highly regulated industries such as healthcare and government;
• Cross-company and cross-Agent task delegation;
• Long-running workflows that require human approval and clear accountability;
• Red-team testing in which security teams need to prove that policies actually took effect.

Rather than teaching Agents how to say “no,” cMCP requires systems to be accountable for that “no.”

It Should Still Be Viewed as an Early-Stage Building Block

Based on the information currently available, what deserves the most attention about cMCP at this stage is its protocol concept and implementation approach—not its immediate adoption as a mature enterprise compliance product. When evaluating it, developers should closely examine the repository’s credential format, signature implementation, key rotation, policy binding, replay protection, and interoperability, rather than focusing only on the marketing term “verifiable.”

Whether the project can build lasting influence will also depend on two factors.

First, whether the credentials can be recognized jointly by Agent frameworks, MCP gateways, and audit platforms. If every system uses proprietary fields and verification logic, signed receipts will ultimately degrade into vendor-specific logs.

Second, whether denial credentials can participate in subsequent workflows. Ideally, they should not merely be piled into an audit repository. Other systems should be able to use them to reliably execute alternatives, such as reducing the amount, requesting elevated permissions, switching to a read-only tool, or escalating the task to a human.

MCP makes it easier for models to reach out and act on the external world; cMCP attempts to leave behind a verifiable record when that hand is stopped. For Agent infrastructure, this may not be the most eye-catching capability, but it could well be a necessary layer in the transition from demos to production.

References

• AgentTrust cMCP GitHub Repository: Project source code and documentation demonstrating the design for denying Agent tool calls and generating signed credentials.
• Model Context Protocol Specification Repository: The MCP protocol specification, useful for understanding tool calls and the interaction boundaries between clients and servers.