Proposal: EABC as an optional interoperability contract for cMCP

[omwei-org]

Context

I would like to explore a possible contribution path around interoperability between cMCP authorization and downstream execution.

I am proposing the Execution Authority Boundary Contract (EABC) as an optional, implementation-independent contract layer that could sit between an authorization decision and downstream execution.

EABC specification: https://github.com/omwei-org/omwei-eabc

The intent is not to replace or redefine cMCP, but to explore whether some execution-authority semantics could be made explicit and consumable by systems beyond the cMCP gateway itself.

What EABC proposes

The EABC model makes three concepts explicit:

• Effect Identity — a stable identifier for the protected effect, independent of MCP session, tool call, or transport
• Execution Scope — an explicit declaration of the execution paths capable of producing that effect
• Authority Binding — a binding from an authorization decision to a specific Effect Identity and Execution Scope

For example, instead of representing authorization only as:

ALLOW(principal, tool_call, MCP path)

an EABC-compatible representation could additionally express:

ALLOW(principal, protected effect, execution constraints)

The purpose is to preserve the existing path-level authorization while providing an explicit contract for the downstream execution boundary.

What EABC does not claim

EABC is not intended to:

• replace cMCP gateway mediation;
• replace Cedar policy evaluation;
• replace TEE isolation or other enforcement mechanisms;
• claim universal or non-bypassable mediation of all possible paths to an effect.

In particular, complete mediation and non-bypassability remain properties of the deployment and enforcement substrate. EABC would define the contract and required semantics; it would not by itself establish those properties.

Potential value for cMCP

An optional EABC profile could potentially provide:

1. Effect-level correlation
   TRACE Claims could carry an Effect Identity and correlate an authorization decision with the externally observable effect.

2. Explicit execution scope
   The catalog could describe which effects and execution paths are intended to be covered.

3. Interoperable execution authority
   An authorization result could carry semantics that downstream enforcement components can consume without depending on the internal implementation of cMCP.

4. A clean extension point
   The same contract could potentially be consumed by software enforcement, backend enforcement, TEEs, or stronger enforcement substrates without making EABC dependent on any particular implementation.

Proposed integration style

I suggest treating EABC as an optional interoperability profile, rather than as a change to the cMCP enforcement model.

Possible characteristics:

• additive only;
• compatible with the current cMCP architecture;
• opt-in;
• no requirement to change the existing gateway mediation model;
• expressible through existing or additional Cedar context, catalog, and TRACE Claim fields.

Questions for discussion

Before proposing implementation details, I would like to get feedback from the maintainers on the architectural fit:

1. Is there interest in exploring an optional EABC-style contract for cMCP?
2. Does the Effect Identity / Execution Scope / Authority Binding distinction map cleanly onto the existing cMCP model?
3. If so, which repository/component would be the most appropriate starting point (cmcp, integrations, or elsewhere)?
4. What would be the most useful next step: a concrete field mapping for Cedar context/catalog/TRACE Claims, or a minimal Authority Binding format?

I would prefer to agree on the scope and architectural fit first, before proposing implementation work.

Happy to refine the proposal based on feedback and keep any contribution small, additive, and reviewable.

[omwei-org]

Concrete example: order_create tool → protected effect

Tool: order_create

Protected effect: commit order O-2026-10-02-C123 into the authoritative orders database.

1. Mapping to existing cMCP inputs and evidence

EABC concept: Effect Identity
Existing cMCP input / evidence: No explicit effect identity today; call_id, execution_id, and related identifiers identify the execution/call context.
Optional profile extension: Bind the authorization result to a stable effect_id, e.g. order:O-2026-10-02-C123.

EABC concept: Execution Scope
Existing cMCP input / evidence: cMCP authorizes the MCP execution path.
Optional profile extension: Declare the execution paths that are intended to be capable of producing the protected effect.

EABC concept: Authority Binding
Existing cMCP input / evidence: Cedar decision authorizes the principal/tool/action in the cMCP context.
Optional profile extension: Bind the authorization result to effect_id and execution_scope.

EABC concept: Evidence
Existing cMCP input / evidence: Existing audit / TRACE evidence correlates the authorization and tool execution.
Optional profile extension: Optionally correlate the authorization binding with downstream effect evidence.

Existing cMCP identity and authorization information can remain unchanged; the profile adds the effect-level semantics.

2. Proposed optional fields

For example, an authorization result could carry:

{
"effect_binding": {
"effect_id": "order:O-2026-10-02-C123",
"effect_type": "database_write:orders",
"execution_scope": [
"mcp:tool:order_create",
"backend:orders-service"
],
"decision": "allow",
"valid_until": "2026-10-02T17:40:00Z",
"nonce": "..."
}
}

The catalog could declare the effect model independently of a particular order instance:

{
"tool_name": "order_create",
"effects": [
{
"effect_type": "database_write:orders",
"identity_scheme": "order:<order_id>",
"intended_paths": [
"mcp:tool:order_create",
"backend:orders-service"
]
}
]
}

The exact encoding is only illustrative at this stage; the purpose is to show the required semantics rather than prescribe a cMCP implementation.

3. What a downstream verifier could establish

Given a valid, untampered binding and the corresponding cMCP evidence, a downstream verifier could establish that:

1. an authorization decision existed for the relevant principal and execution;
2. the decision was explicitly bound to effect_id;
3. the binding declared an execution scope;
4. the binding was within its validity interval;
5. the available evidence correlates the authorization with the relevant execution.

A verifier could not, from these fields alone, establish:

• that the order was actually committed in the authoritative database;
• that no other execution path could produce the same effect;
• that the declared execution scope is complete;
• non-bypassability of the enforcement boundary.

Those require evidence or enforcement properties outside the authorization binding itself.

4. Cases

A. Denial

If Cedar returns deny, no valid Authority Binding is issued for the requested effect.

A downstream verifier therefore has no EABC authority binding authorizing:

effect_id = order:O-2026-10-02-C123

The denial remains a cMCP authorization result; EABC does not replace Cedar policy evaluation.

B. Replay

Suppose a previously issued binding is presented again.

A verifier can reject it if the binding is expired. However, expiry alone does not prevent replay during the validity interval.

Replay protection therefore requires an additional verifier-side condition, such as a nonce, sequence number, or one-time-use state.

That mechanism is outside the minimal EABC contract and is explicitly left as an implementation/deployment choice.

C. Alternate path

Suppose a direct HTTP or SDK call attempts to create the same order without passing through cMCP.

If that path does not consume or verify the EABC Authority Binding, cMCP has no visibility into the execution and cannot establish that the effect was authorized.

This is therefore unverified execution relative to the profile.

If the alternate path does verify the Authority Binding, the verifier can determine whether that path is within the declared execution_scope.

Importantly, the presence of a path in the scope does not by itself prove that the path is actually mediated or non-bypassable. That remains a deployment/enforcement property.

5. Execution and outcome status

Situation: MCP execution with valid Authority Binding
What the profile can establish: Authorization is evidenced and bound to the declared effect.

Situation: Binding expired
What the profile can establish: Binding is invalid.

Situation: Binding replayed during validity interval
What the profile can establish: Requires explicit replay protection; not established by expiry alone.

Situation: Actual database commit
What the profile can establish: Not established by cMCP authorization evidence alone.

Situation: Alternate path without binding verification
What the profile can establish: Unverified relative to the profile.

Situation: Alternate path with binding verification
What the profile can establish: Authorization can be checked against the declared scope.

Situation: No-bypassability of alternate paths
What the profile can establish: Not established by the profile.

6. Scope of this proposal

This remains an optional external interoperability profile.

It would be:

• additive;
• implementation-independent;
• compatible with the existing cMCP authorization model;
• independent of any particular enforcement substrate;
• explicit about what can and cannot be established from the available evidence.

The purpose is not to change the cMCP gateway mediation model, but to make an authorization decision consumable at a downstream execution boundary with explicit effect-level semantics.

This example is intended to provide a bounded basis for assessing architectural fit and, if useful, determining the appropriate repository/component for a minimal prototype.

[imran-siddique]

@omwei-org two of the three already have homes. Effect correlation: cMCP audit entries carry execution_id, and a TRACE record can point at downstream effect evidence through references with rel: observed-effect. Authority binding: the Cedar decision, plus rel: authorized-intent for a grant held elsewhere. Execution Scope, the paths able to produce an effect, is the new part. Build the profile in the integrations repo on those fields and open an issue there with your order_create example mapped to them; whatever does not map is worth a cmcp issue.

[omwei-org]

Thanks Imran.

We mapped the existing cMCP mechanisms for order_create in integrations #290:

• authority → Cedar + authorized-intent
• execution/effect correlation → execution_id + observed-effect
• execution binding → Execution Action Binding

The remaining gap is 'Execution Scope': how we declare and evidence that all paths capable of producing the protected effect are within the enforcement boundary.

We left this explicitly 'OPEN / NOT CLAIMED' rather than inferring complete mediation from MCP gateway mediation, and opened cMCP #736 for that question.

Would appreciate your guidance on where you think this belongs in cMCP.

[imran-siddique]

@omwei-org answered on cmcp#736: execution scope belongs with the confinement work, split into agent-side paths that can be tested and deployment-side paths that are declared and independently observed.

[omwei-org]

Thanks, Imran. That is exactly how we’ve structured the proposal in PR #740:

• agent-side paths → enforced and tested through the confinement work
• deployment-side paths → declared as boundary statements and not treated as established without independent observation
• order_create → worked example of the declared execution path set

The profile therefore treats NON_BYPASSABILITY as scoped to the declared execution boundary, rather than claiming universal mediation from gateway execution alone.

The confinement workflow is currently waiting on the repository approval gate for the PR, so the Linux-Docker job has not actually run yet.