Skip to main content
TrustGate is an AI gateway: a reverse proxy that sits between your applications and the model providers they call. Applications point their base URL at it instead of at OpenAI, Anthropic, Bedrock or Gemini, and it normalizes the request, selects a provider, balances traffic, meters spend, and records telemetry. It handles prompts and completions on LLM routes and tool traffic on the MCP (Model Context Protocol) Gateway. Use the native TrustGuard collector for content policy enforcement on traffic routed through TrustGate. If a gateway is not part of your data path, use an application collector or an edge collector instead.

​
Integration capabilities

TrustGuard is configured as a policy inside TrustGate. TrustGate controls routing, model and tool access, rate limits, and budgets. TrustGuard evaluates content. You can run TrustGate without a TrustGuard policy, but its routing and budget controls do not inspect payload content. The native collector supports input and output evaluation for LLM and MCP traffic. It can block or redact before non-streaming content is forwarded. Streamed responses are evaluated after delivery and therefore provide monitoring only.

​
Before you start

Create the policy in Observe mode. Observe records decisions in Activity without enforcing them. Review the results, then switch the policy to Enforce. See Policies.

​
1. Create the TrustGate collector

In TrustGuard, open Runtime → Collectors → Catalog → Gateway → TrustGate and bind the new collector to your gateway (Agent Gateway in the console). Use one collector per gateway. You can also create the gateway-bound collector from the TrustGate policy form in step 3, when it prompts you.

​
2. Assign a runtime policy

On the collector’s Policies tab, set a default policy, and per-consumer overrides if one consumer needs different rules.
A collector with no matching policy returns allow with no findings. Assign a default policy before enabling enforcement in production.

​
3. Turn on the TrustGuard guardrail

In TrustGate, open Policies → Catalog, where guardrails are listed first, and pick TrustGuard. Select the collector from step 1, then set the scope: global for the gateway, or attached to one consumer.
The TrustGuard base URL and credentials come from the gateway deployment, not from this policy form.

​
4. Choose Enforce or Observe

Enforce applies the verdict inline. Observe records it and lets the traffic through. See Verdict behavior for the full mapping. direction defaults to request_response, which evaluates both directions. Use request or response to limit evaluation to one leg. See Coverage for what each leg can enforce. You can run TrustGuard alongside another guardrail policy in the same chain. For example, use TrustGuard on the request and a Bedrock guardrail for PII anonymization on the response. See Guardrails.

​
5. Verify

  1. Send a test request through the guarded route, or generate one from Playground under a consumer.
  2. Confirm the event in TrustGuard Activity.
  3. Confirm the matching span on the TrustGate trace, and the Security flag in gateway telemetry. See Metrics.
Verify a blocked request as well as an allowed request. An unattached policy and a policy that never produces findings can otherwise look the same in Activity.

​
Reference

​
Coverage

Use this integration for LLM and MCP traffic routed through TrustGate. If you do not use a gateway, see the application or edge collectors. Ask. In Enforce mode, an ask verdict blocks because the gateway has no interactive approval flow. In Observe mode, it is recorded and traffic continues. Ask gates match input only. Streaming. TrustGate evaluates a streamed response in the post_response stage after the client has drained the stream. The resulting finding is recorded but cannot affect bytes already delivered. Put rules that require preventive enforcement on the request direction or use non-streaming completions. Limits. Redaction applies only to data-loss outcomes in Enforce mode. See Verdict behavior. Redaction does not apply to a tool listing: a poisoned tool description is blocked, not rewritten.

​
What is evaluated

Tool declarations are the names, descriptions, and parameter schemas in LLM tools[] or MCP tools/list. TrustGate can inspect them before an agent chooses a tool. Developer lifecycle hooks generally see tool calls and results rather than the declaration list. Each stage sends a POST /v1/evaluate request. The gateway sets direction, sends the payload, and applies the returned status. Application collectors set direction themselves and enforce the verdict in their own code. direction selects which detector phase of the policy runs, Input or Output. For MCP tools/call, tool.name is read from payload.params.name, not from attributes. Gate on that.

​
Verdict behavior

Statuses reduce most-restrictive-first: block > ask > transform > report > allow.

​
Configuration

Where connection settings live. Policy settings include collector_id, direction, and on_error. The TrustGuard base URL and credentials come from the gateway deployment’s TRUSTGUARD_* environment. On SaaS they are platform-managed and require no user configuration. Failure behavior. on_error applies to transport failures, timeouts, and ordinary service errors. Its default, fail_open, lets traffic continue; fail_closed returns a gateway error. TrustGuard responses for authentication (401/403), rate limits (429), and unavailable entitlements (503) always block. A missing TrustGuard base URL or gateway credential fails open. Policy routing. The collector’s default policy covers all of its traffic; a per-consumer override keyed on consumer_id wins where one matches. Resolution is override first, default second. Scope. The guardrail policy itself is attached globally to the gateway or to a single consumer, so a gateway can inspect some consumers and not others.

​
Attributes

Findings appear in TrustGuard Activity and on the TrustGate trace for the same request, as a span and a Security flag in gateway telemetry. Correlate them with Alerts, under Telemetry in the console. Per-consumer policy overrides key on consumer_id. Attribute conditions available to gates and detector rules include consumer.{name,tag,type}, model.{name,provider}, collector.type, source.application, and tool.{name,command,arguments}, with MCP tool.name taken from payload.params.name as above.

​
Troubleshooting