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 Security → Collectors**. The page has two tabs: | Tab | What it is | | - | - | | **Collectors** | Configured integration points and their policy counts. | | **Catalog** | Collector types grouped by integration type. **Add collector** opens the create flow. | Opening a collector is a side panel with: | Tab | What it is | | - | - | | **Connection** | Setup instructions for that provider, with every value you need to paste elsewhere. | | **Auth** | This collector's API keys. Each is shown **once**, at creation. TrustGate has no Auth tab. | | **Policies** | The default policy, and per-consumer overrides. | Each collector owns: 1. **Authentication:** [TrustGate](/integrations/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](/trustguard/concepts/policies) evaluates its traffic (a default policy, and optionally per‑consumer overrides). ## Catalog groups The catalog offers **twenty-two 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. | Catalog group | Where it runs | What it can see | Types | | - | - | - | :-: | | **Gateway** | The AI gateway path | Every LLM and MCP request the gateway proxies | 6 | | **Agent platforms** | A platform you do not operate, which calls TrustGuard itself | What the platform sends, before the agent acts | 2 | | **Coding agents** | Developer machines | Prompts and agent actions, including shell commands, patches, and MCP calls | 7 | | **Application** | Your own code, around model calls or on the request path | Whatever you pass it | 5 | | **Agent frameworks** | Inside your agent loop or workflow | Prompts, responses, and tool calls in the graph — a tool call can be stopped before it runs | 2 | **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, Gemini CLI, Google Antigravity, Windsurf, and GitHub Copilot, which run on developer machines. Every type is listed, group by group, on the [TrustGuard overview](/trustguard/overview#where-traffic-comes-from). Browse [Integrations](/integrations/overview) for setup instructions, and [How it works](/trustguard/how-it-works) to compare what each one can enforce. **Two gateways still need a piece you build.** [Portkey](/integrations/portkey) and [LiteLLM](/integrations/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. **Model providers and collectors are separate.** The [provider catalog](/trustgate/endpoints/models) 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](/trustguard/concepts/policies) 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.