> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neuraltrust.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> TrustGuard is NeuralTrust's runtime security service: it evaluates AI traffic against the collector's policy and reports findings — without ever dropping traffic.

**TrustGuard** is NeuralTrust's runtime security engine for generative-AI and agentic
traffic. It inspects prompts, model output, documents, URLs, and agent/tool activity
in flight and returns a structured security verdict for each request.

TrustGuard is deliberately **decision-only**: it tells you *what* it found and *what*
it would do, but it never blocks or drops traffic itself. The component that calls
TrustGuard (the [collector](/trustguard/concepts/collectors)) decides whether to
allow, mask, or block based on the verdict. This keeps TrustGuard safe to deploy
inline anywhere — a failure or timeout can never take your application down.

> TrustGuard is one of four NeuralTrust products. It pairs naturally with
> **[TrustGate](/trustgate/overview)** (the AI gateway, the most common
> collector), **TrustLens** (AI security posture), and **TrustTest** (red teaming).

## What it does

<CardGroup cols={2}>
  <Card title="Prompt & content security" icon="shield-check">
    Jailbreak and prompt-injection detection, topic moderation, toxicity scoring,
    and document/URL analysis on both input and output.
  </Card>

  <Card title="Data loss prevention" icon="eye-off">
    Detect and mask 43 PII entities and secrets (API keys, tokens, JWTs) in flight,
    returning a transformed payload.
  </Card>

  <Card title="URL & document analysis" icon="file-search">
    Fetch and screen URLs, and extract text from uploaded documents (including OCR)
    for jailbreaks and PII before they reach the model.
  </Card>

  <Card title="Secrets in flight" icon="key">
    Catch leaked credentials and sensitive tokens in prompts and model outputs
    alongside PII masking.
  </Card>
</CardGroup>

## The model in one minute

TrustGuard has four building blocks. You compose them once, then send traffic.

| Concept                                          | What it is                                                                                                                                                                                                                                                                   |
| ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **[Detector](/trustguard/concepts/detectors)**   | A reusable, named detection you create from the [catalog](/trustguard/detectors/overview) — a catalog detector (e.g. `prompt_guard`, `data_loss_prevention`) plus its `settings` (thresholds, entity lists, …). Detection‑only — it decides *what* it finds, not what to do. |
| **[Policy](/trustguard/concepts/policies)**      | Where enforcement lives: **gates** (match request attributes before detection) + **detector rules** (run detectors with a Monitor / Block / Transform action), plus a **Report / Enforce** switch.                                                                           |
| **[Collector](/trustguard/concepts/collectors)** | A traffic tap (gateway, SDK, browser, WAF) authenticated by an API key. It routes each request to a policy.                                                                                                                                                                  |
| **Finding**                                      | What a gate or detector reported — its `source`, `signal`, `outcome`, and `evidence`.                                                                                                                                                                                        |

```text theme={null}
        POST /v1/evaluate  (Authorization: Bearer <collector api key>)
                              │
 ┌──────────┐  resolves  ┌────▼─────┐  routes to  ┌──────────────────────────────┐
 │ API key  │───────────▶│Collector │────────────▶│ Policy                       │
 └──────────┘  collector └──────────┘   a policy   │  gates → detector rules      │
                                                    └──────────────┬───────────────┘
                                                                   ▼
                    { status, findings[], transformed_payload, trace_id }
```

A request names **no detectors**: TrustGuard resolves the collector's policy and
runs its gates and the detector rules that match the request's direction and
conditions. See [How it works](/trustguard/how-it-works).

## What makes it safe to run inline

<Warning>
  Traffic with **no matching policy** is **unguarded**: TrustGuard returns `status: "allow"` with no inspection. Attach a default (or per-consumer) policy on the collector after setup.
</Warning>

* **Never drops traffic.** A detection is always `HTTP 200` with the finding in the
  response body. Non-2xx is reserved for auth (401), bad requests (400), and system
  failures (500).
* **Fail-open or fail-closed — your choice.** If a detector errors (e.g. an upstream
  model API is down), TrustGuard either drops that detector's result and continues
  (fail-open) or returns `500` so you can hold traffic (fail-closed). The mode is **configured per deployment** (ask NeuralTrust if unsure). A structured block decision always applies.
* **Enforcement is the caller's choice.** The response `status`
  (`allow` / `report` / `transform` / `block`) is advisory. Your collector
  decides what to do with it.

## Get started

1. Create a collector ([TrustGate](/trustgate/overview), [SDK/REST](/trustguard/integrations/application), or another collector).
2. Create detectors from the [catalog](/trustguard/detectors/overview).
3. Create a [policy](/trustguard/concepts/policies) with **Input** and **Output** detectors chained and configure rules if needed.
4. Attach the policy to the collector created (default and/or per-consumer).
5. Test in playground.
6. Verify traffic in **Activity**.

## Where to go next

<CardGroup cols={2}>
  <Card title="How it works" icon="workflow" href="/trustguard/how-it-works">
    The guard pipeline, gates, and the findings model.
  </Card>

  <Card title="Core concepts" icon="boxes" href="/trustguard/concepts/detectors">
    Detectors, policies, and collectors.
  </Card>

  <Card title="Policies" icon="shield-check" href="/trustguard/concepts/policies">
    Gates, detector rules, and the Report / Enforce switch.
  </Card>

  <Card title="Detector catalog" icon="list" href="/trustguard/detectors/overview">
    Every built-in detection and its settings.
  </Card>

  <Card title="Evaluate API" icon="code" href="/trustguard/api/evaluate">
    The `POST /v1/evaluate` request and response contract.
  </Card>

  <Card title="Telemetry Alerts" icon="siren" href="/platform/alerts">
    Turn guard findings into prioritized alerts — prompt-injection spikes, leaked PII/secrets, toxicity bursts.
  </Card>
</CardGroup>