SOLUTIONS · 11
Change the SDK’s base URL. Keep everything else.
Applications connect to the Wardline gateway with the OpenAI or Anthropic SDKs they already use; only base_url and the API key change. The gateway inspects the request, enforces the decision and forwards it along the configured route to an in-house model or a cloud provider.
THE PROBLEM
Every team wires up its own provider
One team calls a cloud API directly, another runs an open-weight model on its own server. Keys end up scattered across application configs, and nobody can see centrally which data goes to which provider.
Adding security controls to each application separately is slow and inconsistent. A single point of passage applies the same policy to every application and every provider at once.
HOW IT WORKS
Step by step
Compatible endpoints
chat/completions, responses and embeddings in OpenAI format; messages in Anthropic format. Streaming responses and tool calls are supported.
Identity and tenant
The API key identifies the application and the tenant. Only the key’s prefix is stored as its identifier; the key itself is shown once.
Provider library
Adapters for OpenAI, Anthropic, Bedrock, Gemini and in-house models; any OpenAI-compatible base_url can be added. Provider addresses go through SSRF checks.
Routing
The model name, the application and the policy decision determine the route. A request with personal data can go to an in-house model, to a provider in an allowed region, or be refused.
Cost signal
An estimated cost per request is calculated from price tables; when an application or tenant budget is exceeded, policy decides what happens.
SDKs
The Go, JavaScript and Python SDKs add helpers for tool checks, agent sessions and the RAG filter, with adapters for LangChain and the Vercel AI SDK.
DECISIONS
Which decision you get, and when
| Decision | When | Example reason code |
|---|---|---|
| ALLOW | Nothing was found: the request goes to whichever provider the route selects. | POLICY.DEFAULT_ACTION |
| MASK | A request with personal data is masked and routed to an in-house model. | ROUTE.LOCAL_PII |
| DENY | The target provider does not satisfy the tenant’s data residency rule. | RESIDENCY.TARGET_NOT_ALLOWED |
| DENY | The application’s or tenant’s cost budget has been exceeded. | COST.BUDGET_EXCEEDED |
EXAMPLE
Personal data goes to the in-house model
A credit analysis application uses a cloud model by default. In one request a customer’s phone number is detected, and policy says requests with personal data go to the in-house model. The gateway masks the phone number, forwards the request to the model in the data centre and sets the ROUTED_LOCAL flag. Nothing changes in the application code.
| Decision | MASK |
|---|---|
| Endpoint | /v1/chat/completions |
| Requested model | cloud · general purpose |
| Applied route | in-house model |
| Finding | phone · bytes 96–108 |
| Reason codes |
|
| Flags |
|
| Risk score | 0.92 |
CONFIGURATION
What administrators control
Providers
Which providers and models may be used; provider keys are kept on the organisation’s side.
Routes
Routing by model name and application, with a local model for personal data.
Data residency
The regions allowed while personal data is present.
Budget
A cost limit per application and per tenant, and the decision applied when it is exceeded.
RELATED
Capabilities that work alongside
See it on your own traffic.
In a demo session we walk through this flow with examples your security team picks, in the console’s evidence viewer.
Request a demo