What Never to Paste Into an AI Coding Tool

Direct answer: Never paste live credentials, private keys, session tokens, or customer secrets into an AI coding tool. Default to synthetic data for customer records, regulated personal data, and production logs. Use real, minimized content only through a formally approved workflow with verified contractual terms, access controls, retention, audit logging, and authorization for that data class.

A coding assistant often asks for the artifact closest to the bug: the environment file, failing request, stack trace, database row, or provider response. Those artifacts are useful precisely because they contain real context. They can also contain credentials that never belong in a prompt or customer data that requires a formally approved processing path.

The inventory in data and secret boundaries in the security guide starts before code review. Decide what the tool may receive before a prompt, repository index, terminal command, or connector expands the context.

The vulnerable pattern: paste the production record

Vulnerable prompt pattern. Every value below is fictional. Do not use real data.

My production request fails. Debug this:

DATABASE_URL=postgres://admin:example-password@db.invalid/app
SESSION_TOKEN=fake-session-token-for-documentation
Customer: Test Person, test@example.invalid
Authorization: Bearer fake-provider-token
Full request and response attached.

Changing the labels to “test” does not make a real pasted value safe. The prompt may travel through the coding product’s backend, a selected model provider, abuse-monitoring systems, workspace history, or an integration. A repository-aware tool may also retrieve nearby files that were not named in the prompt.

Generated troubleshooting advice can make this behavior feel routine. An assistant asks for “the exact config” or “the complete log” because more context improves diagnosis. It does not know which data the organization is allowed to send, how the workspace is configured, or whether the user copied a production artifact.

Classify the input before opening the prompt

Keep live authentication material out of prompts and indexed context under every workflow described here:

• live passwords, API keys, signing keys, private certificates, recovery codes, and database credentials
• access tokens, refresh tokens, session cookies, webhook secrets, and bearer headers

Default to synthetic data for the following categories. Real content may be used only when a formally approved workflow permits the exact data class and minimizes it to the fields required for the task:

• customer secrets, private source received under contract, and unreleased business data
• regulated or sensitive personal data, including health, financial, identity, and precise location records
• unrestricted production logs, database exports, support attachments, and incident artifacts
• complete proprietary repositories when the workspace is not approved for that data class

File names, URLs, stack traces, and metadata can be sensitive too. A presigned URL may grant access. A path may reveal a customer or internal project. An error object may serialize headers or query strings that the visible message omits.

OWASP’s Secrets Management Cheat Sheet recommends inventory, controlled storage, rotation, and careful handling throughout a secret’s lifecycle. Sending a credential to a model is another disclosure path, even if the immediate goal is debugging.

An approved customer-data workflow should name the business purpose, data owner, exact product and workspace, selected provider and model, contractual processing terms, retention, training use, storage region where relevant, access roles, audit records, connector scope, deletion process, and incident owner. Security, privacy, legal, and customer commitments determine who must approve it. Remove fields that the task does not need and prohibit the workflow from receiving live credentials or bearer tokens.

Build the smallest synthetic reproduction

Start by writing the behavior in terms of types and invariants. Replace secrets with placeholders that cannot authenticate. Replace customer records with invented values using reserved domains such as .invalid. Remove unrelated headers and payload fields. Keep only the structure needed to reproduce the failure.

Expected: an authenticated test user can read its own synthetic project.
Observed: the local test route returns 403.

Environment variables present:
DATABASE_URL=<server-only connection string omitted>
SESSION_SECRET=<omitted>

Request fields:
projectId="project-a-test"
actorId="user-a-test"

This prompt preserves the authorization question without exposing the values that make production access possible. If the assistant needs a schema, provide the smallest relevant table definition with synthetic names. If it needs a log, reproduce the error locally and capture only the bounded event fields.

Redaction is fallible. Search the final prompt for token formats, private-key markers, connection strings, email addresses, cookies, authorization headers, signed URLs, and long opaque values. A second reviewer should inspect high-risk prompts. When a synthetic fixture is enough, prefer it over redacting a real record.

Keep the fixture beside the test, not in a shared prompt history, when it will be reused. That gives code review a stable artifact and lets secret scanning inspect the same input before each change. Remove one-off exports after the test and confirm they did not enter shell history, editor backups, or an untracked workspace directory.

For source and environment files, keeping privileged API keys out of frontend code covers repository and deployment boundaries that prompts alone cannot solve.

Verify the exact product and workspace policy

Do not rely on a general statement such as “the vendor does not train on code.” Check the exact product, plan, workspace, selected model, endpoint, privacy setting, retention controls, and enabled integrations. Save the review date because these pages change.

Cursor’s Data Use and Privacy Overview, updated July 15, 2026 at the time of this review, says Privacy Mode prevents Cursor from using customer data for training and describes zero-data-retention agreements with model providers. The same page documents exceptions for abuse detection, notes that requests still pass through Cursor’s backend, and explains that codebase indexing uploads chunks to compute embeddings while storing some embeddings and metadata. That is a vendor-specific current statement, not a promise about every coding tool or every future configuration.

Cursor’s security page, updated April 24, 2026, says Privacy Mode can be set by a user or team administrator and points to separate client, agent, and governance controls. A team setting can help, but it does not turn a live credential into acceptable prompt content.

OpenAI’s current API data-control documentation says API data is not used for training unless the customer opts in. It also describes default abuse-monitoring retention, eligibility requirements for modified or zero data retention, and endpoint-specific application-state behavior. Those API terms should not be generalized to ChatGPT, a third-party editor, or a tool that sends requests through its own backend.

Connected context is larger than the text box

Repository indexing can retrieve files related to the prompt. An agent may read terminal output, issue text, documentation, browser content, or files returned by an MCP server. A connector can give the model access to data that was never pasted manually.

Map each context source and its permissions. Exclude secret directories and generated production artifacts from indexing where the product supports it. Use a dedicated agent identity with read access only to approved repositories and test systems. Require separate approval for tools that read production logs, databases, tickets, or cloud consoles.

Ignore files and privacy settings reduce exposure, but they are not proof that data never left the device. A tool can receive content through a terminal, pasted excerpt, open editor buffer, connector, or retrieved dependency. Test the actual workflow with harmless canary files and inspect the documented context controls.

If a secret was pasted

Treat the value as disclosed. Stop using it, revoke or rotate it through the provider, replace dependent configuration, and review access logs for unexpected use. Remove the secret from prompt history or workspace records where the product supports deletion, but do not assume deletion invalidates copies or prior processing.

Record which product, workspace, model, integration, and account received the value. Follow the organization’s incident process and contractual notification rules. The full recovery workflow belongs in a credential-exposure plan; rotating first is more useful than debating whether the interface probably retained the prompt.

The browser-local secret exposure scanner can inspect selected text files before you paste or upload them. It does not send those files to LyraShield AI. It also cannot inspect your clipboard history, tool configuration, remote workspace, repository history, or connected context, and a clean result is not proof that the text contains no sensitive data.

Sources

• OWASP Secrets Management Cheat Sheet
• Cursor Data Use and Privacy Overview
• Cursor Security
• OpenAI API data controls
• NIST Privacy Framework