Secrets Management for AI Agents: Preventing Credential Exposure

AI agents are becoming a new class of enterprise actor. They do not only answer questions. They retrieve records, call tools, query databases, send messages, open tickets, update CRMs, trigger workflows, run code, and coordinate tasks across systems.

That makes secrets management one of the most important controls in enterprise AI security.

A traditional chatbot may leak a bad answer. An AI agent with exposed credentials can leak data, update production systems, call internal APIs, exfiltrate files, send unauthorized requests, create fraudulent workflows, or give attackers a path into systems that were never designed for autonomous access.

This is the core risk behind AI secrets management: the more agents can act, the more dangerous credential exposure becomes.

The current security landscape supports the concern. OWASP’s 2025 Top 10 for LLM and generative AI applications lists prompt injection, sensitive information disclosure, supply chain vulnerabilities, excessive agency, vector and embedding weaknesses, and unbounded consumption as key risks for LLM applications [1]. OWASP’s 2026 Top 10 for Agentic Applications extends the concern to systems that plan, act, and make decisions across complex workflows [2]. Microsoft’s 2026 security research on AI agents warns that as agents move from reading content to taking action, attacks such as MCP tool poisoning can turn trusted AI agents into a control plane for data loss [3]. Cloud Security Alliance has also warned that AI agents should have their own identities, least-privilege access, and fully attributable actions rather than borrowed human credentials or shared service accounts [4].

For decision-stage enterprise buyers, the question is not “Should our AI agent have access to tools?” The better question is:

How do we let AI agents use tools without ever exposing API keys, tokens, database passwords, certificates, service-account credentials, or cloud secrets to the model, the prompt, the logs, the browser, or the wrong system?

This guide explains how to design AI security architecture that prevents LLM credential leakage before AI agents move into production.

Executive Summary: The Rule for AI Secrets Management

The safest architecture is simple in principle:

The AI model should never see, store, generate, log, or directly handle production secrets.

An AI agent may decide that a tool is needed. It may propose a structured action. It may request a specific workflow. But the actual credential retrieval, authorization, token exchange, and tool execution should be handled by deterministic infrastructure outside the model.

That means a secure AI agent should not contain:

- Hardcoded API keys.

- Database passwords in prompts.

- Cloud credentials in environment variables exposed to the model runtime.

- OAuth refresh tokens in conversation memory.

- Service-account keys inside tool descriptions.

- MCP server secrets inside system prompts.

- Secrets in vector indexes.

- Secrets in logs or traces.

- User-provided API keys pasted into chat.

- Browser-exposed model provider keys.

- Long-lived credentials available to every tool.

Instead, the architecture should use:

- Dedicated agent identities.

- Workload identity or managed identity where possible.

- Short-lived scoped tokens.

- Centralized secrets managers or vaults.

- Runtime credential brokers.

- Tool allowlists.

- Least-privilege access.

- Secret scanning and push protection.

- Automated rotation.

- Secure logging and redaction.

- Human approval for privileged actions.

- Incident response and revocation playbooks.

OpenAI’s API key safety guidance says never to commit API keys to repositories and recommends environment variables or secure storage to avoid hardcoding keys [6]. AWS Secrets Manager best practices recommend storing credentials in Secrets Manager, rotating secrets, limiting access, monitoring secrets, and running infrastructure on private networks where appropriate [8]. Azure Key Vault security guidance maps vault protection to Zero Trust principles such as verify explicitly, use least privilege, and assume breach [9]. Google Secret Manager best practices also emphasize least privilege through IAM permissions and careful control of who can access secrets [10].

For AI agents, these practices remain necessary, but they are not enough. Agents introduce a new rule: the model should request capabilities, not receive credentials.

Why AI Agents Make Secrets Management Harder

Secrets management was already difficult before AI. Keys end up in code, CI/CD logs, .env files, screenshots, notebooks, shared drives, chat messages, build artifacts, and abandoned repositories. AI agents make the problem harder because they add new places where secrets can appear and new ways secrets can be misused.

An AI agent may process:

- User prompts.

- System prompts.

- Tool descriptions.

- Tool schemas.

- Retrieved documents.

- API responses.

- Model scratchpads.

- Agent memory.

- Observability traces.

- Evaluation datasets.

- Logs.

- Human feedback.

- Multi-agent handoffs.

- MCP tool metadata.

- Browser or frontend requests.

- Each of those can become a leakage surface.

The risk increases further because agents can operate with context and authority. A user may ask an agent to “check the invoice status.” The agent may need a billing API token. If that token is available inside the model context, hidden in a prompt, exposed in a trace, or stored in a reusable memory object, the system has created a high-impact leak.

The deeper problem is that LLMs are not deterministic secret-keepers. They are language models. They should not be used as vaults, access-control systems, or credential brokers.

The agent architecture should therefore separate three responsibilities:

1. Reasoning: The model decides what needs to happen.

2. Authorization: A policy layer decides whether it is allowed.

3. Execution: A tool or service executes using credentials that never enter the model context.

That separation is the foundation of secure AI secrets management.

What Counts as a Secret in an AI Agent System?

A secret is any credential or sensitive value that grants access, proves identity, signs requests, decrypts data, or allows a system to act.

For AI agents, secrets include:

1. Secret type: Model provider keys

Examples: OpenAI, Anthropic, Google, AWS Bedrock, Azure AI, Mistral, Cohere keys

2. Secret type: Cloud credentials

Examples: AWS access keys, Azure service principal secrets, GCP service account keys

3. Secret type: OAuth tokens

Examples: Access tokens, refresh tokens, delegated user tokens

4. Secret type: API keys

Examples: CRM, ERP, ticketing, payment, email, search, vector DB, observability APIs

5. Secret type: Database credentials

Examples: Usernames, passwords, connection strings

6. Secret type: SSH keys

Examples: Private keys for servers, Git, deployment, internal systems

7. Secret type: Signing keys

Examples: JWT signing keys, webhook signing secrets, package signing keys

8. Secret type: Certificates

Examples: TLS private keys, client certificates

9. Secret type: Webhook secrets

Examples: Stripe, GitHub, Slack, internal webhook secrets

10. Secret type: CI/CD secrets

Examples: Deployment tokens, registry tokens, cloud deploy credentials

11. Secret type: MCP credentials

Examples: Tool-server tokens, protected resource tokens, connector secrets

12. Secret type: Encryption keys

Examples: KMS keys, application encryption keys, data-wrapping keys

13. Secret type: Session credentials

Examples: Cookies, bearer tokens, temporary session tokens

The key point: an AI agent can create damage with a secret even if the agent was not originally designed as a security-sensitive system.

A customer support agent with a CRM token can expose customer records. A finance agent with ERP credentials can read invoices or vendor details. A developer agent with repository credentials can access source code. An IT agent with ticketing and automation permissions can change operational workflows. A security agent with endpoint or SIEM credentials can affect investigations.

Secrets define the agent’s blast radius.

How LLM Credential Leakage Happens

1. Secrets Are Hardcoded Into Agent Code

This is the oldest problem and still one of the most common. Developers may hardcode model provider keys, API keys, or database credentials in agent code, notebooks, tools, local scripts, or demos.

GitHub secret scanning documentation explains that secret scanning can detect supported secrets in repositories, while push protection is designed to prevent hardcoded credentials from being pushed to repositories in the first place [7]. OpenAI’s API key safety guidance also warns against committing keys to repositories and recommends secure handling instead [6].

Control: No production secret should be hardcoded. Use environment configuration only as a bridge to a secrets manager or workload identity, not as a long-term secret sprawl strategy.

2. Secrets Are Put Into Prompts

Teams sometimes place secrets in prompts so the agent can “use” them. This is dangerous.

Examples:

- “Use this API key to call the billing system.”

- “The database password is…”

- “Here is the bearer token for the CRM.”

- “Use this webhook secret when sending updates.”

Once a secret enters the prompt, it may appear in logs, traces, model provider systems, evaluation data, or generated output. It may also be exposed through prompt injection or model behavior.

Control: Secrets must never be included in system prompts, user prompts, retrieved context, tool descriptions, or model-visible memory. The agent should request a tool; the tool broker should handle credentials.

3. Secrets Are Exposed in Tool Descriptions or MCP Metadata

Tools often include descriptions, schemas, examples, and configuration metadata. If secrets are embedded there, the model can read them. Worse, malicious or poisoned tool metadata can manipulate the agent.

Microsoft’s 2026 security research on AI agents specifically discusses how MCP tool poisoning can manipulate agents and create data-loss pathways [3]. OWASP’s MCP Top 10 similarly highlights risks such as tool poisoning, schema poisoning, tool shadowing, and supply chain attacks in MCP-enabled systems [13].

Control: Tool metadata must be treated as a supply-chain surface. Tool descriptions should describe capabilities, not expose credentials. MCP servers and tools should be approved, versioned, monitored, and restricted by policy.

4. Secrets Are Stored in Conversation Memory

Agent memory can store preferences, prior tasks, workflow state, tool results, or user context. If secrets are accidentally pasted or returned by a tool, memory can preserve them and reintroduce them later.

Control: Disable memory for sensitive workflows unless necessary. Add secret detection and redaction before memory write. Scope memory to user, tenant, workflow, and retention policy. Never use memory as a secret store.

5. Secrets Appear in Logs, Traces, and Observability Tools

AI observability is essential, but logs can leak credentials. Agent traces may record model prompts, tool-call parameters, retrieved context, API responses, and error messages. If a tool returns a connection string or token in an error, that secret may be stored in traces.

Control: Redact secrets before logs are written. Restrict trace access. Mask tool payloads. Apply retention limits. Scan AI logs for secrets. Treat AI observability data as sensitive production data.

6. Secrets Are Passed Through the Browser or Client

A common mistake is embedding API keys in client-side apps. This exposes keys to users, browser developer tools, mobile app extraction, or network inspection.

OpenAI’s production best practices advise avoiding exposure of API keys in code or public repositories and using secure storage such as environment variables or secret management services [6].

Control: Browser and mobile apps should call a trusted backend or gateway. The backend authenticates the user, enforces policy, retrieves secrets securely, and calls the model or tool. Never expose model provider or internal API keys to the client.

7. Secrets Leak Through Code-Generating Agents

Developer agents may generate code, edit repository files, write configuration, or create deployment manifests. They may accidentally include secrets in code, examples, tests, CI/CD files, or documentation.

Control: Use secret scanning in repositories, push protection, pre-commit hooks, CI checks, and automated revocation workflows. Run generated code through secret scanners before commit.

8. Secrets Are Reused Across Agents and Environments

A single shared API key used by multiple agents creates attribution and blast-radius problems. If the key leaks, security teams may not know which agent used it, which task caused it, or how far the compromise extends.

Control: Use per-agent, per-environment, per-tool identity where feasible. Separate dev, test, staging, and production secrets. Avoid shared service accounts.

9. Agents Inherit Human Credentials

Some agents operate “as the user.” Delegation can be useful, but it is risky if the agent inherits broad human permissions or long-lived tokens.

Cloud Security Alliance argues that AI agents should have their own identities, not borrowed ones, and that actions should be visible and attributable [4]. Microsoft Foundry’s agent identity concepts also introduce formal agent identities and agent identity blueprints in Microsoft Entra ID for AI agents [14].

Control: Use explicit delegation and scoped authorization. The system should distinguish user identity, agent identity, and tool identity. Do not blur them.

10. Secrets Are Not Rotated or Revoked

A leaked credential remains dangerous until it is revoked or rotated. If teams do not know which agents use which secrets, rotation becomes slow and risky.

AWS Secrets Manager documentation defines rotation as periodically updating a secret and updating credentials in both the secret and the service or database [8]. OWASP’s Secrets Management Cheat Sheet describes safe rotation as a multi-step process that can include creating a new secret, setting it, testing it, and completing rotation [11].

Control: Maintain a secret inventory, automate rotation where possible, monitor rotation failures, and design applications to tolerate rotation without downtime.

The Secure Architecture Pattern: Agent, Policy, Broker, Vault, Tool

Etheon recommends a five-part architecture for AI secrets management:

1. Agent
The agent reasons about the task and emits a structured request. It never sees secrets.

2. Policy engine
A deterministic policy layer decides whether the requested action is allowed for the user, agent, workflow, data class, risk tier, and tool.

3. Credential broker
A runtime broker retrieves or mints the credential required for the tool call. The broker returns only the execution result, not the secret, to the agent.

4. Vault or secrets manager
Secrets are stored in a centralized platform such as AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault, or an equivalent enterprise secrets platform.

5. Tool execution layer
The tool executes using short-lived credentials or scoped access. Inputs and outputs are validated and logged with redaction.

The model sees:

- The user request.

- Allowed context.

- Tool names and schemas.

- Non-sensitive results.

The model does not see:

- API keys.

- OAuth refresh tokens.

- Database passwords.

- Service-account keys.

- Private keys.

- Signing keys.

- Raw bearer tokens.

- Secrets manager payloads.

This is the central design pattern for preventing LLM credential leakage.

Core Principles for AI Secrets Management

Principle 1: Do Not Let the LLM Handle Secrets

The LLM should not receive, store, transform, summarize, or generate secrets. If an agent needs to call a system, it should call a tool through a controlled execution layer.

Implementation controls:

- No secrets in prompts.

- No secrets in system messages.

- No secrets in tool descriptions.

- No secrets in retrieved documents.

- No secrets in memory.

- No secrets in logs.

- No secrets in model-visible errors.

Principle 2: Treat Every Agent as an Identity

An AI agent should have a distinct identity, lifecycle, owner, and permission set.

CSA’s guidance says agents should have their own identities, not borrowed ones, and actions should be visible and attributable [4]. Microsoft’s Foundry agent identity concepts introduce formal agent identities in Microsoft Entra ID [14].

Implementation controls:

- Assign agent identity.

- Assign owner.

- Assign risk tier.

- Use least privilege.

- Log actions by user and agent.

- Review access periodically.

- Revoke agent identity when retired.

Principle 3: Prefer Short-Lived Credentials Over Static Secrets

Long-lived API keys and service-account keys create persistent risk. Short-lived tokens reduce blast radius.

Implementation controls:

- Use workload identity federation where available.

- Use managed identities where available.

- Use OAuth token exchange.

- Use just-in-time access.

- Use short TTLs.

- Avoid static cloud access keys.

- Avoid long-lived refresh tokens in agent runtime.

Microsoft Entra workload identity documentation defines workload identities as identities assigned to software workloads such as applications, services, scripts, or containers to authenticate and access other services [15]. In agent systems, this pattern is better than embedding static credentials.

Principle 4: Use a Central Secrets Manager or Vault

Secrets should be stored centrally, not scattered across code, prompts, notebooks, CI variables, and local files.

AWS Secrets Manager, Azure Key Vault, and Google Secret Manager all emphasize secure storage, access control, monitoring, least privilege, and lifecycle management for secrets [8][9][10].

Implementation controls:

- Store secrets centrally.

- Encrypt at rest.

- Use IAM/RBAC.

- Audit access.

- Rotate secrets.

- Monitor retrieval.

- Restrict production access.

- Separate environments.

Principle 5: Scope Secrets by Tool, Task, and Environment

A support agent should not have a finance API key. A development agent should not have production database access. A tool used for reading should not use a credential that can write.

Implementation controls:

- Per-agent credentials.

- Per-tool credentials.

- Per-environment credentials.

- Per-tenant or per-customer isolation where needed.

- Separate read and write scopes.

- Separate development and production secrets.

- Fine-grained OAuth scopes.

Principle 6: Redact Before Logging

Logs are one of the easiest places to leak secrets.

Implementation controls:

- Mask tokens in logs.

- Redact authorization headers.

- Redact connection strings.

- Redact API keys.

- Redact secrets in error messages.

- Redact retrieved content where sensitive.

- Limit trace access.

- Define retention.

Principle 7: Use Secret Scanning Everywhere

Secret scanning should cover:

- Source code.

- Pull requests.

- Git history.

- CI/CD logs.

- Container images.

- Infrastructure-as-code.

- Notebooks.

- Prompt files.

- Tool definitions.

- MCP server configs.

- Documentation.

- AI-generated code.

GitHub’s push protection is designed to prevent hardcoded credentials from ever being pushed to a repository, and secret scanning can detect supported secret types and notify providers for partner secrets [7].

Implementation controls:

- Enable push protection.

- Scan private and public repositories.

- Scan generated code.

- Scan containers and artifacts.

- Use validity checks where available.

- Automatically revoke exposed secrets.

Principle 8: Rotate and Revoke Automatically

Rotation reduces the lifetime of exposed secrets. Revocation limits damage after exposure.

Implementation controls:

- Rotation schedule by secret class.

- Automated rotation where possible.

- Emergency revocation playbook.

- Break-glass credentials.

- Secret dependency map.

- Rotation testing.

- Alerting for rotation failure.

- Post-incident rotation.

NIST SP 800-57 provides general guidance and best practices for cryptographic key management, including lifecycle considerations for keying material [12].

Principle 9: Keep Secrets Out of RAG

A RAG system should not index secrets. If a document contains API keys, private keys, passwords, or tokens, those should be removed or redacted before ingestion.

Implementation controls:

- Scan documents before indexing.

- Redact secrets before embedding.

- Exclude secrets repositories.

- Block indexing of .env, config, key, certificate, and credential files.

- Detect secrets in retrieved chunks.

- Monitor retrieval of sensitive source types.

Principle 10: Require Human Approval for Privileged Credential Use

If an agent needs to perform a privileged action, human approval may be required. The approval interface should show what the agent wants to do, why, which tool it will call, what data it will send, and what side effect will occur.

Implementation controls:

- Approval gates.

- Reviewer role validation.

- Override logging.

- Action previews.

- Risk indicators.

- No approval bypass by prompt.

- Audit trail.

AI Secrets Management Reference Architecture

A production-ready architecture should include these layers:

1. Layer: User interface

Purpose: Employee interacts with assistant or agent

Secrets control: No secrets in browser or client

2. Layer: Agent runtime

Purpose: Handles reasoning and orchestration

Secrets control: No direct access to secrets

3. Layer: Policy engine

Purpose: Authorizes requested action

Secrets control: User, agent, tool, data, and risk checks

4. Layer: Tool broker

Purpose: Executes tools safely

Secrets control: Retrieves short-lived credentials server-side

5. Layer: Secrets manager

Purpose: Stores sensitive credentials

Secrets control: Encryption, IAM, rotation, audit logs

6. Layer: Identity provider

Purpose: Issues workload or agent identities

Secrets control: Managed identity, OIDC, scoped tokens

7. Layer: Tool/API layer

Purpose: Performs action

Secrets control: Least privilege and input validation

8. Layer: Logging layer

Purpose: Records activity

Secrets control: Redaction and restricted access

9. Layer: Monitoring layer

Purpose: Detects abuse

Secrets control: Secret retrieval anomalies and tool behavior

10. Layer: Incident layer

Purpose: Responds to leaks

Secrets control: Revoke, rotate, disable, investigate

This architecture prevents the model from becoming the secret boundary.

Implementation Roadmap

Phase 1: Inventory Agent Secrets

Create an inventory of:

- Agents.

- Tools.

- APIs.

- Credentials.

- Owners.

- Scopes.

- Environments.

- Rotation status.

- Storage location.

- Last access.

- Last rotation.

- Risk classification.

If the team does not know which agents use which secrets, it cannot secure them.

Phase 2: Remove Secrets From Prompts and Code

Search:

- Code repositories.

- Prompt templates.

- Tool definitions.

- Agent configs.

- MCP server configs.

- Notebooks.

- CI/CD scripts.

- Logs.

- RAG sources.

- Documentation.

Revoke any exposed secret. Rotate credentials. Replace with vault access or identity-based access.

Phase 3: Centralize Secret Storage

Move secrets into an approved secrets manager or vault. Apply access control, encryption, audit logging, and rotation.

Phase 4: Introduce Agent Identity

Assign each agent a distinct identity. Map agent identity to tool permissions. Separate user identity, agent identity, and tool execution identity.

Phase 5: Build a Tool Broker

Create a server-side broker that validates tool calls, retrieves credentials, executes actions, redacts outputs, and logs activity. The broker should not return secrets to the agent.

Phase 6: Enforce Least Privilege

Restrict credentials by agent, workflow, environment, tool, operation, and data class. Remove unused tools and scopes.

Phase 7: Add Rotation and Revocation

Automate rotation. Test rotation. Build emergency revocation. Maintain dependency maps.

Phase 8: Add Secret Scanning

Enable push protection, repository scanning, artifact scanning, and log scanning. Include AI-generated code and prompt files.

Phase 9: Test Prompt Injection and Tool Abuse

Red-team attempts to extract secrets, call tools with unauthorized parameters, trigger exports, reveal environment variables, and access system prompts.

Phase 10: Monitor Production

Monitor:

- Secret access patterns.

- Tool-call patterns.

- Failed authorization.

- Unusual credential retrieval.

- Prompt injection attempts.

- Secret scanning alerts.

- Log leakage.

- Agent identity behavior.

- Rotation failures.

- Cost spikes.

Incident Response: What to Do If an AI Agent Secret Leaks

If a secret leaks through an AI agent, prompt, log, repository, or tool call, act quickly.

Step 1: Contain

- Disable the affected agent.

- Revoke tool access.

- Revoke exposed credential.

- Disable affected MCP server or connector.

- Block outbound calls if needed.

Step 2: Rotate

- Rotate the exposed secret.

- Rotate related secrets if scope is unclear.

- Rotate downstream credentials if chained access may exist.

Step 3: Investigate

- Identify where the secret appeared.

- Review prompts, logs, traces, memory, tool metadata, and repositories.

- Determine whether the secret was used.

- Determine affected data and systems.

Step 4: Eradicate

- Remove the secret from prompts, code, logs, indexes, memory, and evaluation data.

- Remove any tool or workflow that exposed it.

- Patch validation gaps.

Step 5: Recover

- Relaunch agent only after controls are verified.

- Run red-team tests.

- Update monitoring.

Step 6: Learn

- Add the incident to evaluation tests.

- Update secret scanning.

- Update policies.

- Improve tool broker controls.

- Train affected teams.

A secret leak should become a permanent regression test.

Production Checklist for AI Secrets Management

Before an AI agent goes live, confirm:

1. Gate: Agent identity

Required evidence: Dedicated identity, owner, risk tier, revocation path

2. Gate: Secret inventory

Required evidence: All credentials mapped to tools, agents, owners, environments

3. Gate: No model-visible secrets

Required evidence: Prompts, memory, tools, RAG, logs, and outputs checked

4. Gate: Vault storage

Required evidence: Secrets stored in approved secrets manager or vault

5. Gate: Least privilege

Required evidence: Credentials scoped by tool, operation, user, and environment

6. Gate: Short-lived access

Required evidence: Temporary tokens or workload identity used where possible

7. Gate: Tool broker

Required evidence: Agent requests actions; broker handles credentials

8. Gate: Secret scanning

Required evidence: Repos, prompts, configs, logs, artifacts, and generated code scanned

9. Gate: Rotation

Required evidence: Rotation schedule, automation, and failure alerts configured

10. Gate: Logging

Required evidence: Redaction, retention, access control, and audit trail implemented

11. Gate: Prompt injection tests

Required evidence: Attempts to reveal or misuse secrets tested

12. Gate: Tool abuse tests

Required evidence: Unauthorized credential and tool-call attempts tested

13. Gate: Incident response

Required evidence: Revoke, rotate, disable, investigate, and relaunch process ready

If any gate is missing, the agent should remain in pilot.

Common Mistakes to Avoid

The first mistake is letting the LLM see secrets. The model should request actions, not receive credentials.

The second mistake is using one shared API key for many agents. This destroys attribution and increases blast radius.

The third mistake is putting credentials in tool descriptions, prompt templates, or MCP metadata.

The fourth mistake is exposing model provider keys in frontend code.

The fifth mistake is logging raw tool payloads and authorization headers.

The sixth mistake is relying on environment variables alone without centralized governance, rotation, and audit.

The seventh mistake is allowing agents to inherit broad human credentials.

The eighth mistake is failing to scan AI-generated code.

The ninth mistake is indexing secrets into RAG systems.

The tenth mistake is not having an emergency revocation playbook.

The Etheon Recommendation

AI agents should never become credential holders. They should be controlled requesters inside a secure execution architecture.

For Etheon, the rule is direct:

The model should never see the secret. The agent should never own the secret. The tool broker should use the secret only when policy allows it.

That means enterprise teams should build AI secrets management around identity, least privilege, vaults, short-lived credentials, tool brokers, redaction, scanning, rotation, and incident response.

A secure AI agent can still be powerful. It can retrieve data, recommend actions, call tools, and automate workflows. But it should do so inside a credential architecture designed for containment.

The companies that scale AI agents safely will not be the ones that give agents the most access. They will be the ones that give agents the least access required, for the shortest time required, with the clearest audit trail possible.

That is how enterprise teams prevent LLM credential leakage and build AI security architecture that can survive production.

References

[1] OWASP, “Top 10 for Large Language Model Applications.”
https://owasp.org/www-project-top-10-for-large-language-model-applications/

[2] OWASP GenAI Security Project, “OWASP Top 10 for Agentic Applications 2026.”
https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

[3] Microsoft Security, “Securing AI Agents: When AI Tools Move From Reading to Acting.”
https://www.microsoft.com/en-us/security/blog/2026/06/30/securing-ai-agents-ai-tools-move-from-reading-acting/

[4] Cloud Security Alliance, “Who’s Behind That Action? The AI Agent Identity Crisis.”
https://cloudsecurityalliance.org/blog/2026/04/20/who-s-behind-that-action-the-ai-agent-identity-crisis

[5] Cloud Security Alliance, “New CSA Survey Reveals 82% of Enterprises Have Unknown AI Agents in Their Environments.”
https://cloudsecurityalliance.org/press-releases/2026/04/21/new-cloud-security-alliance-survey-reveals-82-of-enterprises-have-unknown-ai-agents-in-their-environments

[6] OpenAI, “Best Practices for API Key Safety” and “Production Best Practices.”
https://help.openai.com/en/articles/5112595-best-practices-for-api-key-safety
https://developers.openai.com/api/docs/guides/production-best-practices

[7] GitHub Docs, “Push Protection,” “Secret Scanning,” and “Supported Secret Scanning Patterns.”
https://docs.github.com/en/code-security/concepts/secret-security/push-protection
https://docs.github.com/code-security/secret-scanning/about-secret-scanning
https://docs.github.com/en/code-security/reference/secret-security/supported-secret-scanning-patterns

[8] AWS Documentation, “AWS Secrets Manager Best Practices” and “Rotate AWS Secrets Manager Secrets.”
https://docs.aws.amazon.com/secretsmanager/latest/userguide/best-practices.html
https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html

[9] Microsoft Learn, “Secure Your Azure Key Vault” and “Authenticate to Azure Key Vault.”
https://learn.microsoft.com/en-us/azure/key-vault/general/secure-key-vault
https://learn.microsoft.com/en-us/azure/key-vault/general/authentication

[10] Google Cloud, “Secret Manager Best Practices.”
https://docs.cloud.google.com/secret-manager/docs/best-practices

[11] OWASP Cheat Sheet Series, “Secrets Management Cheat Sheet.”
https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

[12] NIST, “SP 800-57 Part 1 Rev. 5: Recommendation for Key Management.”
https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final

[13] OWASP, “MCP Top 10.”
https://owasp.org/www-project-mcp-top-10/

[14] Microsoft Learn, “Agent Identity Concepts in Microsoft Foundry.”
https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/agent-identity

[15] Microsoft Learn, “Workload Identities — Microsoft Entra Workload ID.”
https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview