Route the call.Preserve its context.Runtime decides.
MCP Gateway is the governed entry surface for supported MCP traffic. It preserves trusted identity and scope context as tool requests move to Keon Runtime. Runtime—not the Gateway—evaluates policy, authorizes effect, and emits the receipts returned with the outcome.
One request. Two distinct responsibilities.
The call path stays legible because transport and authority are not collapsed into one component.
- 01Supported client call
An MCP-compatible client sends a tool request through a configured Gateway connection.
- 02Context preserved
The Gateway admits the supported request with trusted tenant, actor, scope, and correlation context intact.
- 03Runtime decides
Runtime evaluates policy and authorizes, denies, or stops the effect-bound request.
- 04Outcome returns
The Gateway carries the Runtime outcome and available receipt references back in the MCP response.
Add a governed entry surface without assigning authority to the adapter.
Connect through MCP. Keep authority in Runtime.
- Keep the MCP surface
- Use a supported MCP connection instead of teaching an agent that the Gateway has authority it does not possess.
- Carry trusted context
- Preserve tenant, actor, scope, and correlation context as the request moves toward authorization.
- Receive governed outcomes
- Return Runtime decisions, execution outcomes, and available evidence references through the client-facing response.
Three tiers. One authority boundary.
What a connection can reach is set by its package tier. What it is allowed to do with that reach is still decided by Runtime.
Effect-bound tool requests routed to Runtime for authorization before execution, a decision-only preflight for policy rehearsal, launch hardening review, and bounded inspection of supplied untrusted content.
Memory writes that require an authorizing Runtime decision before anything is stored, and governed reads over that memory: search, receipt retrieval, causal lineage, signed evidence packs, and deterministic replay verification.
Non-effecting deliberation, comparison, adversarial review, collapse, and handoff preparation. A single dispatch path crosses the execution boundary, and it routes through Runtime carrying a memory lineage reference that is verified against the requesting tenant first.
- Tiers are additive. A Collective tier reaches every capability below it.
- The published tool surface is filtered to the tier. Capabilities outside it are not listed and not callable.
- An out-of-tier request is refused on entitlement. It is not quietly downgraded to something weaker.
- Entitlement is checked per capability, not once at connection time.
The Gateway does not become the decision-maker.
A supported integration preserves the separation between bringing a request to the boundary and granting that request authority to cause an effect.
The Gateway handles supported MCP entry, trusted context preservation, request shaping, Runtime handoff, and response preservation.
Runtime evaluates authority before consequence, controls effect-bound execution, and emits the receipts that outrank narrative.
Compatibility does not weaken the rule.
- 01MCP compatibility is a transport property. It is not execution authority.
- 02The Gateway routes governed intent. It does not evaluate or grant authorization.
- 03Runtime unavailability or missing trusted context must not become permission to proceed.
- 04Runtime emits the authoritative decision and execution receipts; the Gateway preserves them in transit.
- 05Every request reaches a governed terminal state and gets an ingress lineage record for it — refusals, entitlement failures, and unreachable backends included.
Evaluate the boundary against your actual tool path.
Integration fit depends on supported client transport, trusted identity, scope, and the effect boundary you need Runtime to govern. Compatibility alone is not a production-readiness claim.
Bring the real call path. Review the real authority boundary.