# Access Models with Guardrails

Active models on the Phoeniqs Model Service now come in two variants through the same API: the standard model, and a guardrailed variant marked with a -GRC suffix (Governance, Risk & Compliance). Same base URL, same API key — you only change the model's name.

Use the -GRC variant when you want content safety and sensitive data filtering enforced at the gateway. Use the standard variant for research, evaluation, and internal tools where you want to see raw model behaviour. You can choose per request.

Teams increasingly need to show that safety controls actually run in production — on every request — rather than living only in a policy document.

This Phase 1 — baseline feature gives you those controls out of the box, so you don't have to build content safety and data filtering.

The -GRC variant screens every request at the gateway before it reaches the model. It either blocks the request (rejected with a structured error, so it never reaches the model) or masks the matched text (the sensitive value is swapped for a redacted placeholder, and the request continues).

We've tackled a specific set of categories, each with a severity threshold — low, medium, or high — that control how sensitive the check is. Low catches even borderline cases (and may flag more false positives); medium strikes a balance, and high acts only on clear, high confidence matches.

The baseline feature we've released covers:

Sensitive data & credentials — these are binary and have exact pattern matching (a string either matches or it doesn't).

In short: high-risk secrets are blocked; lower-risk identifiers are masked.

The -GRC variants sit behind a LiteLLM gateway and attach policies to specific model aliases — in front of our model runtime. For a -GRC alias, the gateway runs the pre-call checks before forwarding the request to the model; standard aliases skip the policy and go straight through.

Any alias ending in -GRC picks up the guardrail stack automatically, with no per-model setup. Both aliases point to the same underlying weights — the only difference is whether the policy is attached. The standard alias (e.g. inference-llama4-maverick) serves the model raw; the -GRC alias (inference-llama4-maverick-GRC) serves the same weights with the baseline guardrails enforced on every request.

Only the model field changes. Same base URL, same API key.

Standard:

curl --location 'https://maas.phoeniqs.com/v1/chat/completions' \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "model": "inference-llama4-maverick",
    "messages": [{"role": "user", "content": "Draft a reply to this ticket..."}]
  }'

Guardrailed — only the model name changes:

curl --location 'https://maas.phoeniqs.com/v1/chat/completions' \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "model": "inference-llama4-maverick-GRC",
    "messages": [{"role": "user", "content": "Draft a reply to this ticket..."}]
  }'

The same applies in any OpenAI-compatible SDK (Python, Node.js): keep your base URL and API key, and switch the model string to the -GRC alias.

A customer support team uses Llama 4 Maverick to draft replies to end-user tickets. They route traffic to inference-llama4-maverick-GRC because every reply reaches a real customer: the gateway keeps the model from producing harmful content and masks sensitive data.

On the other side, the ML engineering team in the same organisation runs a prompt-engineering benchmark in a sandbox and calls inference-llama4-maverick directly. They need to see the model's raw behaviour — including the edge cases the guardrails would otherwise catch.

Same weights. Same API. Different policy postures, chosen per request.

• Latency: detection runs locally on the gateway, so keyword and regex checks add well under a millisecond per request.
• Pricing: both variants share the underlying model's pricing.
• Evolving policies: we'll be continuously working on updating this baseline feature and applying different guardrail policies, so you can evaluate which ones fit your use cases best and choose the right models.