Model Provider Routing Gate

Why this page exists. The secure context layer is not complete until it can answer one operational question: which model/provider is allowed to receive this context for this workflow, right now?

Rechecked source anchors against the public MCP specification 2026-07-28 on August 21, 2026.

The product bet

SecurityRecipes is positioned as the Secure Context Layer for Agentic AI. That means context is not just retrieved, cited, signed, and egress-checked. It also needs a provider route decision before the next model call starts.

The enterprise version of agentic AI will be multi-provider. Teams will want OpenAI, Anthropic, xAI, private-cloud models, local models, and specialized guardrail models in the same estate. The problem is not choosing a favorite model. The problem is proving that the selected model route matches:

  • the workflow,
  • the data class,
  • the autonomy level,
  • the provider contract,
  • the tenant region,
  • the retention/training posture,
  • the MCP and tool guardrails,
  • the telemetry contract,
  • the run receipt,
  • and any human approval required for sensitive context.

The Model Provider Routing Gate makes that decision inspectable. It is a provider-neutral policy pack that enterprises can fork into their own model registry while keeping the open evidence shape stable.

Workflow at a glance

Model Provider Routing Gate workflow

Choose an eligible model/provider route from data, task, region, risk, capability, and fallback policy before any context is sent.

agent-runtime

  1. Signal

    Receive the model request

    Capture workflow, task, model capabilities, identity, tenant, data classes, region, latency, cost, and action impact.

  2. Scope

    Filter eligible routes

    Apply provider approval, residency, retention, training-use, encryption, contract, capability, and availability constraints.

  3. Decision

    Score route risk

    Evaluate private context, secrets, regulated data, tool use, autonomy, safety controls, outage state, and fallback equivalence.

  4. Action

    Select or block

    Choose the lowest-risk compliant route, use an approved fallback, require redaction/approval, hold, or deny the request.

  5. Proof

    Write the routing receipt

    Record candidate routes, exclusions, selected model/provider, transformations, policy, cost class, and fallback state.

Decision gate

Is there an approved route satisfying data, region, capability, risk, contract, and fallback requirements?

Proceed

Send only the authorized context to the selected route.

Hold or stop

Redact, hold, or deny when no compliant provider/model route exists.

Evidence to retain

  • request data/risk classification
  • candidate route evaluation
  • selected-route receipt

Expected outputs

  • model routing decision
  • redaction/approval requirement
  • no-route denial

What was added

  • Source profile: data/assurance/model-provider-routing-profile.json
  • Generator: scripts/generate_model_provider_routing_pack.py
  • Runtime evaluator: scripts/evaluate_model_provider_routing_decision.py
  • Evidence pack: data/evidence/model-provider-routing-pack.json
  • MCP tools: recipes_model_provider_routing_pack, paired with recipes_playbook_plan using playbook id model-provider-routing-gate.

Regenerate and validate the pack:

python3 scripts/generate_model_provider_routing_pack.py
python3 scripts/generate_model_provider_routing_pack.py --check

Evaluate a tenant-sensitive route before a model call starts:

python3 scripts/evaluate_model_provider_routing_decision.py \
  --workflow-id vulnerable-dependency-remediation \
  --provider-id frontier-enterprise-provider \
  --model-id frontier-code-and-security-reasoning \
  --route-class tenant_sensitive_remediation \
  --data-class customer_source_code \
  --data-class customer_finding_metadata \
  --autonomy-level bounded_agent \
  --tenant-id tenant-123 \
  --tenant-region us \
  --provider-region us \
  --enterprise-contract \
  --dpa-in-place \
  --zero-data-retention \
  --training-opt-out \
  --mcp-gateway-enforced \
  --tool-guardrails-enforced \
  --output-guardrails-enforced \
  --telemetry-redacted \
  --run-receipt-attached \
  --egress-decision allow_tenant_bound_egress \
  --human-approval-id approval-123 \
  --expect-decision allow_guarded_route

Routing contract

The default state is hold_for_model_provider_review. A route is not trusted just because a model is capable. The decision contract requires:

Proof What it prevents
Approved provider profile Shadow AI, personal accounts, unmanaged agents, and revoked contracts.
Approved model route Model misbinding and ad hoc provider/model selection.
Data-class allowlist Customer code, regulated data, secrets, and browser context crossing the wrong boundary.
Autonomy ceiling High-impact autonomy using a route intended only for assisted or bounded work.
ZDR / private runtime Sensitive context being retained, trained on, or reused outside the tenant boundary.
DPA and residency evidence External processor and regional-policy drift.
MCP gateway enforcement Tool-backed context bypassing resource, audience, scope, and session controls.
Tool/output guardrails Model calls starting before tool or output tripwires can block side effects.
Redacted telemetry Prompts, tool arguments, outputs, and retrieved context becoming a new data sink.
Run receipt binding Provider decisions that cannot be reconstructed during review or incident response.
Egress decision Model routing bypassing the context egress boundary.

Route classes

The generated pack ships with five reference routes:

Route Default decision Intended use
public-context-frontier-route allow_approved_route Public SecurityRecipes context, generated open evidence, and vulnerability intelligence.
tenant-remediation-frontier-route allow_guarded_route Tenant remediation work through an approved frontier provider under enterprise controls.
private-runtime-restricted-route allow_guarded_route Private runtime for tenant source, regulated data, and restricted support context.
browser-and-untrusted-content-guardrail-route allow_guarded_route Blocking guardrail classification before browser or untrusted-content work proceeds.
shadow-ai-deny-route deny_unapproved_route Personal accounts, unmanaged providers, and unsanctioned model hosts.

Forks should replace abstract model IDs such as frontier-code-and-security-reasoning with their approved OpenAI, Anthropic, xAI, private-cloud, or local model SKUs.

Runtime decisions

The evaluator returns:

  • allow_approved_route when a low-risk route has all required evidence.
  • allow_guarded_route when a sensitive route is acceptable with guardrails, receipts, telemetry, egress approval, and human approval.
  • hold_for_model_provider_review when the route is plausible but proof is missing.
  • deny_unapproved_route when the provider, route, workflow, data class, or autonomy request is not approved.
  • kill_session_on_provider_signal when the request includes secrets, cross-tenant context, non-HTTPS endpoints, denied egress, or another route-level kill signal.

Why this matters

The review-ready story is simple: SecurityRecipes can become the neutral policy layer that makes multi-model agentic AI safe to approve. Open knowledge gets teams started. The hosted-ready surface is the hosted provider-routing PDP, tenant-specific model registry, contract-state checks, route telemetry, procurement exports, and trust-center evidence.

That is valuable to a frontier lab, an AI coding platform, a cloud platform, or a security vendor because it reduces the reviewer friction around letting agents use powerful models on real enterprise context.

MCP examples

Inspect all provider routes:

recipes_model_provider_routing_pack()

Review one workflow’s preferred routes:

recipes_model_provider_routing_pack(
  workflow_id="sast-finding-remediation"
)

Plan a route:

recipes_playbook_plan(
  playbook_id="model-provider-routing-gate",
  finding="Tenant-sensitive remediation data needs an approved US-region model route."
)

Industry alignment

This feature follows current guidance:

  • MCP Authorization 2026-07-28 for resource indicators, audience-bound tokens, HTTPS, PKCE, scope challenges, and token validation.
  • MCP Security Best Practices for confused-deputy prevention, token-passthrough denial, scope minimization, SSRF controls, session safety, and audit trails.
  • OWASP Top 10 for Agentic Applications 2026 for agent goal hijacking, tool misuse, privilege abuse, context poisoning, insecure inter-agent communication, cascading failures, and rogue-agent containment.
  • OWASP MCP Top 10 for model misbinding, context spoofing, prompt-state manipulation, insecure memory references, and covert-channel concerns in MCP-shaped systems.
  • OpenAI prompt-injection guidance for source-sink reasoning, constrained impact, and user confirmation before sensitive transmissions.
  • OpenAI Agents SDK Guardrails and Tracing for input, output, and tool guardrails plus trace evidence.
  • Anthropic Claude Code Security for read-only defaults, explicit approvals, trusted MCP server configuration, isolated execution, and command review.
  • CISA AI Data Security for AI lifecycle data provenance, integrity, access control, monitoring, third-party handling, and incident evidence.
  • NIST AI RMF and NIST AI 600-1 for govern/map/measure/manage practices and generative-AI risk management.

See also