How to Sanitize Untrusted Context Before an AI Agent Reads It
Normalize hidden Unicode, detect secrets, and surface structural risk signals before email, documents, webpages, or retrieval results enter an AI-agent context.
Short answer
Treat retrieved text as data, normalize mechanical obfuscation, detect sensitive patterns, and surface risk indicators before adding it to the model context. Keep semantic instructions from untrusted sources separated from trusted system instructions.
The failure this prevents
An agent may read email, web pages, tickets, or extracted documents containing invisible controls, mixed scripts, encoded payloads, secrets, or instructions aimed at the model rather than the human reader.
Recommended workflow
- Label the source and keep untrusted content in a separate data field.
- Normalize hidden and control characters with a deterministic preprocessing step.
- Inspect risk signals and optionally redact common sensitive patterns.
- Apply an allowlist for the downstream tools and data the task actually requires.
- Validate the model output before any consequential action.
Working starting point
curl https://api.scrubmytext.com/v1/sanitize-context \
-H "Authorization: Bearer smt_live_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"UNTRUSTED_RETRIEVED_TEXT","mode":"strict","redact_sensitive":true}'Relevant product: SanitizeMyContext · Browser + REST + MCP
Reproducible example
Inspect an email that mixes hidden structure with instructions
A customer email contains a zero-width character inside a hostname and a paragraph telling the assistant to ignore earlier instructions. The business task is to extract the order number, not to obey instructions embedded in the email.
- Expected behavior
- Normalization removes the bounded hidden-character artifact and the scan reports structural or instruction-override signals. The email remains untrusted data, and the orchestrator restricts tool access regardless of whether the model says the content looks safe.
- What it teaches
- Mechanical normalization improves visibility but cannot decide intent. The safe design combines source labels, least privilege, output validation, and independent action controls instead of turning one sanitizer result into a security certificate.
Production verification checklist
- Preserve the source label next to sanitized content so trust boundaries remain visible.
- Test that suspicious input cannot expand the agent’s tool allowlist.
- Require approval or another external control for consequential actions even when the scan reports low risk.
Decision rule
Sanitization reduces mechanical ambiguity; it does not prove semantic safety. A suspicious or unnecessary source should remain excluded, and consequential tool use still needs independent authorization.
Good fit
- External text is being inserted into an agent’s working context.
- Hidden Unicode, mixed scripts, encoded payloads, or secrets would change your risk decision.
- You want a reproducible preprocessing report rather than an LLM self-assessment.
Use another approach when
- You expect the sanitizer to understand and neutralize every semantic instruction.
- The agent can safely avoid ingesting the source altogether.
- You have not limited which tools the agent can call after reading the content.
Options compared
| Option | Strength | Important limitation | Best fit |
|---|---|---|---|
| Prompt instruction: ignore attacks | No integration work | Relies on the same model being targeted | Defense-in-depth wording only |
| SanitizeMyContext | Deterministic normalization and bounded indicators | Does not solve semantic prompt injection | Preprocessing and triage |
| Content allowlist | Strong source reduction | Requires curated sources | High-consequence retrieval |
| Sandbox + least privilege | Limits damage after model error | Does not classify the content | Always for consequential tools |
Implementation cautions
- Keep tool permissions narrow even after a clean report.
- Do not automatically trust base64-decoded or normalized output.
- Preserve source identity so downstream decisions can distinguish trusted and untrusted data.
Frequently asked questions
Does sanitization remove prompt injection?
No. It handles bounded mechanical and pattern-based risks; semantic instructions can remain.
Should the agent see the risk report?
The orchestrator should use it to decide whether and how to continue. Avoid letting untrusted text override that policy.
Can this replace sandboxing?
No. Sandboxing, least privilege, approval, output validation, and action controls address different failure modes.
How this guidance was reviewed
The product behavior described here is checked against ScrubMyText's public OpenAPI contract and automated contract tests. The worked example is synthetic and contains no customer data. Recommendations separate verified product behavior from broader implementation judgment, and every limitation remains visible rather than being converted into a marketing claim.
Related decisions
Next step
Use the product page for exact limitations and access requirements, then copy the corresponding REST or MCP workflow.