The Gateway Is a Proxy
When your application sends a request, the gateway validates it, picks the correct government-authorized backend (AWS GovCloud, GCP Assured Workloads, or Azure Government), forwards the request, and returns the response. The gateway does not execute tool calls, make follow-up requests based on model output, or call external URLs. Tool call governance is described below.Tool Calls
The gateway supportsfunction tools. You define tools in your request, the model decides whether to call them, and the gateway returns the model’s tool call response to your application. The gateway never executes tool calls. It has no HTTP client for dynamic URLs, no code execution engine, and no ability to make outbound requests based on model output.
This means the gateway itself cannot exfiltrate data through tool calls. Your application can, and the gateway helps you prevent that in two ways.
What the gateway does for you
At the request boundary. The gateway inspects every tool schema before forwarding it to a model provider. Schemas that describe an outbound destination are rejected with400 invalid_request_error. Property names like destination_url, webhook_url, callback_url, forward_to, send_to, post_to, target_url, upload_url, ingest_url, sink_url, and a few others are treated as the shape of an exfiltration tool and refused. The check walks the full JSON Schema tree, so hiding the name in a nested property, an array items schema, or a $defs entry does not bypass it. See Chat Completions: Rejected Tool Schemas for the full list.
Ambiguous names like url, endpoint, and host are allowed because they legitimately appear in read tools (a database connection helper with host and port, a tool that reads a specific record from your internal API by url, and so on). That is where the second layer comes in.
At the response boundary. When a model returns tool calls, the gateway parses each arguments payload and looks for outbound destinations (URLs with a scheme, raw IP addresses). When any are found, the response carries an advisory field called x_consus_governance that lists every destination by tool call id and tool name. The tool call itself is not modified; you still get the real arguments so your application can run. This is a signal, not a block. We do not stop the tool call from reaching you.
What you need to do
Honor thex_consus_governance field. When it is present, each flagged tool call contains a destination chosen by the model, not by your application. Before executing the tool call, check the destination against an allowlist of hosts you actually use; if it is unfamiliar, surface the decision to a human or route it through a policy check. An audit record is written on our side as well, so repeated flags on a single API key are visible to us during incident review.
Beyond the flag, the same application hygiene still applies: keep an allowlist of tool names your application supports and reject anything else, and compare any URL that appears in a tool call against a list of endpoints you actually use before making a network call.
If your application handles CUI or other sensitive data, run it in an environment with outbound network restrictions. A VPC with no internet access, a proxy with a domain allowlist, or a firewall that only permits connections to known endpoints. This way, even if your application has a bug that blindly executes a flagged tool call, the network layer stops the data from leaving.
Content Filtering Is Not Provided
The gateway does not inspect the content of your prompts or the text body of model responses. It does not classify documents, detect CUI markings, flag sensitive content, or prevent you from sending controlled information to a model. The one narrow exception is the tool call argument scan described above: a structural check on JSON values for outbound destinations, not content classification. The gateway routes your request to infrastructure that is authorized to handle that data at the compliance level you specified, and that’s where its job ends. If you requestclaude-sonnet-4-5:il5, the gateway guarantees that your prompt is processed on DoD IL5 authorized infrastructure. It does not verify that the content you sent actually requires IL5 handling, and it does not prevent you from sending IL5 content to an IL2 endpoint. Choosing the correct compliance level for your data is your responsibility.
If your organization requires data loss prevention, content classification, or automated CUI detection, those controls belong in your application layer, not in the gateway.
API Key Security
Your API key authenticates every request to the gateway. Do not embed API keys in client-side code that ships to end users (browser JavaScript, mobile apps, desktop applications). Anyone who can inspect the code can extract the key and make requests on your behalf, consuming your budget and potentially accessing models under your account. Keep API keys in server-side environment variables or a secrets manager. If you suspect a key has been exposed, contact us and we will rotate it. Keys can be disabled within minutes. We also rotate keys periodically as part of standard operational security.System Prompts
The gateway passes your system prompts to the model provider exactly as you send them. It does not inject, modify, or wrap them. Whatever you put in thesystem message goes directly to the model.
This means your system prompt is part of your security surface. If you include credentials, internal URLs, or sensitive configuration in your system prompt, the model has access to that content and could potentially include it in responses. Models generally resist attempts to extract system prompts, but this is a model-level safety behavior, not a guarantee from the gateway.
Keep system prompts focused on task instructions. Store secrets in your application, not in prompts.