Cato Networks

Use Cato AI Security with TrueFoundry AI Gateway to inspect prompts before they reach the model and model responses before they reach the caller. Cato can pass the payload through, block it, or replace messages with an anonymized copy.

How the integration works

On each non-streaming chat request, the gateway calls POST {base_url}/fw/v1/analyze at the hooks you attach the guardrail to:

Input, on the request the caller sent. In Mutate the result is applied before the model is called.
Output, on the model’s response, before it is returned to the caller

The body is an OpenAI chat payload: model when it is known, the full messages array (including the system prompt), and tools when the caller declared any. On the output hook the model’s reply is appended to the conversation. Cato answers with required_action.action_type:

Cato action	Mutate	Validate
Absent, `monitor_action`, or any unrecognized value	Pass the payload through unchanged	Same
`block_action`	Violation	Violation
`anonymize_action`	Replace the messages with `redacted_chat.all_redacted_messages` and continue	Violation. The payload is not changed.

A violation is handled by the enforcing strategy. When the request is rejected, the caller receives a 400 with type guardrail_checks_failed.

MCP tool calls

The guardrail can also be attached to MCP tool hooks. Tool arguments are sent to Cato as user messages, one per argument, and the tool result is sent as a single assistant message. In Mutate, anonymized arguments and results are written back to the tool call.

The guardrail runs on the input and output of chat requests and on MCP tool calls. Output inspection is skipped for streamed responses.

Prerequisites

An API key issued by Cato for the AI Security guard
The Cato API base URL for your region, or the URL of a Cato Outpost in your environment
Network access from the gateway to that URL

Add the Cato Networks guardrail

Select Cato Networks

In TrueFoundry, go to AI Gateway → Guardrails, create or open a guardrail group, and select Cato Networks under External Providers.

Configure the guardrail

Name: A name such as cato.
API Key: The key from the Cato guard. TrueFoundry stores it as a secret and sends it as Authorization: Bearer.
Base URL: The Cato endpoint, for example https://api.aisec.catonetworks.com, or your Outpost URL. Trailing slashes are ignored. This field is required.
Operation:
- Mutate (default) follows Cato’s contract. On anonymize_action the messages are replaced with Cato’s redacted versions and the request continues. Mutate guardrails run one after another, before the model is called.
- Validate never changes the payload. A block_action or an anonymize_action counts as a violation. Validate guardrails run in parallel with the model request.
Enforcing Strategy: See Enforcing strategy.
Priority: Order among other mutate guardrails. Lower values run first. Applies to Mutate only.

Attach the guardrail

Save the guardrail group, then attach it to the LLM input hook, the LLM output hook, or both through a guardrail policy.

Enforcing strategy

Strategy	Violation (block or, in Validate, anonymize)	Cato unreachable or returns an error
Enforce	Request is rejected	Request is rejected
Enforce But Ignore On Error	Request is rejected	Request continues
Audit (Validate only)	Recorded, request continues	Request continues

Validate guardrails run in parallel with the model request. When a Validate guardrail rejects a request, the prompt has already been sent to the model. To make the guardrail finish before the model is called, turn off Run Guardrails in Parallel with Model Request in the gateway guardrail settings, or use Mutate.

Verify the integration

Select the guardrail on a request with the X-TFY-GUARDRAILS header. The selector format is <group>/<guardrail-name>.

curl -X POST "https://<your-gateway-url>/chat/completions" \
  -H "Authorization: Bearer ${TFY_API_KEY}" \
  -H "Content-Type: application/json" \
  -H 'X-TFY-GUARDRAILS: {"llm_input_guardrails":["my-group/cato"],"llm_output_guardrails":["my-group/cato"]}' \
  -d '{
    "model": "my-account/my-model",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "Hi, my SSN is 123-45-6789"}
    ]
  }'

What comes back depends on the policy configured in Cato for your guard. Cato returns nothing. The response is a normal completion. Each check reports decision: allow.

{
  "guardrail_checks": {
    "input_guardrails": [
      {
        "guardrail_integration": "my-group/cato",
        "result": "passed",
        "data": { "decision": "allow", "action_type": null },
        "transformed": false
      }
    ]
  }
}

Cato anonymizes, guardrail is Mutate. The model sees the masked text, and the check reports transformed: true.

{
  "guardrail_integration": "my-group/cato",
  "result": "passed",
  "data": { "decision": "anonymize" },
  "transformed": true
}

Cato blocks. The request is rejected with 400. The message names the detection categories Cato reported, such as SSN, and never the text that matched. Cato’s detection_message is not returned, because it quotes the matched text. The analysis_result on the check keeps only each policy’s name and the category and certainty of each detection. The matched values, their positions and the entity lists are removed. If Cato reports no category, the message is Content blocked by Cato Networks.

{
  "status": "failure",
  "message": "Input Guardrail checks failed for integrations: [my-group/cato] - Details: Cato Networks policy violation (one)",
  "error": { "type": "guardrail_checks_failed", "code": "400" },
  "error_origin_level": "guardrails_input",
  "guardrail_checks": {
    "input_guardrails": [
      {
        "guardrail_integration": "my-group/cato",
        "result": "failed",
        "data": {
          "decision": "block",
          "message": "Cato Networks policy violation (one)",
          "analysis_result": {
            "policy_drill_down": {
              "<policy-id>": {
                "policy_name": "testone - testone",
                "detections": [{ "type": "one", "certainty": "HIGH" }]
              }
            }
          }
        },
        "transformed": false
      }
    ]
  }
}

In Validate, an anonymize_action produces the same kind of failed check with decision: anonymize, and the same category-only message and redacted analysis_result.

Per-application policy

Every analyze call sends x-cato-gateway-key-alias. Cato uses that alias, not the key secret, to select a policy. TrueFoundry takes the alias from the authenticated caller, never from the request:

The personal access token name, when the request is authenticated with one
Otherwise the virtual account, user, or agent name

A caller cannot choose their own alias, so one application cannot have its traffic evaluated under another application’s policy. If no alias can be determined, the request is rejected. Other request headers whose names start with x-cato- are forwarded to Cato unchanged, as Cato requires. The exceptions are headers that identify the caller or select a policy, which only the gateway sets: x-cato-gateway-key-alias, x-cato-gateway-key-name, x-cato-user-email, and x-cato-call-id. If a caller sends one of these, it is dropped. Name the guard in Cato after the alias you expect, so each application can have its own policy.

Get Started

LLM Gateway

MCP Registry and Gateway

Skills Registry

Prompt Registry

Guardrails and Security

Observability

Deployment

Admin Guide

Chat

Messages

Embeddings

Rerank

Responses

Image

Audio

Batch

Files

Fine-tuning

Moderations

Video

Models

How the integration works

MCP tool calls

Prerequisites

Add the Cato Networks guardrail

Enforcing strategy

Verify the integration

Per-application policy

​How the integration works

​MCP tool calls

​Prerequisites

​Add the Cato Networks guardrail

​Enforcing strategy

​Verify the integration

​Per-application policy

How the integration works

MCP tool calls

Prerequisites

Add the Cato Networks guardrail

Enforcing strategy

Verify the integration

Per-application policy