Skip to main content
TrustGuard inspects prompts, completions, and tool traffic, so the first question any security review asks is what it keeps. This page answers that for the runtime path (POST /v1/evaluate).

​
What is stored

An evaluation produces two kinds of record, and they are not equally detailed. The request body is persisted. That is the important sentence on this page: if a prompt is evaluated, its text can be read back in the console by anyone with access to your workspace, subject to the redaction and retention rules below. Plan your workspace permissions accordingly.

​
What is redacted before storage

Sanitisation runs before anything is written, and it is not configurable. Credential headers are replaced with a placeholder, so a collector API key never lands in storage:
Credential-looking body fields are replaced with [REDACTED] by key name, regardless of nesting: password, passwd, secret, token, api_key, apikey, authorization, credential, access_token, refresh_token, client_secret, and private_key. Multipart bodies are never stored as content. They are replaced wholesale with {"_multipart": true}.
Redaction targets credentials, not personal data. A prompt containing a customer’s name, email, or account number is stored as written unless a DLP rule set to Transform masks it. If you do not want PII reaching storage, mask it with a Transform rule rather than relying on sanitisation.

​
Attachments

Files and URLs are handled apart from the body and are never stored:
  • payload.attachments are decoded for the detectors that consume them (today doc_analyzer) and discarded.
  • Remote attachment URLs are fetched server-side under a strict SSRF guard — HTTPS only, with loopback, private, link-local, CGNAT, and cloud-metadata addresses blocked — and the fetched content is not retained.
Details: Attachments and SSRF.

​
Retention

Retention is a per-team entitlement, not a single global default. Every stored record carries its retention plan and an absolute expiry stamped when it was written, so a record written today expires on a fixed date — changing entitlements later does not retroactively extend or shorten records already stored. For teams entitled to TrustGuard the default window is 365 days. Your team’s actual value is the one stamped on it, so read it in the console rather than assuming the default: a shorter window can be provisioned on request. If you need a specific window contractually, or shorter than what is stamped, raise it with your NeuralTrust contact — it is an entitlement change, not a policy setting, so you cannot alter it yourself from the console.

​
Where it is stored

Findings and sanitised bodies leave TrustGuard over OTLP and land in the NeuralTrust metadata store, which is what Activity, analytics, and the alerting rules read. The event schema documents the record shape. The storage location follows your deployment: If data residency is a requirement, confirm your region with your NeuralTrust contact before onboarding traffic — it is set when the workspace is provisioned.

​
Reducing what gets stored

If your threat model calls for storing less:
  • Mask at the edge. A DLP rule set to Transform rewrites the payload, so downstream records hold the masked form.
  • Scope your collectors. Traffic that never reaches a collector is never evaluated and never stored. Attach policies deliberately rather than workspace-wide.
  • Use gates to waive traffic. A gate with the Skip action stops evaluation for matched requests, so no detector runs on them. See Policies.