Skip to main content

The AI gateway

The AI gateway is the point every request to an AI model passes through. Nothing on the platform talks to a model vendor directly. An agent that asks Claude, GPT or Mistral a question asks the gateway, and the gateway decides.

One request, one decision​

Every request gets exactly one policy decision. Among other things, the gateway checks:

  • The model. Is this model on the list the customer has allowed?
  • The budget. Does the request fit within the customer's budget?
  • The rules. Does the content match the customer's ground rules, for example the requirement that pseudonymisation is active?

If the decision is negative, the request does not reach the vendor. Not a single byte goes to a model the customer has not approved. The decision is recorded, also when it is a refusal.

Why one decision per request

With exactly one decision per request, you can point out afterwards why each model request was allowed. There is no request that slipped through "in between", and no request with two conflicting decisions.

Rules in the gateway, not in the prompt​

A common approach is to put rules in the instruction to the model: "do not share personal data". A model can ignore such an instruction, misunderstand it or forget it in a long conversation. Plainwater AI does not work that way. Every rule is enforced in the gateway, where the model cannot get around it. The instruction to the model may explain the rule, but enforcement never depends on it.

What else the gateway does​

  • Strip the vendor's built-in tools. Some models offer their own tools, for example web search. The gateway removes them from the request. An agent only works with the tools the platform offers, and each of those tools has its own rules.
  • Replace names. If a table or column name goes to the model, it is a pseudonym. See Pseudonymisation.
  • Track usage. Every request is booked per customer. Usage is append-only: nothing is ever overwritten or removed, and a retry does not count twice.
  • Record. Prompts and answers are stored encrypted. Whoever is entitled reads them back with the real names. Every read is itself recorded. See Audit.

The gateway for tools​

Besides the gateway for models there is a gateway for tools. Every tool an agent uses to read or measure data goes through a single checkpoint. There, on every call, the platform checks again:

  • which source the agent may read;
  • which data access mode that source is in;
  • which work mode the task has;
  • whether every name in the call is a known pseudonym.

That check happens on every call, not only at the start of a task. A source can be added while a task is running, or a rule can become stricter. The next call then follows the new rule.

Every tool has a fixed class: it returns either metrics only (counts, structure, statistics) or values. There is no default. A new tool without a class is refused.

Also for your own AI tool​

If you work with your own AI tool via MCP, the model runs outside the platform. The gateway then does not see the model requests themselves. In that case all protection sits on the tools: whatever your AI tool gets from the platform goes through the same tool gateway with the same rules. See Ways of working.

Example​

A consultant asks: "Why has the nightly load of the sales table become slower?" The agent wants to read the procedure definition, look at the slowest queries and check the table's statistics.

  1. The first model request goes to the gateway. The model is on the customer's list, there is budget, pseudonymisation is active. Allowed.
  2. The agent calls the tool for the procedure definition. The tool gateway checks the source, the mode and the names. The definition goes to the model with pseudonyms.
  3. The model's answer mentions t_0042. On screen the consultant sees Sales.

See also​