Documentation Grafana Cloud AI and machine learning Grafana AI Observability Manage privacy and security Redact PII and secrets

PII and secrets redaction

Grafana AI Observability provides two layers of redaction to keep sensitive data out of LLM provider requests and out of your generation history:

• SDK-side secrets redaction — your application SDK detects and redacts secrets before generation data is exported.
• Server-side guards — synchronous redaction rules and PII evaluators that run on the request path before each LLM call.

Use the SDK layer to keep credentials out of your traces. Use guards to apply organization-wide policies that scan and redact requests before they reach the model.

Before you begin

• An AI Observability SDK is installed in your application. Refer to Get started for installation.
• For guard-based redaction, AI Observability is deployed and receiving generation data.

Redact secrets with the SDK

The Go, Python, JavaScript, Java, and .NET SDKs include a built-in secrets sanitizer that runs in the generation pipeline. When enabled, the sanitizer scans message content, tool calls, tool results, and system prompts before the SDK exports the generation. Detected secrets are replaced with [REDACTED:<category>] placeholders, so credentials never reach AI Observability storage.

Secrets redaction is opt-in. Enable it by passing the sanitizer to your client configuration.

Review SDK support

Secrets redaction is available in all five SDKs. Email address redaction is on by default in each SDK.

Review detected secrets

The SDK sanitizer ships with hand-curated patterns sourced from gitleaks. The same patterns are applied across Go, Python, JavaScript, Java, and .NET.

The sanitizer applies a high-confidence pass to all assistant text and reasoning, and an extended pass (which includes the heuristic env-style assignments) to tool arguments, tool results, and system prompts. This split keeps false positives out of model reasoning while catching credentials in tool inputs.

The SDK sanitizer doesn’t detect names, addresses, government IDs, phone numbers, or other general PII. For that, use a guard.

Enable secrets redaction

Pass the sanitizer to your client configuration. Once enabled, the sanitizer runs automatically on all generation exports.

Go

Go Copy

import "github.com/grafana/sigil-sdk/go/sigil"

client := sigil.NewClient(sigil.Config{
    GenerationSanitizer: sigil.NewSecretRedactionSanitizer(sigil.SecretRedactionOptions{}),
})

Python

Python Copy

from sigil_sdk import Client, ClientConfig, create_secret_redaction_sanitizer

client = Client(ClientConfig(
    generation_sanitizer=create_secret_redaction_sanitizer(),
))

JavaScript

JavaScript Copy

import { SigilClient, createSecretRedactionSanitizer } from "@grafana/sigil-sdk";

const client = new SigilClient({
  generationSanitizer: createSecretRedactionSanitizer(),
});

Java

java Copy

SigilClient client = new SigilClient(new SigilClientConfig()
    .setGenerationSanitizer(SecretRedaction.createSecretRedactionSanitizer()));

.NET

csharp Copy

using Grafana.Sigil;

var client = new SigilClient(new SigilClientConfig
{
    GenerationSanitizer = SecretRedactionSanitizer.Create(),
});

Redact user input messages

By default, the sanitizer leaves user messages untouched so that intentional user-provided context, for example, a SQL query a user pasted into a chat, isn’t redacted. To also redact secrets from user messages, opt in:

• Set RedactInputMessages: true (Go), redact_input_messages=True (Python), redactInputMessages: true (JavaScript), setRedactInputMessages(true) (Java), or RedactInputMessages = true (.NET) on the sanitizer options.
• Or set the environment variable SIGIL_REDACT_INPUT_MESSAGES=true.

Explicit options take precedence over the environment variable.

View redacted content

When the sanitizer detects a secret, it replaces the matched substring with a tagged placeholder:

Original tool argument:

Copy

{"command": "curl -H 'Authorization: Bearer ghp_aBcDeFgHiJkLmNoPqRsTuVwXyZ0123456789'"}

Sanitized tool argument exported to AI Observability:

Copy

{"command": "curl -H 'Authorization: [REDACTED:bearer-token]'"}

Placeholders follow the format [REDACTED:<category>], where <category> identifies the pattern that matched, for example, aws-access-token, github-pat, openai-api-key, anthropic-api-key, email-address.

Redact secrets with server-side guards

Guards run on the request path before each LLM call and return an allow or deny decision to the SDK. Two guard types are relevant to redaction:

• Transform guards apply regex patterns to redact content in messages, system prompts, tool definitions, and tool call arguments. The SDK uses the sanitized copy for the LLM call.
• Evaluator guards with the built-in sigil.pii LLM judge detect personally identifiable information based on a semantic policy rather than fixed patterns.

For the full guard configuration workflow, refer to Set up guards.

Detect PII with the sigil.pii evaluator

The built-in PII evaluator is an LLM judge. Because it uses semantic judgment rather than fixed patterns, it catches PII that regex misses, for example, an address written in natural language, at the cost of an additional LLM call per guarded request. Configure judge providers in Configure evaluation.

It flags responses containing:

• Contact details, for example, email addresses or phone numbers.
• Postal addresses.
• Government-issued identifiers.
• Financial details.
• Credentials.
• Exact dates of birth.
• Combinations of attributes that identify a private individual.

Redact with transform guards

Transform guards use regex patterns you define, for example, to redact US SSNs and phone numbers:

Transform guards scan system prompts, message text in user, assistant, and tool messages, tool call arguments (JSON serialized), tool result content, and tool definition descriptions and input schemas.

Transform guards don’t scan model thinking blocks, because transforming them would invalidate the provider’s reasoning signature.

For the full transform guard workflow, refer to Set up guards.

Understand coverage and limits

The SDK and guard layers cover different paths. SDK secrets redaction sanitizes generation content before it leaves your application, so credentials don’t reach AI Observability storage or traces. Guard transform and PII rules sanitize outbound request content before it reaches the LLM provider — the sanitized copy is what the model sees.

Redaction doesn’t cover:

• Responses from the LLM provider — generated text isn’t scanned by the SDK sanitizer or guard transforms. If a model emits sensitive data in its response, that content reaches your application and traces unmodified. For response-side checks, attach an evaluator guard that runs after generation.
• Streaming responses — postflight evaluation buffers complete responses today; AI Observability doesn’t yet support per-chunk scanning of streaming responses.
• Model thinking blocks — transform guards skip thinking content to preserve provider reasoning signatures.
• Reversal of redacted values — [REDACTED:<category>] placeholders are permanent. AI Observability doesn’t store a mapping back to the original value, so the model and downstream consumers both see the placeholder. If your workflow requires the model to act on the original value, for example, processing a refund using the real SSN, redact in a layer that handles de-redaction separately.

If your security model requires that sensitive data never enters AI Observability under any path, combine SDK-side sanitization for client-trusted data with server-side guards for any data that originates outside your control.

Next steps

• Set up guards to configure server-side redaction policies.
• Data handling and privacy for what AI Observability stores and how to control retention.
• Security and access controls for authentication and authorization.