Collectors

How TrustGuard collectors receive traffic, authenticate requests, select policies, and attribute activity

A collector represents an integration point, such as an AI gateway, application SDK, or coding-agent plugin. Most collectors call POST /v1/evaluate. Claude Enterprise uses the specialized endpoint described in its integration guide.

You create and manage collectors under Agent Runtime → 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	Provider instructions and snippet. Claude Enterprise also has Inference Hook URL + whsec_.
Auth	Collector API keys (tgk_…). Shown once at creation. TrustGate collectors skip this.
Policies	Default policy and per‑consumer overrides.

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. 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
AI assistants & coding agents	The Anthropic organization server-side, or developer machines	Prompts and agent actions, including shell commands, patches, and MCP calls	5
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	A low-code agent platform you do not operate	What the platform’s connector sends	1

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.

Claude Enterprise uses /v1/evaluate/claude. The Claude Code, Cursor, Codex, and GitHub Copilot plugins use /v1/evaluate with a tgk_… key.

TrustGate is native. Bind a TrustGate collector to the gateway, assign a runtime policy, and enable the TrustGuard guardrail on routes. The gateway does not need a collector API key; it sets direction and enforces the verdict. Other collectors call /v1/evaluate with a key, send direction, and apply the verdict. See the Python SDK or REST for examples.

Authentication & API keys

Except for TrustGate, a collector authenticates with a bearer API key, created on the collector in the console (TrustGate collectors have no Auth key step).

• 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.

POST /v1/evaluate
Authorization: Bearer <collector-api-key>   # ← resolves the collector
Content-Type: application/json

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. Synthesized if omitted.
• attributes: optional context (consumer.name, consumer.tag, consumer.type, model.name, model.provider, collector.type, source.application) that gates and detector rules can match on. MCP tool.name is taken from payload.params.name, not from attributes.

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.