A benefits agent must not send Social Security numbers into downstream tools. Which NeMo Guardrails control fits best?
Select an answer to reveal the explanation.
Short Explanation
SSNs don’t belong in tool payloads—think blacking out a Social Security card before scanning it. Input rails that redact SSN patterns protect benefits-agent pipelines.
Full Explanation
A benefits agent that can call tools must not ship Social Security numbers into downstream systems in cleartext. The NeMo Guardrails control that fits best is applying input rails that redact SSN patterns before tools run. Input rails inspect and transform user content at the boundary, removing or masking identifier patterns so tool invocations, logs, and secondary services never receive raw SSNs while the resident conversation can still proceed with a safe tokenized or partially redacted form where policy allows.
Logging full SSNs in cleartext so tools can “learn” resident identity patterns fails as a privacy and security anti-pattern—it expands breach blast radius and contradicts minimization. Stripping input rails entirely to maximize tool-calling speed fails by trading trivial latency for uncontrolled PII exfiltration into every tool hop. Asking residents to email SSNs to a shared inbox outside the agent path fails operationally: it creates an ungoverned side channel that is often less monitored than the agent path and still exposes SSNs.
Exam caveat: redaction rails are pattern-and-policy controls, not complete identity proofing. Some benefits workflows may require human-mediated identity verification in a secure portal; the agent should refuse to collect SSNs when the channel is inappropriate rather than partially process them unsafely.
Operational check: send prompts containing well-formed and obfuscated SSN variants, confirm tools receive redacted payloads, verify logs do not retain raw SSNs, and include these cases in CI safety tests whenever rails or tool schemas change.