Before pasting a production error into a prompt

A production request fails. You copy the error, add a question, and prepare to send it to an AI assistant. Pause at that boundary. The useful material is usually the failure pattern, not the customer's identity or the credential beside it. Work through these steps before sending a debugging prompt, support transcript, or document excerpt.

§ Step 1: Define the smallest useful question

Write the task before attaching evidence: explain a timeout, inspect a parser, or summarize a complaint. Then select only the material needed for that task. Prefer one failing function over a repository dump, and one representative event over a complete request history.

For a timeout investigation, begin with the status code, elapsed time, retry behavior, and a sanitized error message. Add context incrementally rather than including everything in the first request.

§ Step 2: Remove anything that grants access

Keep credentials out of every prompt field, including system instructions. A system prompt is not a secret store; prompt leakage can expose information placed there. Telling the model not to reveal a credential is not a substitute for withholding it. ([platform.claude.com](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-prompt-leak?utm_source=openai))

• Authentication: API keys, passwords, bearer tokens, session cookies, and authorization headers.
• Infrastructure: private keys, database connection strings containing credentials, and cloud access credentials.
• Temporary access: signed download URLs, password-reset links, recovery codes, and one-time passwords.

Replace values with explicit placeholders such as REDACTED_API_KEY. Preserve the header name or configuration structure when it matters, but remove the working value. For authentication debugging, send the error and a sanitized request shape, not the credential itself.

§ Step 3: Replace identity while preserving relationships

Remove names, email addresses, phone numbers, street addresses, account identifiers, and unnecessary health or financial details. Use consistent placeholders: CUSTOMER_A should remain CUSTOMER_A throughout the example.

For a billing question, try: CUSTOMER_A reports two charges for ORDER_A on consecutive days. Keep exact amounts or timestamps only when the calculation or sequence requires them. Otherwise, use a synthetic example and label it clearly. Do not describe a lightly edited real record as anonymous.

§ Step 4: Inspect context you did not type

Review attachments, retrieved documents, tool results, and previous conversation turns before sending. In a coding assistant, inspect the context and permission settings rather than assuming the visible question is the entire request. Anthropic's security guidance recommends limiting access to sensitive data and treating instructions inside external content as untrusted. ([platform.claude.com](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/mitigate-jailbreaks?trk=article-ssr-frontend-pulse_little-text-block&utm_source=openai))

Exclude environment files, credential directories, database exports, and unrelated customer records from the assistant's permitted context. Do not rely on a prompt saying 'ignore secrets' while leaving those files accessible.

§ Step 5: Check the request path

Vana API provides one endpoint for supported model APIs. Use that convenience to simplify configuration, not as evidence about data retention. ([vanaapi.com](https://vanaapi.com/)) Before sending confidential material, check the applicable policies and settings for your client, Vana API, and the selected upstream provider. Provider logging and retention controls can be service-specific; Google's Gemini API documentation, for example, distinguishes abuse-monitoring logging from other data-handling controls. ([ai.google.dev](https://ai.google.dev/gemini-api/docs/zdr?hl=en&utm_source=openai))

If you are setting up this workflow, create a Vana API account and test it first with synthetic requests. Keep real confidential material out until your review is complete.

§ Step 6: Check what gets recorded afterward

Inspect application logs, tracing tools, error reports, and saved conversations. Where request logging is enabled, check whether it captures full prompts, responses, or earlier turns. Gemini API's logging documentation explicitly describes inspecting these contents. ([ai.google.dev](https://ai.google.dev/gemini-api/docs/logs-datasets?utm_source=openai)) Configure redaction before logging and avoid recording authorization headers or raw request bodies unnecessarily.

Finish with a repeatable check: Is this detail necessary? Is it authorized for this destination? Has it been sanitized before transmission and logging? If any answer is unclear, reduce the prompt or use synthetic data. The goal is enough context to solve the problem without sending the surrounding private record.