Secrets management for AI

What it does

It keeps credentials out of the places where models, users and attackers can read them, and limits the value of any that leak. Security owns the standard and the scanning; each system owner is accountable for the credentials the system uses. It applies from the first experiment onward.

How to implement it

• Store provider keys, tool tokens and data source credentials in a managed vault.
• Inject them into the calling code at run time; never place them in the model's context.
• Issue separate credentials per system and per environment, with the least scope that works.
• Set expiry and rotate on a schedule and on any suspected exposure.
• Scan repositories, notebooks, prompts and logs for secrets continuously.
• Redact credentials from conversation logs and agent memory.

Evidence it operates

Design: a standard naming the vault and the prohibited locations. Operation: scan results with findings closed; an inventory of AI credentials with owner, scope and last rotation; provider logs showing use only from expected systems.

Where it fits

Established at design and maintained throughout. It is the primary control for exposed AI credentials and secrets and supports least-privilege agent identity.

Limits

It protects credentials at rest and in configuration. A tool that returns a secret in its output, or a user who pastes one into a conversation, puts it back in context. Short-lived credentials reduce that exposure and do not remove it. A leaked provider key should be assumed used: revoke it, review the provider's usage logs for the period, and check which stored conversations or tuned models it could reach.