Secrets Detection in Prompts Needs a Block Before the Provider Call

A secret pasted into a prompt becomes provider-bound data as soon as the HTTPS request leaves the application. Detection after the response helps an investigation. Detection before the connection can stop the exposure.

That timing matters. A scanner placed only in stored logs can identify a leaked credential, but the provider has already received the request by then. Pre-request enforcement gives the application one point where it can inspect the complete outbound payload and stop the call before transmission.

TL;DR

• Scan prompt text and attachments. Also scan tool arguments and decoded fields before the LLM request leaves.
• Combine known token patterns with entropy. Add custom organization signatures and allowlists.
• Block the request and rotate any credential that may already have crossed another route.

The scan must cover more than the visible chat box. An application may assemble one provider request from a user's text and an uploaded document. Retrieved passages, system instructions, and a tool result may also enter the request, so policy needs to inspect the final outbound representation rather than one interface field.

Known patterns provide the first layer

GitHub's secret scanning documentation describes detection for supported secret patterns and partner tokens across repository content and related surfaces. The supported-pattern list shows why the detector needs provider-specific signatures rather than one generic API-key regex.

Prompt traffic adds formats that source scanning may never see. These include chat text and pasted terminal output. Uploaded files, JSON tool arguments, and retrieved context also need inspection. Normalize those fields and preserve boundaries so the detector can report where the match occurred.

Location changes the response. A match in a user message may need different handling from the same match inside retrieved context because the caller can correct one directly, while the other points to a source that may feed many later requests. The audit record should retain that distinction without storing the secret itself.

A provider-specific signature also narrows the next step. The team can route a matched token to the system responsible for that credential class instead of sending every alert through one undifferentiated queue. That makes the block useful to the person who has to contain the exposure.

Entropy and custom formats close gaps

Internal database passwords and signed URLs may lack a public pattern. The same applies to service tokens and legacy keys. Add organization-specific prefixes and checksums where teams control the format. Entropy can flag random-looking strings, but it also catches hashes and identifiers. Allowlists should be narrow and tied to context. Review each entry against the field and route where it is permitted.

At a desk, the dangerous string often looks like one grey line between 80 lines of terminal output. Engineers paste the whole block because the error sits at the bottom. My opinion is that relying on training to prevent that paste has already conceded the incident.

The detector needs enough context to separate expected identifiers from credentials without turning the allowlist into a bypass. Scope an exception to the smallest stable condition, such as a known value in a defined field, then record which rule allowed it. A broad substring exception can suppress the exact match the control was installed to catch.

Custom formats need an owner. When a team changes a prefix or checksum, or changes the token length, the corresponding detector should change with it and be tested against both valid examples and nearby non-secret strings. Otherwise, the policy can keep running while its useful coverage quietly shrinks.

Encodings and fragments matter

Test URL encoding and base64. Also test Unicode substitutions, multiline private keys, and secrets split across JSON fields. Decoding every arbitrary blob can create cost and denial-of-service risk, so set size limits and supported transforms. Record which transform produced the match.

Order matters here. Normalize the supported representation and apply bounded decoding. Then scan the resulting value while retaining a pointer to the original field. If a transform reaches its size or depth limit, the policy should produce an explicit result rather than treating the uninspected value as clean.

Fragments require request-level inspection. One JSON field may contain a token prefix while another contains the remaining characters, and scanning each value in isolation can miss the combined secret. Reassembly should follow known field semantics and firm limits so ordinary structured data does not trigger unbounded combinations.

The LLM DLP guide covers prompt classification. The prompt-injection guide covers hostile instructions; secrets detection solves a different content problem and should keep its own reason codes.

Separate reason codes help responders distinguish a credential match from an instruction-policy violation. They also let the application return the right safe message without exposing the matched value or implying that every blocked prompt failed for the same reason.

Blocking starts the response

A blocked prompt should return a clear message without echoing the full secret. The audit event can contain the detector type and secret class. It can also record the field location, caller, route, and action, along with a one-way fingerprint for correlation. Security operations should determine whether the credential appeared in earlier provider calls or traces. Tickets and chat systems should also be checked.

The fingerprint supports correlation without placing another copy of the credential in the audit stream. Responders can use it to find repeated detections across routes, then check the systems that handled those requests according to their retention and access controls.

Rotate a credential when exposure is plausible. A gateway block protects the current route. It cannot revoke the secret or remove copies already stored elsewhere.

The block is therefore the start of containment. The response path needs a clear owner who can verify prior use and disable the affected credential. That owner must also issue a replacement and confirm that dependent applications received the new value. The policy event should provide enough location and route detail for that work without reproducing the sensitive string.

DeepInspect

DeepInspect can inspect authenticated HTTP AI requests and apply secret and data-class policy. It can block or transform content before forwarding, then record the policy decision. Credential inventories and revocation remain responsibilities of the enterprise secret-management system. That system also owns rotation and incident review.

This division keeps enforcement close to the provider-bound request while leaving credential lifecycle work with the system that owns it. The audit decision can identify the caller and route. It can also identify the field and detector that triggered the block, giving responders a concrete starting point for containment.

Book a technical deep dive at deepinspect.ai.