Secrets on the Big Screen
The stack trace explained the connection failure. It also supplied everything needed to connect.
What it is
Secrets on the Big Screen is the exposure of credentials or sensitive data through AI prompts, attached files, tool output, or shared conversations. Debugging context crosses a boundary the team did not intend to cross. The assistant gives a helpful answer; the same exchange may have disclosed a database password.
The destination matters. A local model, an approved hosted service, and an unknown plugin have different data paths and controls. A prompt is not automatically public, and approved use of customer data is not automatically an incident. The question is whether this information went to a recipient, storage location, or audience authorized to receive it.
A debugging example
In an illustrative incident, a failed database command prints a connection URL containing a password. An agent includes the terminal output in a hosted debugging service approved for source code but not production credentials. The developer never pasted the credential deliberately, but the output carried it to an unauthorized destination. Keeping the password out of the initial prompt would not have prevented it.
Preserve the actual error code, relevant TLS settings, and sequence of events while removing the password locally. If identifiers are sensitive, replace them consistently so repeated requests can still be correlated. Inventing a cleaner error message can erase the clue being investigated. Sending the original to the remote assistant with “please redact this” transmits it before the redaction happens.
Why it’s dangerous
A credential grants authority to whoever can use it. Its risk depends on scope, lifetime, network restrictions, and who can retrieve it after disclosure. Customer data creates a different problem: replacing a token does not retract a record already shared. The team needs to establish what was sent and who received it, then follow its incident process.
Do not infer a vendor’s retention, training, or sharing behavior from the chat interface. Check the actual product, account configuration, agreement, and connected tools. A no-training commitment alone does not answer how long a conversation is retained or who can open a share link. Have the security or data owner determine any reporting obligations from the actual exposure.
How to prevent it
Reduce sensitive data at its source: omit credentials from logs, use sanitized fixtures, and give the agent only the files and accounts the task needs. Where practical, let a constrained tool perform an authorized operation without returning its credential to the model. For database diagnosis, that might mean a read-only query tool scoped to approved views, with bounded and redacted output, rather than a shell carrying the production password. A secret stored outside the repository still leaks if a broadly permitted shell can read and print it.
Scan and redact locally before transmission. Check which routes a scanner actually covers: pasted text, attachments, terminal output, or tool responses. Test each supported route with fake canary values and check that they are blocked before any external request. If the host offers no interception point for tool output, a paste scanner cannot protect that route; prevent sensitive output at the command or service that produces it. Pattern matching still misses unfamiliar secrets and personal data whose sensitivity depends on context.
If the secret has already left
- Invalidate the exposed authority. Revoke or rotate the credential promptly, coordinating replacement for services that use it. Check whether active sessions or derived credentials also need invalidation. GitHub’s secret-removal guidance likewise puts revocation or rotation ahead of repository cleanup. Deleting visible text is not a substitute.
- Establish the exposure. Record when it happened, which service and audience received it, and what the credential could access. Review available access logs and involve the security or data owner. Preserve necessary evidence without copying the secret into the incident ticket. Request removal through the recipient’s supported process, without assuming deletion undoes the exposure.
- Repair the route that leaked it. In the example, redact the connection URL before logging and constrain the agent’s credential access. Prefer short-lived, narrowly scoped credentials where supported. Give someone ownership of the redaction rules and tool permissions as integrations change; a forgotten scanner can become one more reassuring badge.