Overview

Learn how TrustGuard AI guardrails inspect LLM and agent traffic, apply security policies, and return verdicts for collectors to enforce.

TrustGuard is NeuralTrust’s runtime engine for AI guardrails. It inspects prompts, completions, documents, URLs, and tool calls, then returns a structured verdict. It is not a gateway: it does not route, load-balance, or talk to model providers. The collector that called it decides whether to allow, mask, prompt the user, or block.

TrustGate provides native inline enforcement for TrustGuard verdicts. TrustTest serves a separate purpose: it red-teams AI systems before and between releases. You can connect TrustGuard to another gateway, an SDK, or a coding-agent plugin.

What it stops

Three things TrustGuard is bought for, and where each is handled:

• An employee pastes a customer contract into a chat assistant. The prompt carries names, emails, and an account number. A DLP rule set to Transform masks them in flight, so the model receives [MASKED_EMAIL] instead of the real address.
• A user talks the assistant out of its instructions. The jailbreak attempt is scored by Content security, and a Block rule stops the turn before it reaches the model.
• An MCP tool returns text that instructs your agent. Nobody on your side wrote that instruction — it was planted in a page, a ticket, or a file the tool read. Agent & MCP security screens tool-sourced content for exactly this.

What TrustGuard inspects

Area	Catalog
Jailbreaks, toxicity, topic/keyword moderation, and the URL (url_analyzer) and document (doc_analyzer) analyzers	Content security
PII and secrets (optional in-flight masking)	Data loss prevention
Indirect prompt injection in tool-sourced content (MCP / role=tool)	Agent & MCP security

Detectors find risks. The policy determines what happens next: gates run first (matching attributes such as consumer, model, tool, and source), followed by detector rules (Monitor / Block / Transform).

Where traffic comes from

Create a collector under Agent Runtime → Collectors → Catalog.

The five groups and nineteen collector types below are exactly what the catalog offers, named as the console names them:

Catalog group	Collector types
Gateway	TrustGate (native; no tgk_… key), Portkey, LiteLLM, Kong, Apigee, Azure APIM
AI assistants & coding agents	Inference Hooks (Claude chat and Cowork, server-side), Claude Code, Cursor, Codex, GitHub Copilot
Application	Python, Node.js, REST API, Python Middleware, Node.js Middleware
Agent frameworks	n8n (@neuraltrust/n8n-nodes-trustguard), LangChain (langchain-neuraltrust)
Agent platforms	Copilot Studio

Most collectors call POST /v1/evaluate with a collector API key. TrustGate authenticates as the gateway. Inference Hooks uses POST /v1/evaluate/claude.

Some gateways still need a piece from you. Portkey and LiteLLM have a collector type, but TrustGuard is not yet a named guardrail in either product: Portkey needs a Bring Your Own Guardrails webhook adapter you host, and LiteLLM loads a custom guardrail class you place next to its config.yaml. Both work today; both are more setup than the other groups.

A collector with no matching policy is unguarded: TrustGuard returns status: "allow" and inspects nothing. Assign a default policy (and per-consumer overrides if you need them) before you rely on it.

AI guardrails for coding agents and agent platforms

Coding-agent plugins evaluate lifecycle events on developer machines. Agent platforms can provide organization-level inference hooks. These integration points expose different parts of a request and support different enforcement actions.

Collector	Path	source.application	Enforcement
Claude Enterprise	Anthropic organization, server-side (/v1/evaluate/claude)	claude-ai, claude-code, config-test	Allow or deny only. Ask is treated as Allow because this endpoint has no interactive confirmation.
Claude Code	Laptop plugin + binary + tgk_…	claude-code-plugin	Block on prompts; Block or Ask on tool calls
Cursor	Plugin + MDM cursor.json	cursor-plugin	Block on prompts; Block or Ask on tool calls
Codex	Plugin / managed hooks + codex.json	codex-plugin	Block to stop. Ask is extra context only (no dialog)
GitHub Copilot	Plugin / policy hooks + copilot.json	copilot-plugin	Block or Ask on tool calls; prompt events are audit-only

A gate on claude-code (Claude Enterprise, server-side) does not match the laptop plugin (claude-code-plugin). TrustGate MCP is an organization connector, not one of these plugins. Do not put a tgk_… key on the connector.

Full list: Integrations.

Building blocks

Concept	What it is
Detector	A named instance of a catalog detector plus its settings. Detection-only.
Policy	Gates + detector rules (Input / Output), and Observe / Enforce. Built under Agent Runtime → Policies.
Collector	The integration point that sends requests to a policy.
Gate	A rule on request metadata — consumer, model, tool, source — not on the text. Gates run before detectors and can settle a request without reaching them.
Finding	What a gate or detector reported (source, signal, outcome, evidence).

Requests do not name detectors. TrustGuard resolves the collector, selects the policy, runs gates, then applies detector rules that match direction. See Evaluation pipeline.

The verdict

Everything that fires reduces to a single status. The console and the API each have a name for it, so here they are side by side — most restrictive first, which is also the order TrustGuard applies when several fire at once:

Console	API status	Produced by	What the collector does
Block	block	a gate or a detector rule	Stops the interaction before the model, the tool, or the user sees it.
Ask	ask	a gate only, on input only	Asks the person to confirm. Needs a human at a keyboard, so most collectors cannot honour it.
Transform	transform	a detector rule — data_loss_prevention only	Rewrites the content and continues, masked. Returned as transformed_payload.
Monitor	report	a gate (labelled Report there) or a detector rule	Records the finding and continues.
Allow	allow	nothing fired, or everything was waived	Continues untouched.

Two things this table exists to settle:

• Monitor and report are the same thing. The console labels it Monitor on a detector rule and Report on a gate; the API value is report in both cases.
• There is no Ask rule. A detector rule can only be Monitor, Block, or Transform. ask comes from a gate, and only on input — on output a gate with Ask does not match.

Which of these a given collector can actually apply varies: TrustGuard coverage is the per-collector matrix. Read it before designing a policy around Transform or Ask.

A request and its verdict

The smallest useful call — an employee prompt on the way in:

{
  "payload": { "input": "My email is [e-mail], please draft a reply" },
  "direction": "input",
  "protocol": "llm",
  "consumer_id": "[e-mail]"
}

With a DLP detector on a Transform rule, TrustGuard answers:

{
  "status": "transform",
  "transformed_payload": { "input": "My email is [MASKED_EMAIL], please draft a reply" },
  "findings": [
    {
      "source": { "kind": "detector", "plugin": "data_loss_prevention", "detector_name": "PII masking" },
      "signal": { "type": "pii", "confidence": 1.0 },
      "outcome": { "action": "transform" },
      "evidence": { "masked": 1, "entities": ["email"] }
    }
  ]
}

The collector forwards transformed_payload instead of the original. Every field, plus the base URL, limits, and status codes: Evaluate API.

Observe vs Enforce

Every policy runs in one of two modes, switched on its Basics tab. In Observe everything is recorded and nothing is applied: blocks, asks, and transforms are all downgraded, so the status never goes past report. In Enforce, actions apply as configured. Run a new policy in Observe until the signal looks right, then switch it.

The collector acts on status. TrustGate enforces the verdict on the route; coding-agent behavior varies by event and host, as TrustGuard coverage sets out. A successful evaluation returns HTTP 200 even when status is block. A non-2xx response means something else entirely: authentication failed, the body was rejected, the plan quota was exceeded, or a detector errored while the deployment was set to fail-closed.

Get started

You need a workspace with TrustGuard enabled. It is entitlement-gated, so if your team does not have it, Agent Runtime does not appear in the console sidebar at all. TrustGuard runs as SaaS and self-hosted; the console shows the base URL for your deployment.

The console walks you through setup in three steps under Agent Runtime → Getting started, and that is the fastest path — it creates the detectors and a first policy for you, tests them, and connects the collector last.

1. Build a policy. Pick the detectors you want and add Input / Output rules — or gates alone, if you are matching on metadata only. Leave the policy in Observe.
2. Test it. Run a sample on the policy Test tab. It evaluates the saved policy, so save before you test.
3. Connect a collector. Create one under Agent Runtime → Collectors → Catalog, then attach the policy: the Policies tab on the collector, or Collectors on the policy. Until a policy is attached, that collector inspects nothing and every request comes back allow.

Then watch Agent Runtime → Activity for real traffic, and switch the policy to Enforce once the findings look right.

To build the same setup by hand, create the detectors and policy under Agent Runtime → Detectors and → Policies, then attach a collector as in step 3.

TrustGuard FAQ

Is TrustGuard an AI gateway?

No. TrustGuard’s AI guardrails evaluate traffic and return verdicts. The calling collector applies the verdict; when that collector is a gateway, it also routes the traffic. TrustGate includes a native TrustGuard integration.

What happens if a collector has no matching policy?

TrustGuard returns status: "allow" without running detectors. Assign a default policy before relying on the collector, then add per-consumer overrides if needed.

Can TrustGuard inspect tool calls?

Yes, when the collector sends tool events. Available enforcement actions depend on the collector and host, as shown in TrustGuard coverage.

Can I evaluate a policy without blocking traffic?

Yes. Start the policy in Observe to record findings without blocking or transforming traffic. Move to Enforce after you validate the results in Activity.

Do I need TrustGate to use TrustGuard?

No. You can connect TrustGuard through another supported gateway, an SDK, middleware, or a coding-agent plugin.

How does TrustGuard choose what to evaluate?

TrustGuard resolves the collector and its assigned policy. It runs matching gates first, then detector rules for the request’s Input or Output direction.

Where to go next

How it works

Compare policy actions and enforcement support across collectors.

Policies

Tabs, Observe / Enforce, gates (including Ask), Test.

Coding agents

Claude Code, Cursor, Codex, and GitHub Copilot.

Detector catalog

Built-in detections and settings.

Evaluate API

POST /v1/evaluate, base URL, limits, and status codes.

Data handling

What TrustGuard stores, what it redacts, and for how long.

Telemetry Alerts

Turn findings into alerts.