> ## 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.
> ## Agent Instructions
> These docs cover three products: TrustGate (AI agent gateway), TrustGuard (runtime security), and TrustTest (AI red teaming). Start from each product overview for the definition and How it works. Prefer the .md URL next to a page in /llms.txt when you need the full article. Use /llms-full.txt for a single-file dump of the site.
# Quickstart
> Protect a TrustGate gateway end to end: build a security policy, connect the collector, watch it in Observe, then enforce.
One complete pass: two detectors, one policy, a TrustGate collector, and the
switch from watching to blocking. Twenty minutes, and nothing is enforced until
the last step.
This walks the [TrustGate](/integrations/trustgate) path because it is the only
one where nothing is deployed and no code changes — the gateway already sits in
front of your model, so it can both send traffic and enforce the answer. Every
other [collector](/trustguard/concepts/collectors) follows the same four ideas in
a different order.
**Before you start** you need TrustGuard entitled — if **Agent Runtime** is not in
the console sidebar, your team does not have it — and a
[TrustGate gateway](/trustgate/getting-started/quickstart) already routing traffic.
Open **Agent Runtime → Detectors** and click **New detector**. Pick **Prompt
Guard** from the catalog.
On **Basics**, set **Name** to something that says how it is tuned — `Jailbreak —
balanced` — because this is the name you will pick from inside the policy, and
*Prompt Guard 2* will mean nothing to you in a month.
On **Configuration** you get one control:
[**Protection Sensitivity**](/trustguard/detectors/content-security#protection-sensitivity).
Leave it on **Balanced**. It is the recommended preset and the right starting
point; tightening it before you have seen real traffic only buys false positives.
Click **Create detector**.
Repeat with **Data Loss Prevention**, named `Secrets — block`.
On **Configuration**, open **Data Categories** and enable the **Secrets &
credentials** group — API key, access token, JWT token, Stripe key. Leave the rest
off for now: a first policy that flags every email address in every prompt is a
policy people learn to ignore.
Click **Create detector**.
Open **Agent Runtime → Policies** and click **New Policy**. On **Basics**, set
**Policy name** to `Gateway — baseline` and leave **Enforcement mode** on
**Observe**.
Observe is the whole point of this step: every action is recorded and none is
applied, so you can be wrong about your own traffic without anyone noticing.
Open the **Detectors** tab and add two rules under **Input**:
| Detector | Action | Why |
| ---------------------- | ----------- | ---------------------------------------------------------- |
| `Jailbreak — balanced` | **Monitor** | You want to see the volume before you block on it |
| `Secrets — block` | **Block** | A credential in a prompt is a bug, not traffic to clean up |
Save the policy.
**Block** on the secrets rule is not enforced yet — the policy is in Observe, so it
is recorded as a report. That is intentional: configure the end state now, review
it, and flip one switch at the end.
Open **Agent Runtime → Collectors → Catalog**, find **TrustGate** under
**Gateway**, and click **Add collector**. Select the gateway you want to protect.
TrustGate is the one collector with no **Auth** step — it is native, so it
authenticates through the platform and never needs an API key of its own.
On the collector's **Policies** tab, set `Gateway — baseline` as the **default
policy**.
A collector with no matching policy is not protected — it allows everything and
inspects nothing, silently. This step is what makes the previous three do
anything.
The collector says *which* policy evaluates the traffic. The gateway still has to
send it.
In **TrustGate**, open **Policies → Catalog** — guardrails are listed first — and
enable the **TrustGuard** guardrail on the routes you want covered. See
[TrustGate integration](/integrations/trustgate) for the route-level detail.
Make a few normal calls through the gateway, then something that should trip a
rule — ask the model to ignore its instructions, or paste a fake API key.
Open **Activity**. You should see one finding per trip, each showing the detector,
the outcome, and the request behind it.
Nothing was blocked. The policy is in Observe, so this is a rehearsal — and the
question to answer here is not "did it catch the obvious test", it is **how many
findings did normal traffic produce**. That number is what tells you whether
Balanced was the right preset.
Open the policy's **Test** tab and try the prompts you are unsure about.
Test evaluates the **last saved** policy, not your unsaved edits. If you changed a
rule and the result surprises you, save first and try again.
When Activity looks right, open the policy's **Basics** tab and switch
**Enforcement mode** to **Enforce**.
From this point the secrets rule blocks, and the jailbreak rule keeps recording.
Promote the jailbreak rule from **Monitor** to **Block** when you have seen enough
of its findings to trust it — as a separate change, so that if blocking starts
biting you know exactly which change caused it.
## What you built
| Piece | What it does |
| ------------------------------------------------ | -------------------------------------------------------- |
| Two [detectors](/trustguard/concepts/detectors) | Find things. They never decide anything |
| One [policy](/trustguard/concepts/policies) | Decides the action, and holds the Observe/Enforce switch |
| One [collector](/trustguard/concepts/collectors) | Sends the traffic and applies the verdict |
The detectors are reusable. The next policy — a stricter one for a
customer-facing route, say — references the same two, and retuning one improves
every policy that uses it.
## Where to go next
The other six detectors, and how much each one has to configure.
Gates, per-consumer routing, and which action wins when several fire.
Coding agents, agent platforms, SDKs, and other gateways.
What each host can actually apply — not every one can mask.