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/guard 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.
GroupExamplesWhere it runs
GatewayTrustGate (recommended), Portkey, LiteLLM, Kong, Apigee, Azure APIMAt the AI gateway, in the request/response path.
ApplicationPython / Node SDK, REST API, middlewareInside your app, around model calls.
BrowserChrome, Edge, Firefox extensionsIn the browser, around AI web apps.
WAF / EdgeCloudflare Workers, AWS CloudFront (Lambda@Edge), Fastly Compute, Akamai EdgeWorkersAt the CDN edge.
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/guard for you and enforces the verdict natively. Other collectors call the same API directly and enforce the verdict themselves.

​
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. 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 routing and by anomaly_detector.
  • session_id — which conversation the message belongs to. Used by the multi‑turn detector; synthesised if omitted (treated as single‑turn).
  • 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.