Secret redaction in tool results
When an agent calls a tool, the tool’s output is scanned for credential-like secrets before it is spliced back into the model’s context. Any match is replaced with a[REDACTED:<type>] marker, so a leaked key in an API response, log line, or file never becomes part of the ongoing conversation the model sees.
- Where it runs — On tool-result content, immediately before that content is added to the agent’s message context. Redaction runs before the result is truncated to its size cap, so a secret straddling the truncation boundary can’t lose its tail and leak as a partial credential.
- Detection method — Prefix-anchored pattern matching with a keyword pre-filter. There is no entropy scoring and no generic keyword matching, which keeps false positives near zero: clean output passes straight through untouched.
- Direction — One-way. The original secret is discarded from the model context. There is no stored mapping and no un-redaction step.
What is detected
Redaction targets well-known secret formats with unique prefixes, not general personal data. The patterns cover credentials such as:- Cloud provider keys — AWS access keys
- Source control tokens — GitHub (PAT, OAuth, app, fine-grained), GitLab PAT
- Messaging — Slack bot, user, and app tokens, and incoming webhook URLs
- Payment and email — Stripe secret/restricted keys, SendGrid keys
- AI providers — OpenAI and Anthropic API keys
- Package and infra — npm tokens, DigitalOcean PATs, Doppler tokens, Age secret keys
- Private keys — PEM-encoded RSA/DSA/EC/OpenSSH/PGP private keys
- MagOneAI platform keys — the platform’s own API-key format
This is credential redaction, not PII redaction. Names, email addresses, phone numbers, and national IDs are not targeted by these patterns. Do not rely on this mechanism to strip personal data from model prompts.
Sandboxing untrusted content
Content that originates outside the workflow author, such as retrieved knowledge, stored memory, chat attachments, and user-supplied field values, is treated as untrusted before it enters a prompt. Two things happen to it:1
Structural cleanup
Chat-template protocol delimiters (ChatML and Llama-style role markers) are stripped, control characters are removed, and runs of excessive blank lines are collapsed. These delimiters have no legitimate use in natural content, and a forged one could otherwise fake a role boundary in a concatenated prompt.
2
Data-only fencing
The cleaned content is wrapped in XML tags with an explicit notice that it is retrieved data, not instructions to follow. Any attempt by the untrusted text to inject its own closing tag and escape the fence is stripped. Retrieved reference material (knowledge the agent is meant to use) gets a softer notice that still forbids treating embedded text as system commands.
Human: or ### System: are deliberately left intact, because they do not create an API-level role boundary and stripping them would corrupt legitimate transcripts, email threads, and config files.
Keeping sensitive data out of a provider entirely
Redaction and fencing operate on content inside a prompt; they do not remove personal data from the inputs your workflow is designed to process. When a workflow must handle sensitive data and you need certainty that a third-party provider never sees it, the platform-level control is model placement:- Private models — Route sensitive workloads to a locally-deployed model (such as a self-hosted vLLM or Ollama endpoint). The data never leaves your infrastructure and never reaches a third-party AI provider.
- Self-hosted deployment — Running MagOneAI within your own network keeps all execution, logging, and storage under your control. See the security overview for the full data-residency picture.
Next steps
Private models
Keep sensitive data in your network with locally-deployed LLMs
Security overview
See how prompt safety fits into defense-in-depth
Secrets and Vault
How credentials are stored and injected at runtime
Input limits
Per-execution caps that bound every workflow run