Enforced Model and Connector Gateways

Target architecture — not the current operating contract

This page preserves the broader gateway contract. Use the current Gateway APIs for implemented routes and behavior.

The current gateways enforce Organization/Team/owner/key/customer budgets with physical-attempt reservations and settlement. The Model Gateway already supports capability-safe provider fallback under deployment retry-safety rules. Reusable YAML guardrail policies apply at Organization and virtual-model scope and remain pinned across provider fallback; see Model guardrails. Purpose-aware policy, broader targeting and orchestration proposals below remain target architecture. Current durable administrator/conversation approvals remain documented in the current guides.

The current inference listener exposes model discovery, Chat Completions, stateless Responses, embeddings, reranking, MCP and Production deployment invoke. A separate private listener owns control and readiness. Calls carry or receive W3C Trace context, emit Trace-native governed evidence, and use standard OTLP for independent spans; no Mission Control Run or Trace lifecycle endpoint exists.

Mission Control uses two separate enforcement boundaries because inference and enterprise tool execution have different protocols, risks, and operating controls. Models never enter the connector catalog, and MCP tools never route through the Model Gateway.

Shared gateway contract

Both gateways:

• Accept a registered human or workload principal, customer and environment, resource identity and immutable version, Trace context, requested capability, and idempotency context. A future Run context may extend this target contract without changing current W3C propagation.
• Resolve only approved, environment-available targets and pinned versions.
• Enforce capability grants and obtain versioned access and policy decisions from the Control Kernel.
• Propagate structured status, timing, usage, cost, and failure data into the shared event and evidence contract.
• Use explicit timeouts, bounded retries, circuit breakers, credential isolation, and typed error codes.
• Refuse direct-call fallback when the gateway or a required control dependency is unavailable.

The detailed recovery contract is defined in reliability and failure semantics.

Model Gateway

The Model Gateway exposes an OpenAI-compatible inference interface to native and external runtimes. It owns:

• Provider and deployment resolution through a stable Virtual Model.
• Provider credential isolation and approved egress.
• Environment and resource allowlists plus capability grants.
• Routing, fallback, quota, budget, concurrency, and rate limits.
• Input and output guardrail, validation, purpose, and redaction profiles.
• Token, latency, error, availability, and estimated-cost attribution.
• Trace correlation plus evidence publication; a future Run layer remains target architecture.

The Control Kernel provides identity, resource configuration, grants, and policy decisions. Model Management provides provider, deployment, virtual-model, route, health, and economics configuration. The gateway performs inference routing against those approved definitions.

A request resolves in this order:

Resolve caller and resource version
  -> resolve virtual model and current routing policy
  -> authorize the requested inference capability
  -> select an approved, healthy deployment
  -> apply quota, budget, concurrency, and guardrail controls
  -> invoke the provider with isolated credentials
  -> validate the response
  -> publish route, usage, cost, status, trace, and evidence metadata

Approved fallback chains stay inside the gateway. Every fallback target is separately approved for the environment, data class, use case, quality, latency, and cost policy. Provider failure cannot trigger a direct provider call from the runtime.

Bounded prompt and response trace content follows the stored capture policy, access, hard-exclusion, retention, and deletion rules. Broader purpose/redaction/legal-hold policy remains part of the resource and evidence model.

Connector Gateway

The Connector Gateway is the exclusive invocation path for registered MCP tools. It owns:

• MCP transport, protocol negotiation, and structured errors.
• Server authentication brokering from customer-managed secret references.
• Connector and immutable tool-version resolution.
• Typed argument and result validation.
• Capability-grant checks and contextual policy requests to the Control Kernel.
• Durable approval pause and safe, idempotent resumption.
• Timeout, bounded retry, circuit-breaker, duplicate-suppression, and result-normalization behavior.
• Invocation, decision, usage, cost, action, and outcome evidence.

Every invocation follows the same sequence:

Resolve caller identity and execution context
  -> resolve registered MCP tool and pinned version
  -> validate typed arguments
  -> evaluate access and contextual policy
  -> allow, deny, or create a durable approval
  -> re-evaluate identity, policy, version, health, and context after any delay
  -> invoke the MCP tool
  -> validate and normalize the result
  -> publish evidence and outcome signals

The connector's tool-level classification determines its baseline posture:

Class	Enforcement emphasis
Data	Caller and source access, data classification, purpose, lineage, freshness, and citation
Decision	Input and output references, decision version, confidence or validation, reproducibility, and outcome linkage
Action	Strong authorization, scope, risk and value thresholds, stable idempotency, approval, operating window, and recovery or compensation

Data and Decision Connectors must be side-effect-free from the caller's perspective. Any externally meaningful effect makes the tool an Action Connector.

Approval and delayed execution

approval_required is a durable policy result, not an open network request. The Connector Gateway records the validated request and idempotency identity, then releases execution capacity. Approval changes do not themselves execute the tool.

Before resumption, the gateway re-resolves the principal, capability grant, current policy, approval validity, connector version and certification, server health, operating window, and time-sensitive context. A changed or expired condition can deny, cancel, or request a new approval. An approved request executes at most once for its idempotency key.

Non-bypass rule

Native runtimes, external runtimes, Workflow workers, indexing workers, application services, and browser clients may not connect directly to model providers or registered MCP servers for governed work. Action Connectors fail closed whenever identity, policy, approval, version, or evidence guarantees are unavailable. A bypassed request may be observed as an incident, but it is never relabeled as governed.

Current governance mapping

The current source release uses Organizations, Teams, real user/service-account virtual keys and separate human management roles. Agent is managed application content; deployments own secretless execution access and publisher funding. Observe uses Requests, Traces, Sessions and Usage with separate metadata/content/export permissions. Historical identity terms in this target proposal are not the operating contract. See Current release.