Skip to main content
This is in development. Details may change before it is available.
When your applications send model requests through the AI Gateway, Altrum checks each one against the live guardrail version of whoever the key belongs to:
  • A key attached to an AI system is checked against that AI system’s live version. If the AI system has no live version, its requests are not checked, and the organization’s guardrails do not stand in for it.
  • An organization key, a person’s key, and a request that carries the caller’s own provider key are checked against the organization’s live version, if it has one.
An AI system’s guardrails take effect from its next request after you apply them. The same goes for attaching a key to an AI system: the next request uses the AI system’s guardrails.

​
The order of checks

1

Before the model

Guardrails that apply to What people send check every message in the request, whatever its role, and the arguments of every tool call in it. A block stops the request: it never reaches the model provider. A mask replaces the sensitive text before it is sent. A request is checked once, even when Altrum then tries a fallback model.
2

After the model

Guardrails that apply to What the model answers check every answer the model returns, including a refusal and the arguments of a tool call. A block withholds the answer. A mask replaces the sensitive text before your application receives it.
Long text is checked in pieces. A request with more text than can be checked is refused with a message that says to send less at once.

​
A check that cannot be made stops the request

If Altrum cannot check a request, for any reason, the request is not sent to the model. If it cannot check an answer, the answer is withheld. A failed check never lets unchecked text through. A guardrail setup that Altrum cannot read is treated the same way: the request is refused, not let through. A key whose owner has no live guardrails is not checked, and the request is recorded as unguarded.

​
Streaming

  • When every guardrail on answers is set to Log only, the answer streams to your application as the model writes it. Altrum checks the whole answer once the stream ends and records what it found. The last event of the stream waits for that check.
  • When any guardrail on answers can Block or Mask, Altrum holds the answer, checks it whole, and then streams it to your application. The first words arrive later, and no unchecked text ever reaches the caller. A stream that is cut off while it is held releases nothing.
  • When an answer is blocked, the caller receives one error and no end marker.
A mask on an answer replaces the sensitive text wherever the answer repeats it, whichever API your application called.

​
Tool calls

Calls to MCP tools made through Altrum are checked with the same guardrails: the arguments before the tool runs, and the result before it returns to the model. Listing the tools a key may use is not checked. Arguments that a mask would turn into something that is not valid JSON are blocked instead. See MCP tools.

​
What Altrum records

For every request: whose guardrails applied and which version, whether the request and the answer were checked, and how the request ended. For every check that found something: which guardrail fired, in which direction, what it did (logged, blocked or masked) and the kind of thing it found, such as a data type, a topic name, or the word you configured. Never the text that matched. See Request logs.

​
What your application sees

A blocked request, a blocked answer and a check that could not be made each return an error in the format of the API your application called. It names the guardrails that fired and never your text. Handle it as you would a provider’s refusal. The codes are in Error messages.