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
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.
Related decisions
Next step
Use the product page for exact limitations and access requirements, then copy the corresponding REST or MCP workflow.