Skip to main content

A collector is the integration point — a gateway, an SDK, a coding-agent plugin, an agent platform — that sends traffic to TrustGuard and applies the verdict. It is the only piece you install, and nothing is inspected until one exists.

You create and manage collectors under Agent Runtime → Collectors. The page has two tabs: Opening a collector is a side panel with: Each collector owns:
  1. Authentication: TrustGate is native (no customer API key; the gateway authenticates via the platform). Other integrations use one or more API keys that resolve the collector at runtime.
  2. Policy routing: which policy evaluates its traffic (a default policy, and optionally per‑consumer overrides).

​
Catalog groups

The catalog offers nineteen collector types in five groups, in this order. The group decides where the collector runs, what it can see, and which setup snippet you get. Agent platforms covers Microsoft Copilot Studio and Anthropic Inference Hooks: in both, the vendor runs the agent and calls TrustGuard for a verdict, so there is nothing of yours on the request path. Coding agents covers Claude Code, Cursor, Codex, and GitHub Copilot, which run on developer machines. Every type is listed, group by group, on the TrustGuard overview. Browse Integrations for setup instructions, and How it works to compare what each one can enforce. Two gateways still need a piece you build. Portkey and LiteLLM each have a collector type, but TrustGuard is not yet a named guardrail inside either product — Portkey calls a Bring Your Own Guardrails webhook adapter you host, and LiteLLM loads a custom guardrail class you place beside its config.yaml. Both work today; both are more setup than the other groups. Employee use of AI services you do not operate is covered by the browser extension, which is configured through managed browser policy rather than as a collector. Model providers and collectors are separate. The provider catalog configures which upstream models TrustGate calls. A collector defines where TrustGuard evaluates traffic. Adding a provider does not create a collector or change the enforcement path. TrustGate is the shortest path. Bind a TrustGate collector to the gateway, assign it a policy, and turn on the TrustGuard guardrail for the routes you want covered. Nothing is deployed, no key is created, and no application code changes — the gateway already sits in front of the model, so it both sends the traffic and applies the verdict. Every other collector needs a key and needs whatever is calling it to say which direction the traffic is going.

​
Authentication

Every collector except TrustGate needs a key, created on its Auth tab. TrustGate is native to the platform and has no Auth tab at all.
  • The key is shown once, when you create it. Copy it then — afterwards the console only shows a prefix hint, and there is no way to reveal it again.
  • Keys can be given an expiry, and can be revoked.
  • The key is the collector’s identity. Whatever presents it is treated as that collector, which is why a key shared between two integrations makes their traffic indistinguishable in Activity.

​
Routing traffic to a policy

A collector decides which policy evaluates a request:
  • Default policy — the fallback for all of that collector’s traffic.
  • Per-consumer policy — an override for one consumer, so a single collector can send different people or services to different policies.
The more specific one wins: if the caller matches a per-consumer override, that policy runs; otherwise the default does. A collector with neither leaves its traffic unguarded — allowed, and inspected by nothing.
Unguarded traffic is not inspected. Set a default policy (and per-consumer overrides if needed) before relying on TrustGuard in production.
You attach a collector to a policy from the policy’s Collectors tab (routing mode Default or Consumer ID).

​
Who did what

A finding is only useful if you can tell who caused it. Each integration passes along, where its platform can supply it:
  • Who made the request — a user ID, an email, a device. This is also what per-consumer policy routing keys on, so without it every caller gets the default policy.
  • Which conversation it belongs to — TrustGuard makes one up if the integration cannot supply it, which is enough for grouping but not for tying a session back to a real person.
  • Context worth gating on — consumer name, tag and type, the model and its provider, the source application. These are the same attributes your gates and detector rules match on.
This is what fills in the consumer and session columns in Activity, and what the session-aware detectors need to work at all. Each integration page shows where these values naturally come from on that platform — some hand them over for free, others need you to pass them.