Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Define execution scope for protected effects and complete mediation

Open
  • Is something wrong?
#736 6 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
security

Research direction

The issue does not name files, tests, or entry points; start by reading the cMCP design and existing profile or contract mechanisms for authorization, execution binding, and observed effects. Determine whether a native execution-scope representation already exists or identify the smallest missing contract and evidence boundary. Done means the project can distinguish a mediated path and an observed effect from a supported claim that all paths capable of producing the protected effect are mediated.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Python
Stars
33
Forks
24
Avg merge
19h 50m
Merged PRs (30d)
75

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from agentrust-io/cmcp

All issues in agentrust-io/cmcp

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.