Define execution scope for protected effects and complete mediation #736

Context

The EABC/cMCP interoperability profile for order_create maps the existing cMCP mechanisms for:

• authority binding: Cedar decision + rel: authorized-intent
• effect correlation: execution_id + rel: observed-effect
• execution binding: the proposed Execution Action Binding

The remaining EABC dimension is Execution Scope.

For a protected effect such as order_create, the relevant question is not whether an MCP request passed through the cMCP gateway. It is:

For the declared order_create effect domain, how is the set of paths capable of committing that effect identified, declared, and shown to be mediated?

Gap

Current cMCP mechanisms can establish what happened on a mediated execution path, and can correlate the execution with authority and downstream evidence. They do not appear to provide a protocol-level declaration or evidence model for the effect-producing path set itself.

In particular, the following are different claims:

1. this MCP tool call was authorized;
2. this execution was correlated to that authorization;
3. this downstream evidence was observed for that execution;
4. all paths capable of producing the protected effect are within the declared enforcement boundary.

The first three have existing cMCP homes. The fourth is the open part.

This matters because gateway mediation of MCP traffic does not by itself prove that an application cannot create the same protected effect through another API, service, direct database operation, alternate tool server, privileged process, or other execution path.

Concrete example: order_create

Assume order_create is the protected effect.

A useful execution-scope declaration would need to make it possible to state something equivalent to:

Protected Effect: order_create

Declared effect-producing paths:
  P1 = MCP tool X -> cMCP -> upstream order service
  P2 = ...
  Pn = ...

Enforcement boundary:
  every Pi capable of committing order_create
  must pass the declared authorization/execution gate

The exact representation need not be this syntax. The question is what cMCP should carry, require, or integrate with so that this scope is explicit and independently assessable rather than inferred from the presence of the gateway.

Questions

1. Does cMCP already have a planned or existing mechanism for declaring an effect domain / execution scope and its effect-producing paths?
2. If not, should this be represented as a cMCP profile/contract rather than as a runtime field?
3. What evidence should establish that the declared path set is complete for a protected effect?
4. How should a verifier distinguish:
   • "this path was mediated",
   • "this effect was observed", and
   • "all paths capable of producing this effect are mediated"?
5. Is there an existing cMCP issue or design that should own this rather than opening a new mechanism?

Boundary

This issue is not asking cMCP to implement EABC or to claim universal complete mediation.

The immediate goal is to identify whether cMCP has a native representation for Execution Scope, or to define the smallest missing contract needed for an integration profile to make a scoped non-bypassability claim.

The EABC profile currently records Execution Scope as OPEN / NOT CLAIMED until such a mechanism and evidence boundary are identified.