AI agents need credentials — API keys, model provider tokens, database passwords — but the way those secrets are supplied determines whether they are secure or a liability. The safest pattern is to keep secrets out of agent code, prompts, and configuration files entirely, and instead route them through a managed secrets layer that supplies credentials at runtime, logs access, and supports rotation without redeployment. This is one of the foundational practices covered in AI Agent Security: The Complete Guide.

Why Hardcoded Secrets Are So Dangerous for Agents

The most common way a secret ends up exposed is the simplest: a developer embeds a key directly into the configuration, the prompt template, or the source code of an agent. It works immediately, and the problem is invisible until the moment it is not.

The risks compound in an agentic context for several reasons. Agents often log their inputs and outputs for tracing. A system prompt that contains an API key will surface that key in any log aggregation system the agent reports to. A credential that lives in memory between calls can be exfiltrated by prompt injection — an adversarial instruction embedded in retrieved content that persuades the agent to repeat back what it knows. Agents also proliferate: once a working configuration is shared across a team, the embedded secret is in version control, CI pipelines, and every developer's local checkout.

The fundamental issue is that hardcoded secrets treat credentials as static configuration. Secrets management inverts this: credentials are stored separately, protected at rest, retrieved on demand, and never written into artifact files that get copied around.

The Anatomy of a Secrets Management Approach

A secrets management layer for AI agents typically has four concerns: storage, delivery, access control, and rotation.

Storage means the secret is kept in one authoritative location — a managed vault, an encrypted database column, or a cloud secrets service — and encrypted at rest using a key management system. The raw secret value is never written into source control, environment configuration files committed to a repository, or application logs. Only a hint or reference (such as the last four characters of a key) is ever displayed in interfaces that operators see.

Delivery means the agent receives the secret value only at the moment it is needed, through a controlled interface. Rather than having the secret baked into the agent's environment at startup, the control plane resolves and supplies it in-band when the agent is about to make a call that requires it. The secret is not present in the agent process any longer than necessary.

Access control means who and what can retrieve a given secret. Not every agent in an organisation should be able to retrieve every credential. The access policy is expressed at the resource level: this agent, running in this context, may retrieve the key associated with this provider configuration. Attempts outside that scope are denied and logged.

Rotation means the secret can be changed without breaking the agent. If the secret lives in a managed layer rather than baked into the agent's deployment, updating the stored value is sufficient — no redeployment, no configuration patch, no grep-and-replace across repositories. Agents that retrieve credentials at runtime automatically use the new value on the next call.

Bring-Your-Own-Key: Controlling Which Provider Your Agents Use

One specific pattern that arises in AI-heavy systems is the need to supply model provider credentials on a per-organisation basis. Different tenants may have contracts with different providers, prefer different models, or want to use their own API keys for cost attribution and billing purposes, rather than consuming shared platform capacity.

The design for this — often called bring-your-own-key or BYOK — involves the organisation registering a provider configuration (provider name, model, and optionally a custom endpoint) and separately storing an API key against it. The key is stored encrypted; the interface never returns the raw value, only a last-few-characters hint so the operator can confirm which key is active without being able to extract it.

At runtime, the platform resolves the organisation's configuration, decrypts the key in-band, and uses it for the outbound call. The agent code itself does not hold the key; it delegates to the platform. The key can be rotated by updating the stored value in the management interface, and the platform's audit log records which configuration was used for each call, attributable to the agent and workflow that triggered it.

Secrets in Prompts: The Input Surface

Beyond provider credentials, agents carry another category of secret: information that gets dynamically inserted into prompts. This might be a user's account number retrieved from a database, a session token passed through a workflow, or a connection password resolved at dispatch time.

The risk is that anything in a prompt is text. It can be logged, repeated back by the model, included in a retrieved context window, or leaked by prompt injection. The mitigations are:

Redaction before logging. Any system that logs prompts should pass them through a redaction filter that recognises common secret patterns (key formats, token structures, credential-shaped strings) and replaces them before the log is written. This is analogous to how application logging frameworks handle password fields in database connection strings.

Minimise what you pass in. Rather than resolving and inserting a full credential into the prompt, consider whether the agent actually needs the raw value or whether it can call a tool that holds the credential internally. If the agent invokes a tool that makes the authenticated call, the credential never enters the prompt at all.

Content guardrails. A guardrail layer that inspects prompt content and model responses can catch patterns that look like secrets and block or redact them before they propagate. This is a second-order control, not a substitute for keeping secrets out of prompts in the first place, but it catches what slips through.

Access Control: Scoping Secrets to the Agents That Need Them

Secrets should follow the principle of least privilege. In a multi-agent environment, not every agent needs every credential. Access control on the secrets layer means that:

  • A credential stored for one team's LLM configuration is not retrievable by agents owned by a different team.
  • An agent with read-only analysis responsibilities cannot retrieve write-capable database credentials even if those credentials exist in the same organisation's vault.
  • Cross-organisation agent sharing does not carry implied access to the source organisation's secrets; the receiving organisation must supply its own credentials under its own policy.

Enforcing this requires that the secrets layer knows the identity of the requesting agent. This circles back to agent-native identity: if an agent is authenticated as a named, registered principal, the secrets management layer can evaluate access policy against that principal. If the agent is anonymous or running under a shared service account, there is no basis for fine-grained access control. See AI Agent Identity: Why Agents Need Their Own Credentials for a deeper treatment of agent identity design.

Rotation Without Disruption

Credential rotation is often deferred because it seems disruptive. If the secret is hardcoded into ten places, changing it requires finding all ten places first and then coordinating the change to avoid a gap during which agents have the old key and the provider has already revoked it.

With centralised secrets management, rotation is a targeted operation: update the stored value, and all agents that resolve the credential at runtime pick up the new value on their next call. Agents currently mid-task will complete using the old value; future calls use the new one. The window of exposure for a compromised key is the time from detection to rotation, measured in minutes rather than days.

For long-lived credentials, periodic rotation should be routine, not triggered only by incidents. A defined rotation schedule treats key hygiene as normal maintenance rather than an emergency response. This principle applies equally to the bring-your-own-key pattern described in Bring Your Own Key: Managing LLM Configurations.

Praesidia is designed around this model: API keys are stored encrypted, retrieved in-band, and exposed only as masked hints in the management interface. Rotation is a single update action, and audit events capture every key lifecycle operation — creation, update, removal, and use — so the history of a credential is legible without the value itself being visible.

Common questions

Should agents ever have direct access to the raw secret value?

As rarely as possible. If the agent can delegate the authenticated call to a platform component or tool that holds the credential internally, the agent itself never needs the raw value. When it does need the raw value — for example, to call an SDK that requires it — it should receive it through a controlled interface at the moment of use, not carry it in its context window across the entire session.

What is the difference between environment variables and proper secrets management?

Environment variables are an improvement over hardcoded values, but have real limitations: they are visible to every process in the environment, accumulate in CI pipeline secrets stores and container image build arguments, and rotating them requires redeployment. A dedicated secrets management layer provides encryption at rest, audit logging of every access, fine-grained access control, and rotation without redeployment — capabilities that environment variables do not offer at scale.

How does secrets management interact with the model provider credential problem specifically?

The model provider credential is one of the highest-value secrets in an AI system — it unlocks potentially expensive compute and data access at the provider. Treating it as a first-class managed secret — stored encrypted, scoped to the organisation, rotated on schedule, and accessed only in-band during inference calls — reduces the risk that a leaked key drives unbounded spend or data extraction. See bring-your-own-key: managing LLM configurations for how provider configurations and bring-your-own-key work in practice.

What happens if a secret is accidentally included in an agent's output? Output guardrails are the last line of defence. A guardrail layer that inspects model responses for patterns that resemble secrets can redact or block the output before it reaches the caller. This does not substitute for keeping secrets out of prompts in the first place, but it catches what slips through. For how output inspection fits into a broader guardrail strategy, see designing guardrails: block, redact, or warn?. For how to prevent sensitive data reaching prompts at all, see PII detection and redaction in AI pipelines.