Secrets
Runtime secret injection for AI workloads, with prompt and trace redaction and short-lived session credentials.
AI workloads use the existing secrets-management discipline and add two common exposure paths: prompts and traces.
Existing controls
Keep secrets out of source and container images. Inject them at runtime from a secret store, scope them to the workload identity, and prefer short-lived credentials. Rotation should not require an application change window.
Apply these controls before adding AI-specific handling.
Prompt and trace exposure
People may paste credentials into prompts while debugging a failed API call, especially when they include a complete request with headers. The credential can then reach provider logs, prompt logs, conversation history, and traces.
Agent traces capture tool calls and their arguments. An authenticating tool call can put the credential in a trace unless the collector redacts it before storage.
Detect known credential formats at the gateway and trace collector, redact before storage, and alert the owning team. Use each detection to fix the workflow that exposed the credential.
Agents hold credentials for a long time
A web request holds a credential for milliseconds. An agent session holds one for the length of the session, in a process that is also executing generated code and reading untrusted content. The longer lifetime increases exposure to that code and input.
Use session credentials with the smallest practical scope and lifetime:
- Limit the credential to the operations required by the task.
- Issue it at session start and expire it at session end. A longer session can request a replacement.
- For production operations, let a broker hold the credential and perform the privileged call. The agent receives the result and cannot read the key.
Brokered access requires more implementation work and reduces credential exposure in production workflows.
Credentials in chat history
Scan model chat history for credential formats. Apply the same control to ticket comments, incident channels, and pull request descriptions before they enter a retrieval index.
Scan indexed and logged content, then rotate a credential when detection fires. Record the earliest affected copy so incident review can establish the exposure window.
A public ClickHouse instance with a million log lines and the API keys
Wiz Research found two open ports on DeepSeek infrastructure leading to a ClickHouse database with no authentication. It held over a million log entries including chat history, API keys, and backend service detail, queryable by anyone over HTTP.
The skipped letter. Run. Data plane and control plane provisioned without the guardrails the rest of the stack gets. For the enterprise consuming that endpoint the skipped letter is Secure: nobody asked where the prompts land, in what form, or for how long.
Wiz Research: exposed DeepSeek database leaking sensitive information
Questions to ask your vendor, or your own team
- How does an AI workload get its model credential at runtime, and how long does a value set through an environment variable remain unchanged?
- What scans prompts for credential patterns before they are stored?
- Are tool-call arguments redacted in traces, and who verified that?
- For a production-touching agent: does it hold the credential, or does a broker hold it?
- If a credential leaked into chat history six months ago, would you know?
- Does your secret rotation runbook include the model provider keys?