AI Gateway

One layer for all your applications' language model traffic: masking, audit trail, quota, and usage collected in one place. Your code stays the same.

An AI gateway is the layer that sits between your applications and language models. Instead of going straight to the provider, requests pass through it first; the organization sees every request in one place and applies its rules in one place.

Gurubase Gateway runs this layer in Turkey and adds one more step at the moment of passage: personal data is masked before the request leaves for the external model.

Why a single point of passage

When usage is scattered, each team goes to its own provider, with its own key, from its own code. No one can see who sent what across the organization; this is the picture known in enterprise literature as shadow AI. A single point of passage changes that in four places.

Personal data control. Masking is applied in one place. Instead of expecting every application to get it right on its own, the rule sits at the point of passage and works the same way no matter which team the request comes from.

Visibility. Which team uses which model and how much, which categories are detected and how often, which requests returned an error. It is collected on a single screen, broken down by virtual key and model.

Resilience. When a provider slows down or returns an error, the decision to retry or switch to an alternative is made at the gateway, not in application code.

Budget. Token budget, quota, and warning thresholds are tracked per key; usage is read from one place across the organization.

What changes in your code

Two values. The rest stays the standard OpenAI SDK: the model name, the parameters, and the response format are the same.

  client = OpenAI(
-     base_url="https://api.openai.com/v1",
-     api_key=OPENAI_API_KEY,
+     base_url="https://gw-tr.gurubase.io/v1",
+     api_key=VIRTUAL_KEY,
  )

The provider’s real key stays inside the Gateway; your application carries only the virtual key you generated in the panel. For a step-by-step switch, see Gateway integration.

Guardrails

Masking is the first guardrail running at the point of passage, and the default one. Input is masked on every request; response masking is turned on optionally. Prompt injection protection and hallucination protection will be added to the same layer; they are coming soon. For details and current status, see Guardrails.

Models and providers

The Gateway offers a single OpenAI-compatible interface. Behind it there can be general providers such as OpenAI, Anthropic, and Gemini, or models running on your own servers; the only thing that changes on the client side is the model field. You get the models you can access from the /v1/models endpoint. For provider selection, retry, and fallback behavior, see Models and providers.

Visibility and governance

The panel makes the data that accumulates at the gateway readable: request and token counts, characters processed, the distribution of detected categories, and the breakdown by model and virtual key. Administrative events are written to an append-only audit trail and can be exported. For the screens, see Panel; for retention and access rules, see Security.

Runs in Turkey

The Gateway and masking run on infrastructure hosted in Turkey. Only masked text goes to the external model; raw personal data is processed in Turkey and stays there. If masking cannot be completed, the request does not go to the external model at all, and the Gateway returns a 502. This behavior is called fail-closed; the details are on the Concepts page.