Reduce the risk of secrets in prompts by keeping credentials, tokens, and personal data out of user-visible and model-visible text. Use secret storage outside the prompt, redact sensitive fields before sending context, and block prompts that request disclosure of values. Review logs, cache contents, and tool outputs for accidental retention or re-use of secrets.
How to keep secrets out of prompts without breaking the workflow
The safest pattern is to treat prompts as an untrusted transport layer, not a secrets store. Keep credentials, tokens, session material, and personal data in dedicated secret stores or controlled context, then inject only the minimum non-sensitive values needed for the task. For workflows that rely on prompt templates, design them so the model can complete the job without ever seeing the underlying secret.
A practical way to do this is to shift from raw disclosure to controlled substitution. Instead of passing a live value into the prompt, pass a reference, label, or masked placeholder, then resolve the sensitive value outside the model boundary at the last possible moment. That reduces accidental exposure in chat history, copied prompts, training-like retention paths, and downstream logs.
For teams building AI features, the main design choice is not whether secrets can be hidden perfectly, but whether the workflow can still function when the model only sees the non-sensitive parts of the request. When that is not possible, the safer fallback is to move the sensitive operation into a tool or backend service and keep the model at the orchestration layer rather than the disclosure layer. The OWASP Cheat Sheet Series is a useful implementation reference for secure handling patterns across prompts, authentication, and logging.
What should be redacted, blocked, or isolated before the prompt is sent?
Redaction should cover anything that would be harmful if copied into logs, memory, caches, or analytics. That includes API keys, bearer tokens, passwords, private keys, secrets embedded in configuration, and personal data that is not required for the task. If the prompt includes user-provided text, sanitise it before it reaches model-visible context, especially when the application automatically appends metadata, attachments, or retrieved documents.
Blocking is appropriate when the prompt explicitly asks for disclosure of a secret or for a model to retrieve sensitive values that should never appear in free text. The right control here is policy enforcement at the application boundary, not a warning label after the fact. A request that would cause a value to be written into a prompt, response, or audit trail should be rejected or rerouted to a secure workflow.
Isolation matters just as much as redaction. Separate tenant-specific context, developer debugging data, and production secrets so that one prompt cannot accidentally surface another environment's sensitive material. If you already manage non-human access tokens and service credentials, the OWASP Non-Human Identity Top 10 gives a useful lens for thinking about secret handling, rotation, and overprivilege around machine-facing credentials.
For workflow-level guidance, Generative AI Data Loss Prevention Guide covers prompt redaction, browser controls, and log retention patterns that are directly relevant when secrets might be pasted, inferred, or echoed back by AI tools.
How to limit retention, reuse, and accidental recovery of secrets
Once a secret has entered the prompt path, the risk does not end with the model response. Logs, cache layers, prompt history, prompt templates, retrieval context, and tool outputs can all become secondary copies of the same value. The control objective is to reduce how many places can retain it, how long it lives there, and who can later recover it.
That means reviewing application logs, conversation transcripts, debugging traces, and retrieval stores for accidental persistence. It also means designing retention rules so secrets are not indexed, copied into analytics pipelines, or reused in future prompts. If a secret has been exposed in a prompt or response, treat the prompt record itself as sensitive until it is cleaned up or discarded.
Where secrets are still required for the task, favour short-lived, scoped credentials over long-lived static values. This does not eliminate prompt risk, but it narrows the blast radius if a value is copied into a visible context. The Guide to the Secret Sprawl Challenge is a strong companion piece for understanding why hardcoded and duplicated secrets keep reappearing across workflows.
For broader operational hardening, Secrets Management Guide and API Key Management Guide both reinforce the same principle: move secrets out of casual text channels, keep them revocable, and reduce the chance that a prompt becomes an unintended distribution path.
Risk and Threat Considerations
secrets in prompts create an exposure path because prompt text is often copied into chat history, telemetry, support tooling, and model-adjacent logs. Even when the model does not retain the secret intentionally, the surrounding system may preserve it long enough for reuse, leakage, or lateral abuse.
Failure mechanism: A user, developer, or automated workflow places a live secret into prompt-visible text, then the value is retained or echoed through logs, cached context, retrieval layers, or downstream outputs where it can be recovered later.
Impact: Exposure can lead to account compromise, unauthorized API use, privilege abuse, or broader secret sprawl across environments and tools. If the secret is still valid, the attacker or unintended recipient may use it immediately.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V14 — Data Protection | Prompt redaction and secret handling are data protection concerns. |
| Recommendation — Prevent sensitive values from entering prompts, logs, and other user-visible text. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Secrets in prompts are a direct secret leakage path. |
| NHI-07 — Long-Lived Secrets | Prompt exposure is worse when secrets are static and reusable. | |
| NHI-10 — Human Use of NHI | People pasting secrets into prompts is a common leakage path. | |
| Recommendation — Remove secrets from prompt-visible text and block disclosure requests. Prefer short-lived credentials and rotate any secret that may enter prompts. Keep humans out of direct secret handling by using safer secret injection patterns. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The topic involves storing, rotating, and protecting credentials and tokens. |
| Recommendation — Store and rotate credentials outside prompts and revoke exposed authenticators. | ||
Practitioner Guidance
What to prioritise: First eliminate prompt paths that carry live secrets at all, then reduce the number of places those prompts are stored or replayed. If a workflow cannot function without sensitive context, move that step behind a service boundary instead of letting the model see the secret directly.
What to verify: Confirm that redaction happens before prompt assembly, that logs do not capture raw secret values, and that tool outputs cannot reintroduce sensitive fields into the conversation. Also verify that retention settings cover prompt history, cache layers, and debugging traces, not just the user-facing chat UI.
Practitioner takeaway: The key decision is whether the model truly needs the secret, because if it does not, the safest control is to keep the secret outside the prompt entirely and let the system pass only a controlled substitute.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org