Skip to main content
A collector is where TrustGuard receives traffic. It represents one integration point — an AI gateway, an application SDK, a browser extension, or an edge/WAF worker — that calls POST /v1/evaluate on every request it wants inspected. You create and manage collectors in the console’s Collectors screen. Each collector owns:
  1. One or more API keys — the credentials its integration uses to authenticate. The key resolves the collector at runtime.
  2. A policy routing — which policy evaluates its traffic (a default policy, and optionally per‑consumer overrides).

​
Integration types

Collectors are created from a catalog grouped by integration type. The integration determines the setup snippet you get and where enforcement happens. When you create or open a collector, the side panel shows step‑by‑step instructions and a ready‑to‑paste snippet for the chosen integration. See Integrations for all of them.
TrustGate is the first‑class collector. When TrustGuard runs behind the gateway, the gateway calls /v1/evaluate for you, sets direction (input / output) from the request and response path, and enforces the verdict natively. Other collectors call the same API directly, must send direction themselves, and enforce the verdict themselves — see Application integrations.

​
Authentication & API keys

A collector authenticates with a bearer API key, created on the collector in the console.
  • The raw secret is shown once, at creation — store it immediately. Afterwards only a non‑secret prefix hint is shown.
  • Keys support an optional expiry and can be revoked.
  • The key carries the collector identity — the runtime resolves the collector from the key, so the request body never needs a collector id.

​
Routing traffic to a policy

A collector decides which policy evaluates a request:
  • Default policy — the fallback used for all of the collector’s traffic.
  • Per‑consumer policy — an override keyed on consumer_id, so one collector can send different consumers to different policies.
Resolution is: if the request’s consumer_id has a per‑consumer policy, use it; otherwise use the default policy. A collector with no matching policy leaves that request unguarded — it returns allow with no findings.
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).

​
Attribution

Each integration should send, when available:
  • consumer_id — who made the request (user id, email, or device fingerprint). Used for per‑consumer policy routing.
  • session_id — which conversation the message belongs to. Synthesised if omitted.
  • attributes — optional context (consumer.name, consumer.tag, consumer.type, model.name, model.provider, collector.type) that gates and detector rules can match on.
These attribute findings to the right user and session in the Activity view and power the stateful detectors. Every integration snippet shows the natural source for each on that platform.