NVIDIANVIDIA-Certified Professional: Agentic AI2026-109.2 Integrate compliance guardrails (privacy, enterprise policy).
Redact PII before each data exposure
Completed by the knowledge check
Learning objective
Detect and redact PII in prompts, outputs, retrieved content, and traces.
Core idea
Personally identifiable information (PII) can enter an agent through a user message, a retrieved document, or a tool result, and leave through an answer or a trace. Protect each copy before it reaches a destination that must not receive it. A masked answer says nothing about whether an inference request or telemetry exporter already received the original text.
NeMo Guardrails integrates NVIDIA GLiNER-PII NIM and Presidio for detection and masking on input, output, and retrieval. Those are content-processing controls. Trace capture has separate controls, and the telemetry pipeline needs its own sanitization. See 7.1.1 for rail placement in general; here you choose what information each surface may expose and how to verify that decision.
How it works
Define the entities and the disposition
Choose where detection runs. Presidio uses in-process analyzer and anonymizer dependencies with a spaCy model. GLiNER-PII runs behind an HTTP NIM endpoint: configure rails.config.gliner.server_endpoint, threshold in 0.0–1.0, and per-source input.entities, output.entities, and retrieval.entities. Its model defaults to nvidia/gliner-pii; labels include email, phone_number, ssn, and first_name.
The GLiNER flows are gliner detect pii on input and gliner mask pii on input, with corresponding output and retrieval variants. Detection blocks; masking substitutes label placeholders such as [FIRST_NAME]. Use api_key_env_var for the NVIDIA-hosted endpoint, or point server_endpoint to a locally hosted NIM. Local serving requires capacity; hosted detection sends checked text across that service boundary. An unavailable detector endpoint prevents completion of the HTTP check: test that failure path before accepting traffic, without treating an unchecked request as safe. GLiNER retrieval flows also require LLMRails.
For Presidio, configure rails.config.sensitive_data_detection.input.entities in config.yml, with separate output.entities and retrieval.entities lists under the same sensitive_data_detection section. Documented entity examples include PERSON and EMAIL_ADDRESS. A list scoped only to input does not express the output or retrieval policy.
Activate mask sensitive data on input under rails.input.flows to rewrite detected sensitive parts and continue processing. The alternative, detect sensitive data on input, refuses to respond when it detects sensitive data. The corresponding output and retrieval flow names substitute output and retrieval for input.
Reject requests when removing a sensitive field makes the task unsafe or meaningless. Mask when the remaining text still supports a useful answer, such as explaining a procedure after removing an email address.
The Presidio integration requires the analyzer, anonymizer, and spaCy dependencies, plus the en_core_web_lg model. NVIDIA documents the nemoguardrails[sdd] extra as an installation alternative. Exercise the deployed rail before admitting traffic: on LLMRails, Presidio imports occur lazily, so a missing dependency can fail the first request that runs the action rather than the process startup.
Cover prompts, retrieved chunks, and answers
Apply each flow before its corresponding exposure: input before downstream processing, retrieval before using retrieved chunks, and output before returning the checked response. Retrieved records can contain PII even when the question contains none.
Retrieval masking requires LLMRails. NVIDIA’s engine matrix supports Presidio input and output detection and masking on both LLMRails and IORails, but retrieval flows only on LLMRails, because IORails has no retrieval pipeline. A configuration declaring rails.retrieval routes to LLMRails by default; require_iorails=True raises ValueError instead of permitting that fallback. Choose the engine from the required protection surface.
The per-source score_threshold controls the minimum confidence accepted for a detection. NVIDIA documents a default of 0.2; increasing it reduces false positives by requiring stronger confidence. Evaluate missed PII as well as false alarms before raising it. If employee-specific identifiers are missed, the documented recognizers configuration supports custom recognizers with fields such as supported_entity and deny_list. Repair coverage with representative examples and an appropriate recognizer, rather than declaring an untested threshold safe.
Sanitize telemetry independently
Guardrails traces exclude prompt and response content by default. Keep tracing.enable_content_capture: false when timing, model names, token usage, and rail decisions are sufficient. This setting is available on both engines. On the early-release, opt-in IORails engine, OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=false forces capture off; LLMRails uses the configuration field and does not consult that variable.
The content-capture documentation marks the feature experimental. If capture is enabled on IORails, guardrails.request.input holds caller input and CLIENT spans can hold raw model responses even when the caller receives a refusal. Output masking is therefore not a guarantee that captured model content is masked. Inspect every exporter-bound representation, including span events and application logs.
For retained telemetry, Collector attributes actions such as action: delete and the redaction allowlist processor address attributes. IORails CLIENT content defaults to span events such as gen_ai.user.message and gen_ai.choice; use transform with the spanevent context under trace_statements for event content. OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental switches CLIENT content to JSON span attributes. Match sanitization to the emitted form; deleting span attributes alone can miss events. Remove prohibited fields or transform required diagnostic content, then test the exporting pipeline’s payload.
NeMo Agent Toolkit’s Weave exporter separately provides redact_pii (default false), redact_pii_fields, and redact_keys; these controls apply to that exporter, not every telemetry destination (see 3.3.2).
Collector sanitization protects downstream storage after collection. When a policy prohibits the collector itself from receiving raw PII, disable content capture or sanitize before that boundary. Hashing a predictable user identifier is not reliable anonymization: OpenTelemetry warns that a small input space can make the original recoverable.
Each masking flow guards only its own exposure, while captured trace content takes a separate path into the telemetry pipeline.
Key distinctions and trade-offs
Use the destination to decide which control must run:
| Surface | Mechanism | Decision and cost |
|---|---|---|
| User prompt | mask sensitive data on input or detect sensitive data on input | Continue with reduced context, or refuse; masking can remove task-critical details. |
| Retrieved content | mask sensitive data on retrieval | Protect context entering generation; requires the LLMRails retrieval path and adds checking work per retrieval. |
| Generated answer | mask sensitive data on output | Reduce disclosed content; does not repair raw content already sent elsewhere. |
| Detector hosting | Presidio in-process or GLiNER server_endpoint | Local dependencies versus NIM capacity, HTTP latency, service availability, and data location. |
| Traces | tracing.enable_content_capture, Collector attributes/redaction/transform | Minimize capture or sanitize retained fields; less content makes diagnosis harder. |
Masking retrieved text does not erase its source document or persisted index. Retention is a separate decision in 9.2.2. Likewise, a detector’s entity list and threshold define coverage; a successful execution alone does not establish that every sensitive entity was found.
Architecture / decision scenario
An insurance claims assistant handles 6,000 requests daily under a hypothetical policy prohibiting claimant PII in model prompts and the central telemetry store. Its p95 response target is 2.5 seconds. The tempting proposal is an output mask plus full tracing for troubleshooting: a trial meets latency, but synthetic canary emails appear in 14 of 100 exported traces and 11 of 100 retrieved contexts sent for inference.
The privacy owner rejects that design. The application team selects LLMRails, configures input, retrieval, and output entity lists, and activates the three masking flows. Claims whose required identifiers cannot be removed without changing the task take the rejection path instead. This exercises prompts, source chunks, and answers separately.
The observability owner keeps content capture disabled and deletes prohibited identity attributes in the Collector pipeline. Synthetic canaries are checked at the model-request boundary, caller response, and telemetry export. Suppose the revised trial reaches p95 2.7 seconds: it fails the latency target, even if the privacy checks pass. The team must optimize or reduce checked context and rerun coverage tests; dropping retrieval protection to recover 200 milliseconds would violate the deciding policy.
Common exam traps
- Treating
detectas a synonym for masking and continuation. - Configuring input entities while leaving retrieved context and output unchecked.
- Selecting
IORailswhile assuming its retrieval pipeline runs Presidio rails. - Assuming a masked answer proves captured model responses are sanitized.
- Raising
score_thresholdwithout measuring missed entities. - Treating hashes or masked retrieval results as deletion from durable storage.
What to remember
Configure entity coverage and disposition for each content surface. Use LLMRails when retrieval rails are required. Minimize trace capture and sanitize telemetry through its own pipeline; inspect the bytes at each protected destination, not only the visible answer.
Knowledge check
An HR assistant answers questions about internal procedures. Employees often paste messages that include a colleague’s email address, which the answer never needs. Policy forbids sending email addresses to the main model, but the question should still be answered. Which Presidio flow fits?
detect sensitive data on inputdetect sensitive data on outputmask sensitive data on inputmask sensitive data on outputA retrieval-augmented assistant’s policy requires Presidio to mask PII in retrieved chunks before they reach generation. The team currently runs NeMo Guardrails with require_iorails=True for its input and output rails. Which change meets the requirement?
LLMRails with mask sensitive data on retrievalmask sensitive data on retrievalmask sensitive data on input onlymask sensitive data on output onlyLLMRails , because IORails has no retrieval pipeline; a configuration that declares retrieval rails routes to LLMRails by default, and require_iorails=True raises an error instead. Input masking checks the user’s message, not the retrieved records, and output masking runs after the chunks have already reached generation.A team runs NeMo Guardrails on the LLMRails engine. Its config.yml still sets tracing.enable_content_capture: true from a debugging session. Operators try to stop capture by setting OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=false on every pod, yet exported traces still contain prompt text. What is the fix?
mask sensitive data on output to the output railstracing.enable_content_capture: false in the configurationLLMRails , content capture is controlled by the configuration field only; the environment variable that forces capture off is honoured by IORails, so on this engine neither false nor an unset variable changes anything while the field says true . Output masking changes the caller’s answer, and editing application logs changes a separate copy; neither disables trace capture.Presidio input masking passes tests for names and email addresses, but employee badge numbers such as EMP-48213 pass through unmasked. The analyzer returns no detection for them at any confidence score. Which change addresses the gap?
score_threshold for the input sourcescore_threshold for the input sourcerecognizers configuration does with fields such as supported_entity and deny_list . A threshold filters detections that exist; raising it removes more and lowering it cannot surface one that was never made, and detection refuses on the same entities masking would rewrite, so it misses badges too.A claims assistant runs on IORails, and OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT is unset on its pods. Its policy forbids claimant PII from reaching the central OpenTelemetry Collector at all, not only the storage behind it. Engineers propose enabling content capture for troubleshooting and removing PII in the Collector pipeline. Which approach meets the policy?
redaction processorattributes processorOTEL_SEMCONV_STABILITY_OPT_IN variabletracing.enable_content_capture: false does. Hashing a predictable identifier is not reliable anonymization either, and OTEL_SEMCONV_STABILITY_OPT_IN selects whether captured content is encoded as span events or attributes, not whether it is captured.References
- NVIDIA, Presidio Integration
- NVIDIA, Capturing Prompt and Response Content
- OpenTelemetry, Handling sensitive data
- NVIDIA, PII Detection
- NVIDIA, Observe Workflows
- OpenTelemetry, Transform processor