A customer record left in a prompt

A prompt can look temporary while behaving like a durable record. It may be stored in local history, forwarded through an API, included in logs, copied into a support ticket, or repeated in a later conversation. The safest habit is to compare every piece of context you want to send with the smallest version that still lets the model do useful work.

This matters when using a tool such as Claude Code, an OpenAI SDK, or Vana API. Vana API provides one OpenAI-compatible endpoint and also accepts the Anthropic Messages and Gemini native protocols, so the same prompt can move through different clients and integrations. The protocol may change, but the privacy decision stays the same: do not send information that the task does not require.

§ Useful context beside unnecessary exposure

• Usually useful: “The checkout service returns HTTP 403 after a successful payment.” Keep out: the customer’s full name, email address, billing address, and complete payment response when none of them affects the diagnosis.
• Usually useful: a short, redacted log showing the timestamp, endpoint, status code, and relevant error. Keep out: authorization headers, cookies, session identifiers, access tokens, and unfiltered request bodies.
• Usually useful: a small code sample with representative variable names. Keep out: production configuration files, private repository URLs, deployment credentials, and copied environment files.
• Usually useful: a synthetic example of a user profile or order. Keep out: a real person’s identity data, government identifier, health information, financial details, or private messages.

§ Identification beside anonymization

Replacing a name with “Alice” is not always enough. A rare job title, exact date, small town, incident time, and account history can identify someone when combined. Compare the full record with a reduced description that preserves only what the model needs.

• Full record: “Mara Patel, account 184729, born 12 March 1988, reported the issue from 14 Kingsley Road at 09:12.”
• Reduced record: “An adult customer reported the issue from a residential address during the morning.”

Keep exact values only when they are part of the problem. If the task is date parsing, use a date without a person’s identity. If the task is validating an address form, use a fabricated address. If the task is debugging authorization, preserve the token shape but replace the token itself.

§ Secrets beside safe placeholders

A model can explain how to use an API key without seeing a valid key. It can review authentication code with a placeholder such as API_KEY_REDACTED. It can reason about a database connection using a fake hostname and a schema excerpt.

• Send: Authorization: Bearer REDACTED, a short schema, and the error returned by the service.
• Do not send: a live bearer token, private key, webhook secret, password, signing key, or recovery code.

Redaction should happen before the request reaches the model provider. Do not paste a secret and rely on the model to remove it later. If a credential has already been exposed, revoke or rotate it, then inspect logs and prompt history for copies.

§ Relevant history beside permanent baggage

More context is not automatically better. Include the decisions, constraints, and recent output that explain the current task. Remove old conversation turns, unrelated customer cases, internal debates, and personal details that no longer affect the answer. Shorter prompts are easier to review and reduce accidental disclosure.

For repeated workflows, create a redaction step before your application calls Vana API. Allowlist the fields the model needs rather than trying to block every sensitive field after collection. Keep separate storage for private source records and the sanitized prompt, with access controls and retention rules for both.

§ A final comparison before sending

• Needed for the answer: include it, at the lowest useful level of detail.
• Helpful but replaceable: anonymize it, generalize it, or create a synthetic equivalent.
• Not needed: remove it.
• Secret or regulated: keep it out unless a documented, approved workflow specifically requires it.

Create a Vana API account when you are ready to use the endpoint, then make privacy review part of the code path rather than an afterthought. Per-token billing does not change the rule: every token should earn its place in the prompt.