Where a model gateway policy stops: finding bypass paths

A configured route is not coverage of the whole application

Changing one application's model endpoint establishes one intended path. It does not automatically configure a queue worker, an older SDK client, or a network-capable tool. As a concrete integration example, Cloudflare's Bedrock gateway documentation describes replacing a provider endpoint with a gateway URL. That documents a routing configuration, not universal interception of every process's outbound calls.

The question here is coverage: which requests encounter the policy? It differs from deciding what a model may receive or which privileges an agent needs. A well-designed payload check is irrelevant to a request that never reaches it.

Trace one synthetic request through success and failure

Imagine an invented support classifier. The web process sends request R-17 to a gateway; the gateway checks policy and forwards an allowed request to Provider A. A successful response proves something about that attempt only.

Intended:
  web classifier -> gateway policy -> Provider A

Paths requiring their own evidence:
  timeout -> fallback client -> Provider B
  nightly queue -> independently configured SDK
  agent tool -> HTTP client -> external destination

Now suppose a timeout handler creates a second client using a provider's default endpoint. The retry can leave the intended gateway path even though the primary request was routed correctly. This is an original architecture example, not an observed flaw in any vendor. R-17 is a synthetic correlation label, not a real customer's request.

Choose the required failure behavior before implementation: return an unavailable result, queue work, or use an explicitly authorized fallback that receives the required policy evaluation. Availability goals should not silently create an exception.

Complete a route and egress worksheet

Create one row for each execution context, including scheduled jobs and administrative utilities. Fill in the deployed client configuration, destination, credential reference, egress rule, policy point, owner, and evidence date. Record secret identifiers or roles, never key values. This example shows questions to resolve, not verified results.

Include embeddings, file-processing requests, streaming connections, and batch submission if your application uses them. Coverage of one chat endpoint does not establish coverage of different APIs or transports.

Put credential and network controls behind the routing choice

When the topology uses provider credentials, keeping a working copy in every worker can leave those workers able to call the provider directly. Where supported, concentrate provider access in the approved execution service and give callers only the narrower credential needed for that service. Do not assume gateway authentication revokes an existing provider credential.

For AWS workloads specifically, AWS IAM guidance recommends temporary role credentials and reviewing unused permissions and credentials. Other model platforms have different mechanisms. Temporary credentials reduce their lifetime; they do not force traffic through a gateway.

Enforce required outbound destinations at the application and infrastructure layers appropriate to your environment. OWASP's SSRF guidance discusses network restrictions alongside application validation, including redirect and DNS complications. Apply those principles to your own egress design; this article is not a finding of SSRF.

A host allowlist does not authorize every path, credential, or payload on that host. A browsing tool that legitimately needs broad Internet access may require a separate process and identity without model-provider credentials. A model gateway alone cannot enforce that isolation.

Check each route without contacting real providers

Begin with recording adapters and fake credentials in an isolated fixture. Map the gateway and provider destinations to controlled stubs. Write expected outcomes before running anything. These proposed checks have not been run for this article.

1. Normal request: expect one policy decision and the permitted stub dispatch, with matching attempt identifiers.
2. Gateway unavailable: inject a timeout. Expect the declared unavailable, queued, or authorized-fallback behavior; no hidden direct-provider attempt.
3. Worker configuration drift: point a fixture worker at a disallowed endpoint. Expect rejection at the intended boundary, not merely a model refusal.
4. Tool network attempt: ask the recording tool adapter to target the provider stub. Expect the configured destination policy and no inherited provider credential.
5. Copied credential: use only a fabricated credential reference to inspect configuration paths. Do not test a real leaked key. Any real revocation or connectivity verification needs its own authorized scope.

Stub checks establish application behavior under those conditions. They do not prove deployed firewall, DNS, proxy, or identity enforcement. Verify those separately in an authorized isolated environment before claiming deployment coverage.

Report evidence per route and keep the product boundary explicit

For each row, distinguish configured, exercised, observed through policy, rejected elsewhere, and unknown. Missing gateway logs can mean no request, bypass, logging failure, or an incomplete observation window. Silence is not proof that egress was blocked. Recheck routes when SDK initialization, retry logic, workers, credentials, or network policies change.

Boundary's model-request policy checks are planned; this guide does not assert that a live Boundary router enforces these routes today. The published evidence page concerns a different, synthetic agent-action evaluator. Its local tests do not demonstrate gateway routing, network isolation, provider integration, or control over all agent tools.