> ## Documentation Index
> Fetch the complete documentation index at: https://neuraltrust-92b43583-develop.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Collectors

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

A **collector** represents an integration point, such as an
[AI gateway](/trustgate/overview), application SDK, or coding-agent plugin.
Most collectors call
[`POST /v1/evaluate`](/trustguard/api/evaluate). Claude Enterprise uses the
specialized endpoint described in its
[integration guide](/integrations/claude-enterprise).

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](/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 **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](/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.

<Note>
  **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.
</Note>

Employee use of AI services you do **not** operate is covered by the
[browser extension](/platform/browser-extension), which is configured through
managed browser policy rather than as a collector.

<Note>
  **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.
</Note>

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

<Note>
  **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](/integrations/python-sdk) or
  [REST](/integrations/rest) for examples.
</Note>

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

```bash theme={null}
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](/trustguard/concepts/policies) 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.

<Warning>
  Unguarded traffic is not inspected. Set a default policy (and per-consumer overrides if needed) before relying on TrustGuard in production.
</Warning>

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.