> ## 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. # Prompt Template > Inject a system prompt into every request an application makes, or publish a prompt library clients invoke by name and version. Applies to **LLM**. One policy type doing two unrelated jobs; the console asks which before showing fields. ### Inject a system prompt into every request Every application that calls a model carries its own system prompt, so the organisation's rules — tone, what the assistant may not do, what it must disclose — live in a dozen codebases and drift apart. Injecting the prompt at the gateway puts one copy where every request passes, and changing it needs no release. Your platform team writes the prompt; the gateway injects it; callers send their requests unchanged and never see it. The parts that vary per request are `{{placeholders}}`, each mapped to a **header** or a **JWT claim** to read at request time — a tenant id from `X-Tenant-Id`, a plan tier from a claim. A placeholder with no source cannot be saved. **If a variable is missing** at request time: skip the template (default — the caller cannot fix a header it was never asked to send), substitute an empty string, or reject. A **JWT claim** is read without verifying the token's signature. It is trustworthy only when the caller authenticates with that same bearer token. An application that authenticates with an API key can put anything in an `Authorization` header, and the claim you read is whatever it put there. Never make an authorisation decision on a claim unless bearer auth is the only way in. ### Publish a prompt library clients invoke A prompt is part of the product and changes more often than the client does. Publishing it from the gateway lets the people who own the prompt ship it without a deployment, and lets a client pin the version it was tested against. Prompts live on the gateway and change without a client release. A client references one by name in a plain user message — `{template://support-greeting}`, or `@stable` to pin a label — and the gateway renders it. Placeholders are filled by the client, or by a header or claim the gateway reads so the client cannot influence that value. Rendering a named template **replaces the entire message list**. Conversation history the client sent is discarded before the model sees anything. This fits single-turn calls; the trace reports how many turns were dropped. Two switches shape the library. **Require a template reference** rejects any request that does not name a template, which turns the gateway into the only source of prompts for that application. A **default label** answers a reference that names a template but no label. The console saves one version labelled `latest`. Versioning beyond that is API-only; a template that already carries several versions keeps them, and the panel says so rather than editing them.