TrustGuard is runtime security for AI agents. It inspects prompts, responses, and tool activity, then returns a verdict for the collector to enforce.
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.
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.
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.
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.
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.
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.
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.
Do I need TrustGate?
No. Use another supported gateway, an SDK, middleware, an agent platform, or a
coding-agent plugin. See Integrations.
Can I evaluate a policy without blocking traffic?
Yes — that is Observe. It records findings and downgrades block, ask, and
transform to a recorded finding. Switch to Enforce once Activity looks right.
Can TrustGuard inspect tool calls?
Yes, when the collector sends tool events. Which actions the host can then apply
is in How it works.
What happens if TrustGuard is slow or unreachable?
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.