What happens when an API key goes into an AI coding prompt?

The honest answer: it is already gone

Sending the prompt to the provider is the tool's entire job, and it does that first. Telemetry about the prompt is emitted alongside or just after. Anything watching from the endpoint is watching a departure, not standing in a doorway.

Actually preventing it would mean sitting between the editor and the provider and refusing the request: a proxy every engineer's traffic is forced through, enforced by MDM, with a latency budget and an outage story. That is a different product with a different cost. Synopt is not that and does not pretend to be. Describing after-the-fact detection as prevention is the most common piece of dishonesty in this category, and it is worth checking every vendor against, including this one.

Where the key ends up

One paste, several copies. Before you decide what to do, work out how many of these apply.

• The model provider has it, in whatever request logging their terms describe for that account and plan.
• The tool's local transcript on that machine probably has it, in a file that syncs, backs up, or gets attached to a bug report.
• Shell history has it, if the paste came from a command line.
• Your own observability stack may now have it, and this is the one people miss.

Sit with that last one. If you turned on prompt logging in your OpenTelemetry pipeline to get visibility, you have copied the secret into a log store that has broader read access than the original credential, longer retention than the incident, and an export path into a data warehouse. Visibility bought that way can cost more than it returns.

What should you do in the first hour?

• Rotate the credential. Now, before the investigation. This is the only step that changes the outcome, and every minute you spend deciding whether it was really exposed is a minute the old key still works.
• Establish blast radius: what did that key authorise, against which environment, and how long was it live?
• Read the provider's retention terms for that specific account and plan, rather than the marketing page.
• Sweep the other copies: local transcripts, shell history, any log pipeline where prompt content is enabled.
• Only then ask how it got there. In practice it is almost never someone being cavalier with a key. It is someone pasting a stack trace, a .env file or a failing curl command, and the credential came along for the ride.

What on-device detection can actually tell you

Synopt's agent scans each event before it is buffered, redacts the matched substring in place, and records a finding that carries no content: a type, a severity, and which field it was in. The value never reaches the buffer, never crosses the network, and is not sitting in the dashboard for whoever has access to read.

These are the built-in patterns. The agent is Apache-2.0, so this table is not a claim you have to take on trust: it is one regex list in one file your security team can read before the binary goes near anyone's laptop.

What it will not catch

A detection list is only useful next to its complement, so here is the complement.

• PII. Not shipped. The scanner finds credentials and tokens, full stop. If a customer's email address goes into a prompt, nothing here notices.
• Proprietary code and internal identifiers. Also not shipped.
• A password that does not look like a key. An assignment matches; a memorable string in the middle of a sentence does not.
• Anything the tool did not emit. This reads telemetry, not your disk. A secret in a file the model read but never quoted back is not in scope.
• A motivated insider. These are public patterns, in an open-source binary, running on the machine of the person you would be trying to catch. It is a control against accidents, and accidents are the actual failure mode.

To scan a prompt, something has to see the prompt

This is the trade at the centre of the design, and it deserves stating rather than glossing. Claude Code redacts prompt content from its telemetry by default.

Prompt content. Redacted by default. Set `OTEL_LOG_USER_PROMPTS=1` to include it

With prompt content redacted, a secret pasted into a prompt is undetectable at the endpoint: there is nothing to scan. So the agent opts that emission in, and only when its own receiver is bound to loopback. The prompt text then travels to a process on the same machine, is scanned in memory, and is discarded. Storing prompt text is a separate org setting, off by default, whose default fails closed: absent, invalid or mistyped all resolve to storing nothing.

If the receiver is bound to something other than loopback, which is an explicit opt-in for unusual setups, prompt emission stays off. Raw prompts crossing a plaintext network hop so that they can be scanned would be a worse outcome than not scanning them. That trade lives in the code rather than in a settings page, which is the right place for it.

Nothing is going to page you

Alerting is not shipped. Findings appear in the dashboard's security view and in a quarterly data-exposure report, and nothing sends an email, a Slack message or a webhook. If your incident process depends on being told, this does not do that yet. Better you read it here than find out in an incident.