AI Secrets Management: Protecting API Keys, System Prompts, and Model Credentials in Production

Published · 23 min read
defense-patternscredential-managementsecrets-managementleast-privilegeagent-securitymonitoringincident-responseapi-securitysystem-promptcicd

Every production AI deployment carries secrets. At minimum: an API key for the model provider. Usually more — system prompts that encode proprietary business logic, model endpoint URLs, vector database credentials, fine-tuned model weights, and the OAuth delegation tokens that let your agents act on behalf of users.

Teams that build web applications have spent a decade developing muscle memory around secrets hygiene: don’t commit .env files, rotate database passwords, use a secrets manager for production. That hygiene rarely transfers cleanly to AI deployments. The credential types are different, the blast radius is different, and the failure modes are different.

This post covers each credential type in detail — what makes it sensitive, how to store and rotate it properly, and what a compromise looks like — then closes with a deployment checklist you can apply immediately.

Why AI Credentials Are Different

Before diving into specific credential types, it’s worth understanding why the standard application-security playbook doesn’t map cleanly onto AI systems.

Blast radius is unusually large. A compromised model provider API key doesn’t just unlock a single application function. Depending on the key’s scope, an attacker can run inference at scale (with cost accruing to your account), access your fine-tuned models, enumerate your stored prompts, trigger training jobs, or exfiltrate structured output from model calls that include sensitive system context. Major providers charge by token; a single compromised key can generate tens of thousands of dollars in fraudulent charges in hours — before any data theft has occurred.

Credentials encode intellectual property, not just access. A database password is a bearer token — it proves identity but carries no information itself. A system prompt, by contrast, is the product. It encodes the persona, the policies, the constraints, and often the competitive differentiator of an AI application. Teams that harden their database passwords but paste system prompts directly into client-side JavaScript code have the threat model exactly backwards.

The credential distribution surface is novel. Traditional application credentials pass from secrets manager to the runtime environment, and the application code calls the downstream service directly. In agentic AI deployments, credentials often flow through additional hops: from secrets manager to orchestrator, from orchestrator to sub-agents, from sub-agents into tool calls. Each hop is a potential exposure point. An agent that reads a configuration file to load its own credentials places those credentials in the model’s context window, where a prompt injection attack can target them.

Rotation is harder. API key rotation for traditional services is painful but understood. For model APIs, it’s compounded by the fact that fine-tuned models may be scoped to specific key prefixes, that organizations frequently use the same key across multiple integrations, and that many AI applications have no rotation-aware credential refresh mechanism at all — the key is hardcoded at build time and rotation requires a redeployment.

System Prompts Are Secrets

System prompts occupy an unusual position in the secrets taxonomy: they are both configuration (they shape the model’s behavior) and secrets (they often contain proprietary logic that warrants protection). Most teams handle them as the former and ignore the latter.

What system prompts reveal

A system prompt for a commercial AI product commonly contains:

  • The application’s core product logic expressed as natural language instructions
  • Business rules, compliance constraints, and decision criteria that are otherwise undocumented
  • Data about the application’s architecture (database schemas referenced by name, API endpoint patterns, internal service names)
  • Information that would assist prompt injection attacks — the exact instruction boundaries that an attacker can try to override

System prompt extraction is an active attack technique — adversarial prompting can coax a model into repeating its instructions, and client-side exposure makes it even simpler. Even without a successful extraction attack, client-side exposure is endemic: system prompts delivered as part of client-rendered JavaScript bundles are trivially readable by anyone who opens their browser’s developer tools. This is the single most common system prompt exposure pattern, and it requires no attack sophistication at all.

Storage patterns

Do not deliver system prompts from client-side code. The model call should originate from a server-side component (a backend API, an edge function, a serverless function) that retrieves the system prompt from a controlled source and assembles the full request before it leaves your infrastructure. The client never sees the prompt.

Store system prompts under access control. The appropriate storage depends on your sensitivity assessment:

  • For prompts that are moderately sensitive (business logic, not trade secrets), a dedicated configuration store with access logging (e.g., a separate configuration service, or a secrets manager entry with an audit trail) provides adequate protection.
  • For prompts that encode significant IP, encrypted storage with envelope encryption (where the data encryption key is itself managed by a hardware-backed KMS) adds a layer that survives secrets manager access log gaps.
  • For the highest-sensitivity prompts (e.g., a prompt used in a legal or financial compliance context where the reasoning logic is itself a regulated artifact), treat the prompt as you would a private key: version-controlled in an encrypted vault, with change approval workflows and an immutable audit log.

Implement versioning and change control. System prompts are production configuration that affects application behavior. Changes should be tracked, reviewed, and attributable to a specific author with a business justification. An untracked prompt change that causes a security regression is hard to detect and hard to roll back. At minimum, store prompts in a version-controlled system and require human approval for changes that affect security-relevant behaviors (e.g., instructions about what data the model can or cannot access).

Treat prompt leakage as a security incident. If you discover that a system prompt has been extracted or exposed, the response should mirror your response to any secrets exposure: assess what the prompt revealed, consider whether that information changes the risk posture of your application (if the prompt described internal system architecture, that’s now attacker intelligence), and update the prompt — not just rotate it, because a rotated prompt with the same logic is still disclosed.

Model API Key Hygiene

Model provider API keys are the credentials most teams think about first, and yet common mismanagement patterns persist.

Anti-patterns to eliminate

Committed to version control. Git history is permanent and widely accessible. An API key committed to a public repository — even if immediately deleted — has been indexed by credential harvesting tools and is effectively compromised. Private repositories offer marginal protection: former employees, CI/CD systems, and repository mirrors all create exposure paths. Never commit API keys. Use pre-commit hooks and GitHub’s secret scanning push protection, which catches many patterns before a push succeeds — note that a blocked push can still leave the secret in local git history, requiring a history rewrite and key rotation regardless.

Hardcoded in container images. Keys baked into Docker images at build time are embedded in every layer of the image and persist in any registry that stores the image. Teams that rotate keys but don’t rebuild images are rotating in name only. Build pipelines should receive credentials as environment variables injected at runtime, never as ARG or ENV declarations with literal values.

Shared across environments. A single API key used in development, staging, and production means that a developer’s compromised local machine creates a production breach. Issue separate keys per environment. Most providers support multiple API keys on a single account — the inconvenience of managing separate keys is small compared to the blast radius of cross-environment exposure.

Stored in application configuration files that ship with the application. .env files, config.json files, appsettings.json files — any plaintext configuration that travels with the application artifact is a credential exposure waiting to happen. Secrets belong in a secrets management system, accessed at runtime.

Long-lived keys with no expiry. If your team has never rotated a model API key, the key is likely present in far more places than the current production deployment: old CI/CD artifact stores, developer machine dotfiles, Slack messages that were shared for debugging, screenshots in ticket trackers. Establish a rotation schedule and treat rotation as a normal operational event, not an emergency response.

Scoping by use case

Most model providers offer API keys with configurable scope — read-only access (model listing, usage retrieval) versus inference access versus fine-tuning and model management access. Apply least-privilege scoping:

  • A key used only for inference should not have fine-tuning permissions
  • A key used for a read-only analytics pipeline should not have write access
  • A key used by a specific application should be isolated from keys used by other applications — cross-application sharing means a compromise in one application compromises all of them

Some providers support more granular controls: per-model permissions, rate limits enforced at the key level, IP allowlisting, and project-level isolation. Where these controls exist, use them. The goal is to ensure that a compromised key’s blast radius is bounded — ideally to the specific application and access type it was provisioned for.

Rotation patterns

Rotation should be automated where possible and should not require application downtime. The general pattern:

  1. Provision new key in the provider’s console or via API.
  2. Deploy new key to the secrets manager. Good secrets managers support staging a new secret version alongside the current one.
  3. Rotate application instances to consume the new key version (either via a secrets manager SDK that fetches the current version at runtime, or by triggering a rolling restart of application instances).
  4. Verify that all production traffic is flowing on the new key (monitor error rates; the old key should stop appearing in access logs).
  5. Revoke old key after a short overlap period (long enough to catch any instances that failed to update, short enough that the old key doesn’t become a long-lived backup credential).

Automated rotation pipelines can streamline steps 1, 2, and 5. AWS Secrets Manager rotation lambdas, HashiCorp Vault’s dynamic secrets engine, and Azure Key Vault’s automatic rotation policies each provide a framework for this — but note that these platforms do not natively provision or revoke third-party model-provider API keys without provider-specific custom rotation logic (a Lambda that calls the provider’s key management API, for example). The automation scaffolding is provided; the provider integration must be built. The critical piece regardless of tooling is step 3 — applications must fetch credentials from the secrets manager at runtime rather than caching them indefinitely, so that a rotation event is picked up without a redeployment.

AI Agent Credential Scoping

Tool-using AI agents create a credential management challenge that has no direct precedent in traditional application security: the agent holds credentials not just to perform its task, but potentially to perform any task that its assigned credentials support. This is the confused deputy problem applied to credential management.

A detailed treatment of the architectural patterns lives in the non-human identity security post and the confused deputy post. This section focuses on the operational implementation.

Least privilege for tool-using agents

Scope credentials to the minimum access the agent’s defined task requires. This sounds obvious, but it requires discipline at provisioning time, when the path of least resistance is to provision broad access and narrow it later (which often never happens). Establish the principle that every agent credential request must be accompanied by a description of the specific resources the agent will access, the operations it will perform, and the time window during which access is needed.

Separate read and write credentials. An agent that only reads data should not hold credentials that allow writes. This is especially important for agents that process external content (web pages, documents, API responses) — content that could contain prompt injection payloads. An agent with read-only credentials can be hijacked by a prompt injection but cannot cause persistent damage. An agent with write credentials can be instructed to modify, delete, or exfiltrate data.

Scope to specific resources, not resource classes. Where the target system supports resource-level permissions (specific S3 buckets, specific database tables, specific API endpoints), scope the agent’s credentials accordingly. An agent that queries a specific database table for product information should not have credentials that provide access to the customer data table in the same database.

Apply time-bounding. Agent credentials should expire after the expected task duration, not after months or years. Short-lived credentials — tokens with a 15-minute to 4-hour lifetime, depending on the task — dramatically reduce the window of opportunity for misuse. If a credential is compromised during an agent run, it expires before an attacker can reliably operationalize it.

Ephemeral credential patterns

The most robust pattern for agent credential management is just-in-time credential issuance: the agent doesn’t hold long-lived credentials at all. Instead, when the agent needs to perform a specific action, it requests a scoped credential from a credential broker, uses it for that specific operation, and the credential expires shortly after.

This pattern requires infrastructure: a credential broker service that can authenticate the agent (verifying it is who it claims to be, with the task it claims to be executing), issue scoped credentials on demand, and audit each issuance. AWS IAM roles for EC2 and ECS workloads provide this pattern at the infrastructure layer — the platform issues short-lived STS credentials scoped to the instance or task role, rotated automatically. Lambda uses a similar model via execution role credentials injected as environment variables by the runtime. For AI-specific use cases, purpose-built credential delegation services that understand agent task context can provide finer-grained issuance policies.

At minimum, even without a credential broker, agents should use credential stores that support short-lived token generation with automatic expiry, rather than static API keys with indefinite lifetimes.

Preventing credential exfiltration through the model

Credentials should not be present in the model’s input context. If your agent architecture requires credentials to be loaded from environment variables or configuration files, that loading should happen in application code outside the model’s context window — the credential value should never appear in a prompt, a tool call parameter, or a tool response that the model processes.

If you are using a framework that automatically injects environment variables into the model’s context for debugging purposes, disable that behavior in production. A model that has seen a credential value in its context can be prompted to repeat it — this is not a model-specific flaw but a fundamental property of how language models work.

CI/CD Pipeline Security for AI Deployments

The CI/CD pipeline is one of the highest-risk credential exposure points in AI deployments, and it’s frequently an afterthought.

Secrets injection at deploy time

Container images and build artifacts should never contain secrets. The build process should compile, test, and package the application without access to production credentials. Credentials reach the runtime through the platform’s native mechanism — for example, ECS task role credentials issued at container start, Kubernetes secrets (note: plain Kubernetes Secrets are base64-encoded, not encrypted; enable etcd encryption-at-rest and restrict RBAC access, or use an external secrets operator backed by a secrets manager), or Cloud Run secrets injected as environment variables. The key principle is that the credential is not baked into the image but supplied by the platform at runtime.

Test the build pipeline: if you can pull the image from your registry and run it without providing any runtime secrets, and the application immediately performs credential-dependent operations successfully (e.g., successfully calls the model API or connects to the database at startup), then secrets are likely embedded in the image. Note that well-designed applications may defer credential use until first request, so a clean startup without secrets is necessary but not sufficient — also inspect the image layers and environment for embedded credential patterns.

Not logging what you shouldn’t

AI pipelines are unusually prone to sensitive data appearing in logs. Model API responses frequently contain user-submitted content (queries, documents, personal information). Model inputs may contain system prompt fragments. Debugging logs often capture full request/response payloads.

Audit your logging pipeline before deploying to production:

  • Model request/response payloads: Log metadata (token counts, model version, latency, status codes) not full payloads. Where full payloads are needed for debugging, gate them behind a log level that is disabled by default in production.
  • Tool call parameters and responses: Tools that operate on user data (database queries, email reads, file accesses) should log operation metadata, not the data itself.
  • Credential presence in logs: Explicitly filter known credential patterns (API key formats, bearer token shapes) from log output using a log scrubbing layer. Most structured logging frameworks support field-level redaction.

Supply chain considerations for model artifacts

If your deployment includes fine-tuned model weights, treat the weights as a production artifact with a provenance chain. This parallels the software supply chain security post principles applied to model artifacts: know where your weights came from, verify their integrity before deploying, and store them with access controls equivalent to your application code.

A compromised fine-tuned model — whether via a poisoned base model, a tampered fine-tuning dataset, or unauthorized modification of the weights file — can change application behavior in ways that are difficult to detect through standard testing. Consider checksum verification of weights at deployment time and alerting on unexpected changes to the model artifact hash.

Monitoring and Incident Response

Effective credential security requires the ability to detect when something goes wrong. For AI credentials, anomaly detection needs to cover patterns that don’t exist in traditional applications.

Signals worth monitoring

API key usage anomalies. Most model providers expose usage metrics (calls per minute, tokens per day, cost per day) via API or dashboard. Establish a baseline and alert on deviations — particularly spikes in after-hours usage, unexpected model access (a key provisioned for GPT-4 calls that suddenly starts hitting fine-tuning endpoints), or geographic anomalies if your provider exposes that data. Sudden cost spikes are often the first observable indicator of key compromise.

Inference pattern changes. A compromised application may start receiving and responding to queries that differ from baseline. Production LLM monitoring (tracking output safety classifications, input topic distributions, and refusal rates) can surface a prompt injection campaign before it causes significant damage. This is covered in depth in the LLM security monitoring post.

Unauthorized system prompt access. If your system prompt is stored in a secrets manager or encrypted configuration store, access logs for that store should be reviewed. Unexpected reads (outside normal deployment events, from unexpected principals, at unusual hours) may indicate an attacker probing the credential chain.

Output policy violations. An agent that has been successfully prompt-injected will often produce outputs that violate its normal operating policies — attempting to access resources it shouldn’t, producing responses that are inconsistent with its configured persona, or making tool calls that weren’t part of its assigned task. Output classifiers trained on your application’s normal behavior distribution can flag these deviations.

Revocation playbooks

When you suspect key compromise, the response sequence matters:

  1. Stage replacement, then revoke. The safer default is to provision and deploy a new key before revoking the suspected-compromised one — this avoids an outage in single-key deployments and buys time to confirm the revocation won’t break production traffic. If there is clear evidence of active, ongoing abuse by an attacker, immediate revocation takes priority over continuity. In either case, do not leave the suspected key active for extended investigation; the window between suspicion and revocation should be measured in minutes, not hours.

  2. Audit usage history. Pull the access logs for the compromised key covering the period of suspected compromise. Look for: requests originating from unexpected IP addresses, requests to endpoints your application doesn’t use (fine-tuning, model management), unusually high token counts (data exfiltration via large inference requests), and timing patterns that don’t match normal application traffic.

  3. Assess what was accessible. Map the key’s scope to the data and capabilities it could have been used against. A key scoped to inference only has a different exposure profile than a key with fine-tuning access. Document this assessment — it may be required for breach notification purposes depending on your jurisdiction and whether user data was accessible through the model.

  4. Rotate adjacent credentials. If one credential in a system was compromised, assume attackers may have had visibility into the credential storage mechanism. Rotate credentials that were stored in the same location, even if there’s no direct evidence they were accessed.

  5. Update monitoring baselines. After a compromise event, your baseline usage metrics are no longer a reliable indicator of normal behavior. Reset them after the incident is closed to avoid alert fatigue from persistent false positives.

If a system prompt leaks

System prompt exposure has a different incident response profile than key compromise because you can’t “rotate” a system prompt in the same way — the logic it encodes is still valid and in use.

The response priorities are:

  1. Assess what was revealed. Does the exposed prompt contain information that would materially assist attacks against your application? (Specific instruction patterns to override, internal service names, data schemas?) If yes, this accelerates your priority on other mitigations (see #2).

  2. Modify the prompt. If the exposed prompt’s content assists attacks, update the prompt to remove or obfuscate the most actionable elements. This is not about security by obscurity — your application’s defenses should not depend on the prompt being secret — but about removing low-hanging intelligence for attackers who now know your exact instruction structure.

  3. Reassess client-side exposure. System prompt leakage via client-side JavaScript exposure is structural, not incidental. Fix the architecture: move the model call server-side so the prompt never reaches the client.

  4. Review for IP exposure. If the prompt contained proprietary business logic that constitutes a trade secret, the exposure may have legal implications. Document the incident, the scope of exposure, and the remediation steps.

Practical Checklist

Use this checklist during design reviews for new AI deployments and as an audit reference for existing ones. Each item maps to a specific risk described above.

API Key Management

  • No API keys committed to version control (enforce with pre-commit hooks and CI secret scanning)
  • No API keys hardcoded in container images or build artifacts
  • Separate keys per environment (dev / staging / prod) — no cross-environment key sharing
  • API keys scoped to minimum required permissions (inference-only where fine-tuning isn’t needed)
  • Rotation schedule defined and automated where possible (quarterly at minimum; shorter for high-value keys)
  • Secrets manager used for production key storage (not environment files shipped with the application)
  • Usage anomaly alerts configured on the provider account (cost spike alerts, usage threshold alerts)

System Prompt Security

  • System prompts are not delivered from client-side code (model call originates server-side)
  • System prompts are stored under access control with an audit trail
  • System prompt changes are version-controlled and require review
  • Prompt exposure has been assessed — what would a leaked prompt reveal?
  • System prompt extraction monitoring is in place (output anomaly detection, refusal rate monitoring)

Agent Credential Scoping

  • Each agent has a dedicated credential with a defined scope (not a shared admin token)
  • Credentials are time-bounded (short-lived tokens preferred over static keys)
  • Agent credentials do not appear in model context (not injected into system prompts or tool responses)
  • Read/write permissions are separated (agents that only read data do not hold write credentials)
  • Credential scope is documented per agent and reviewed when agent capabilities change

CI/CD Pipeline

  • Build artifacts contain no secrets (inspect image layers and ENV declarations; verify credentials are not baked into the image at build time — note that clean startup alone is not reliable, since well-designed apps may defer credential use until first request)
  • Credentials are injected at runtime via platform-native mechanisms (not in Dockerfile ENV or build args)
  • Log scrubbing is applied to production logs (credential patterns and model payload content filtered)
  • Model artifacts (weights) have checksum verification at deploy time
  • CI/CD service account credentials are scoped to CI/CD operations only (not production access)

Monitoring and Incident Response

  • API key usage baseline is documented; anomaly alerts are configured
  • System prompt access logs are reviewed periodically
  • Incident response playbook includes AI credential compromise scenarios
  • Key revocation procedure is documented and tested (how quickly can you revoke and replace a key?)
  • Post-compromise audit procedure covers usage history review and adjacent credential rotation

Deployment Context Variations

Not all AI deployments have the same risk profile, and the controls above should be calibrated accordingly.

Consumer applications (a public-facing chatbot, an AI-powered web app with anonymous or authenticated end users): The primary risks are API key exposure that enables cost fraud, and system prompt extraction that enables competing products to clone your application logic. Key-per-environment isolation and server-side model calls are the highest-priority controls. Anomaly detection on cost is essential.

Enterprise internal deployments (AI assistants with access to internal data, agents that can query internal systems): The blast radius of credential compromise extends to internal data accessible through agent tool calls. Least-privilege scoping for agents and per-agent credential isolation are the highest-priority controls. Audit logging for all agent tool calls is critical for incident investigation.

Agentic automation pipelines (agents that take autonomous actions — write code, send communications, modify data): Ephemeral credentials and per-action authorization checks are essential. Long-lived credentials with broad scope in autonomous agents represent the highest-risk configuration in this taxonomy. These deployments also benefit most from the confused deputy mitigations described in the least-privilege for tool-using agents post.

References

Back to all posts