Skip to main content
The TrustGuard policy sends what passes through the gateway to TrustGuard and applies the verdict it returns: allow, report, block, or a masked rewrite of the content itself. It covers LLM and MCP — the Model Context Protocol your agents call tools over — and it sends the whole conversation: the system prompt, every message with its role, the tool calls the assistant proposed, the tool definitions the client declared, and file and image attachments. What it detects is not configured here. The gateway policy decides which traffic is inspected and whether the gateway acts; the TrustGuard policy bound to the collector decides which detectors run and what a finding costs.
This policy puts a synchronous call in front of every inspected leg. With Direction set to both legs, a non-streaming turn makes two calls. How much that costs depends on your deployment and the size of the conversation, so measure it in your own environment rather than assuming. Enable the request leg first, measure, and only then add the response leg.

​
Before you configure: the runtime collector

A runtime collector bound to this gateway is a hard prerequisite, not a convenience. It is what authenticates the gateway to TrustGuard and what selects the TrustGuard policy that will judge the traffic.
The policy does not create the collector for you. Saving a TrustGuard policy with no collector bound fails. Create one first — under Agent Runtime → Collectors, or inline from the policy form, which offers Create collector when the selected instance has none on this gateway.
The collector type is the TrustGate one, and it is native: there is no customer API key to paste, because the gateway authenticates through the platform. See Collectors for what a collector owns.

​
Configure the policy

Open Policies → Library → TrustGuard.

​
Runtime collector

Two cascading selects, and this pair is the whole binding: If the list is empty you get No collectors for this instance on this gateway and a Create collector link that makes one without leaving the panel.

​
Direction

Direction is the only control over what is inspected, and it defaults to Request & Response.

​
Mode and scope

Start in Observe, which records every verdict without acting on it, and switch to Enforce once the decisions look right. Read Modes and failures first: Observe here is narrower than it sounds. Scope works as it does for every policy — Requests from for applications and groups, Resources for MCP servers and tools. See Policies overview.

​
What is sent on each leg

Binary content is not inspected: an image or audio block, or a resource that carries a base64 blob rather than text, contributes nothing and is not decoded.

​
How the decision is made

1

The leg is sent to TrustGuard

Only the legs Direction selects are sent. A leg with nothing inspectable in it — an empty body, a tool result with no text anywhere — is skipped, and the event records why, so “not inspected” and “inspected, found nothing” stay distinguishable.
2

A block verdict refuses the request

The caller gets 403, and the response says the request was blocked by security policy. Where the finding has a detector or gate behind it, that name is in the message too, and the refusal carries identifiers you can use to find the request in Activity.The findings themselves are not in the response — no matched text, no confidence scores. Those are on the event and in Activity.A TrustGuard Ask action counts as a block here. Nothing on the gateway’s path can stop and put a confirmation in front of a person, so a verdict the gateway cannot ask about is refused rather than allowed.
3

A transform verdict rewrites the content in place

TrustGuard returns the masked payload and the gateway substitutes it, then lets the call continue. On the request leg the model or MCP server receives the masked version and never sees the original. On the response leg the caller does.
4

Otherwise the call continues untouched

A transform the gateway cannot apply becomes a block. If TrustGuard asks for a rewrite but returns no usable payload, or the body cannot be re-encoded, the request is refused rather than forwarded unmasked. That is deliberate — the alternative is sending the content the detector just flagged.
There are two Observe switches, and both have to be off for anything to be blocked. This policy’s mode decides whether the gateway acts on a verdict. The TrustGuard policy bound to the collector has its own mode, and in Observe it records detector actions without ever asking for a block or a transform. A gateway policy in Enforce against a TrustGuard policy in Observe blocks nothing, and nothing in this screen says so.

​
Modes and failures

Observe does not mean “never refuses”. Four paths refuse the request in Observe exactly as they do in Enforce, because they never reach the point where the mode is read:
  • a TrustGuard rate limit — 429, with the retry-after and rate-limit headers TrustGuard returned forwarded to the caller;
  • entitlements unavailable — 503;
  • a rejected credential, or a 401 that survives a token refresh — 502;
  • a configuration the gateway cannot parse — 502.
This is deliberate and pinned by tests. A gateway that cannot prove it is allowed to call the detector does not get to guess, in either mode. Plan for it before you put an Observe policy in front of production traffic.
On a transport failure or a 5xx from TrustGuard, traffic is forwarded uninspected. The event records the failure; the caller sees nothing. The console offers no setting to change this, in either mode. Alert on the failure count rather than assuming silence means clean traffic.

​
Limits

  • Streaming responses are inspected only after the response was already delivered. They are buffered and sent to TrustGuard once the client has drained the stream, off the caller’s path. Everything is recorded; nothing can be refused. A response guardrail on a streaming application observes; it does not protect. Enforce on the request leg.
  • A streamed response larger than 8 MiB is not inspected at all. The buffer is abandoned, a warning is logged, and — unlike every other skip — no event is emitted. There is nothing in Activity to count.
  • Direction is the only control over what is inspected. The policy is always active at every point in a request’s journey, and nothing stored on it changes that, so there is no second setting anywhere that narrows it. Direction is what decides whether a leg is actually sent to TrustGuard.
  • The request leg cannot be turned off for MCP separately from LLM. One policy covers both protocols within its scope.
  • Binary payloads are not inspected — image and audio content blocks, and embedded resources carrying a blob rather than text.

​
Verify the policy

Open the Playground, pick an application the policy applies to, and send these prompts in this order. Starting with the control means a failure tells you something specific. Before you start, confirm the TrustGuard policy bound to the collector is in Enforce and has the detector you are about to exercise enabled on Input. Otherwise step 3 proves nothing.
1

Control — the path works at all

Expect a normal reply and the decision allowed. If this fails, the problem is the application, the model or the collector binding — not the detector. Fix it before going on.
2

Sensitive data — masking works

Send a prompt containing something your TrustGuard policy masks, for example an email address.With a transform action, expect the decision transformed.Read the reply, not just the status. What the model answered must not contain the original value. That is what proves the model never received it.
3

Prompt injection — blocking works

Expect the decision block, a 403, and no time at the provider in the timing breakdown. That the provider leg is empty is the evidence that matters: the request never reached the model.
4

MCP — the other protocol is covered too

The Playground cannot make this check — it sends prompts, not tool calls. So this one comes from a client already connected to an MCP server in this policy’s scope, whatever your agents use: have it call a tool with an argument that should trip the same detector.Expect a finding against the tool call, not only against chat traffic. This is the check most people skip, and it is the one that distinguishes this policy from every other guardrail.
Every verdict is emitted as a metadata event, in Observe mode too. See the event schema for the fields recorded.

​
Troubleshooting