Skip to main content

Prompts, completions, documents, URLs, tool calls — each one gets the same question asked of it: should this be allowed? TrustGuard answers. It never acts on its own answer; whatever sent the traffic is what applies it.

TrustGuard is not a gateway. It does not route requests or call model providers, so putting it in front of an agent never changes where your prompts go. Something else asks TrustGuard for a verdict and then acts on the answer: a gateway, a coding-agent hook, an agent platform, or your own code. That something is called a collector, and it is the only part you install.

What it stops

Data loss

PII and secrets leaving in a prompt, a completion, or a tool argument.

Jailbreaks and abuse

Prompt injection, toxicity, off-topic use, hostile URLs, and documents.

Tool-borne attacks

Instructions smuggled into what a tool hands back — MCP results, API responses, fetched pages.
Detectors find risk. They never act on it. What happens next is the policy’s decision, which is why the same detector can be a silent monitor in one policy and a hard block in another.

How it works

1

A collector sends the event

Your gateway, hook, or SDK hands TrustGuard the traffic and says which way it is going — to the model, or coming back. That choice decides which half of the policy runs.
2

TrustGuard picks one policy

The collector’s default policy — unless you set an override for the consumer making the call, in which case that one wins. A collector with no matching policy inspects nothing at all.
3

Gates decide what runs

Gates match on request attributes and can skip evaluation entirely — useful for traffic you have deliberately waived. Whatever survives the gates runs the detectors attached to that direction.
4

The strictest result wins

Each detector returns its own outcome. TrustGuard reduces them to one status, worst-first: block, ask, transform, report, allow.
5

The collector enforces the verdict

TrustGuard only answers. What a host can actually do with that answer varies — a gateway can drop the request, a coding-agent hook can refuse a tool call, an SDK can do whatever you code. See How verdicts are enforced.
Flow diagram showing a collector sending input or output to TrustGuard, which selects a policy, evaluates gates and detector rules, and returns a verdict for the collector to apply.
A collector with no matching policy is unguarded. TrustGuard returns allows everything and inspects nothing — it does not fail loudly, and nothing in the console flags it. Attach a default policy before you rely on it.

Where traffic comes from

The catalog under Agent Runtime → Collectors → Catalog offers nineteen collector types in five groups. The group tells you where the collector runs and, as a result, how much it can see. Collectors explains authentication and policy routing; Integrations has the setup steps for each type.
Employee use of AI services you do not operate is not a collector. That is the browser extension, deployed through managed browser policy.

Building blocks

Detectors

A catalog detector plus its settings. Detection only — they do not enforce.

Policies

Gates, Input / Output rules, and Observe vs Enforce.

Collectors

The integration point that sends traffic to a policy.

Data handling

What an evaluation stores, where it lives, and for how long.

Get started

TrustGuard is entitlement-gated: if your team is not entitled, Agent Runtime does not appear in the console at all.

Quickstart

Protect a TrustGate gateway end to end — two detectors, one policy, one collector, and the switch from watching to blocking. Nothing is enforced until the last step.

FAQ

No. It evaluates traffic and returns a verdict; the collector applies it. When that collector happens to be TrustGate, the gateway also routes the call — but that is TrustGate’s job, not TrustGuard’s.
No. Use another supported gateway, an SDK, middleware, an agent platform, or a coding-agent plugin. See Integrations.
Yes — that is Observe. It records findings and downgrades block, ask, and transform to a recorded finding. Switch to Enforce once Activity looks right.
Yes, when the collector sends tool events. Which actions the host can then apply is in How it works.
That is the collector’s decision, not TrustGuard’s, and every integration exposes it differently — Copilot Studio, for example, asks you to choose up front what happens when no verdict arrives in time. Check the page for your integration before you rely on it.