68.1 Introduction
AI applications depend on secrets.
Examples include:
- AI provider API keys
- database credentials
- Redis credentials
- object-storage credentials
- OAuth client secrets
- signing keys
- encryption keys
- webhook secrets
- service credentials
- deployment credentials
- monitoring tokens
- certificate private keys
A leaked secret can provide an attacker with direct access to infrastructure or data.
Therefore:
A secret is not configuration data. It is a security credential.
Secrets require their own lifecycle:
Create
↓
Store
↓
Distribute
↓
Use
↓
Monitor
↓
Rotate
↓
Revoke
↓
Destroy
68.2 API Keys
AI platforms frequently connect to external providers.
Conceptually:
AI Application
│
│ API credential
▼
AI Provider
The credential should never be exposed to the browser when the provider expects server-side authentication.
Unsafe architecture:
Browser
↓
Provider API key
↓
AI Provider
A safer architecture is:
Browser
↓
Your Backend
↓
Secret Manager
↓
AI Provider
The browser receives the result, not the provider's secret.
68.3 Environment Variables
Environment variables are useful for configuration and secrets, but they should not automatically be considered a complete secret-management system.
For example:
```text id="kjv8bq"
AI_PROVIDER_KEY=...
DATABASE_PASSWORD=...
Important concerns include:
* accidental logging
* exposure through debugging
* insecure deployment configuration
* process inspection
* incorrect frontend bundling
* source-control mistakes
Environment variables should therefore be used carefully and preferably populated from a dedicated secret-management mechanism.
---
# 68.4 Never Commit Secrets
One of the most important rules:
```text id="w2a7qx"
DO NOT commit:
.env
.env.production
private keys
API tokens
database passwords
cloud credentials
A .gitignore should include appropriate secret files.
Example:
.env
.env.*
!.env.example
An example configuration can contain placeholders:
```text id="2x0c1y"
AI_PROVIDER_KEY=replace_me
but never a real credential.
---
# 68.5 Secret Manager
Production systems should preferably use a dedicated secret-management system.
Conceptually:
```text id="z6a3t9"
Application
│
│ authenticated request
▼
Secret Manager
│
▼
Secret
The application receives only the secret it actually needs.
Examples of secret-management technologies include:
- cloud secret managers
- Vault-style systems
- Kubernetes secret integrations
- hardware-backed key-management systems
The implementation depends on the infrastructure.
68.6 Secret vs Configuration
Not every environment variable is a secret.
Configuration:
```text id="j89w0d"
PORT=3000
LOG_LEVEL=info
MODEL_NAME=model-x
Secret:
```text id="7c6g2m"
API_KEY=...
PASSWORD=...
PRIVATE_KEY=...
Separating these categories improves security management.
68.7 Secret Classification
A useful classification is:
| Secret | Risk |
|---|---|
| Development API key | Medium |
| Production API key | High |
| Database password | Critical |
| Signing key | Critical |
| Encryption key | Critical |
| OAuth client secret | High |
| Webhook signing secret | High |
| Cloud administrator credential | Critical |
Higher-risk credentials should receive stronger controls.
68.8 Credential Isolation
Do not use one credential everywhere.
Bad architecture:
```text id="m2k1ko"
MASTER_KEY
│
├── API
├── Worker
├── Billing
├── Notifications
└── Media Processor
If the key leaks, every component is affected.
Better:
```text id="6b7y7a"
API credential
Worker credential
Billing credential
Notification credential
Media credential
Each identity receives only what it needs.
68.9 Least Privilege
A service credential should have the minimum required permissions.
For example:
```text id="w4j6q0"
Media Worker
├── read quarantine storage
├── write processed storage
└── denied database administration
A compromised media worker should not automatically become an infrastructure administrator.
---
# 68.10 Short-Lived Credentials
Long-lived credentials increase exposure.
Prefer:
```text id="c0f0qk"
short-lived credential
↓
use
↓
expire
where supported.
This reduces the useful lifetime of a stolen credential.
68.11 Credential Rotation
Rotation replaces an active credential with a new one.
A safe rotation process is:
```text id="o7b4jc"
Create new credential
↓
Deploy new credential
↓
Verify operation
↓
Revoke old credential
↓
Monitor
Avoid immediately deleting the old credential before confirming that all services have migrated.
---
# 68.12 Dual-Key Rotation
Some systems support two active credentials.
For example:
```text id="0r0d8f"
Key A = active
Key B = standby
During rotation:
```text id="5j1d1c"
Create B
↓
Deploy B
↓
Verify B
↓
Revoke A
This reduces downtime during credential replacement.
---
# 68.13 Emergency Revocation
Every critical credential should be revocable.
Suppose:
```text id="y98v6a"
Provider API key leaked
The incident response should allow:
```text id="w0n9a4"
Detect
↓
Disable key
↓
Issue replacement
↓
Deploy replacement
↓
Investigate
↓
Monitor
Emergency procedures should be documented and tested.
---
# 68.14 Encryption Keys
Encryption keys are different from ordinary API credentials.
A key may protect:
* database fields
* object-storage data
* backups
* tokens
* application secrets
* sensitive documents
A key-management architecture should prevent applications from unnecessarily handling master keys directly.
---
# 68.15 KMS
A Key Management Service can provide centralized control over cryptographic keys.
Conceptually:
```text id="1z3m5g"
Application
│
│ cryptographic operation
▼
KMS
│
▼
Key Material
The application may request:
- encrypt
- decrypt
- generate data key
- sign
- verify
without directly receiving the highest-level key material.
68.16 Envelope Encryption
A common architecture is envelope encryption.
Conceptually:
```text id="1i1c7g"
Master Key
│
▼
Data Encryption Key
│
▼
Encrypted Data
The data encryption key encrypts the actual data.
The master key protects the data encryption key.
This creates a hierarchy.
---
# 68.17 Why Key Hierarchies Matter
Suppose an application stores millions of encrypted objects.
Using one directly exposed key everywhere creates unnecessary risk.
Instead:
```text id="j9lqg8"
Root / KMS Key
│
├── Data Key A → Object Group A
├── Data Key B → Object Group B
└── Data Key C → Object Group C
Compromise of one lower-level key can have a more limited impact.
The exact hierarchy depends on the security model.
68.18 Key Separation
Do not use one cryptographic key for unrelated purposes.
Avoid:
```text id="9ym5jd"
ONE_KEY
├── encryption
├── signing
├── sessions
└── webhooks
Prefer purpose-specific keys:
```text id="m5c5z1"
encryption key
signing key
session-signing key
webhook-signing key
This is known as key separation.
68.19 Signing Keys
Signing keys provide integrity and authenticity.
For example:
```text id="3u9k74"
Message
↓
Private Signing Key
↓
Signature
The receiver can verify:
```text id="q78g2y"
Message
+
Signature
+
Public Key
↓
Valid / Invalid
Signing keys should be protected carefully because anyone who obtains the private key may be able to forge trusted messages.
68.20 Session Signing
Applications may sign session or token data.
The signing secret should be:
- unpredictable
- protected
- rotated
- revocable through an appropriate versioning mechanism
- unavailable to untrusted clients
Never expose private signing keys to browser code.
68.21 Webhook Secrets
External providers may send webhooks.
A secure flow is:
```text id="5fpx50"
Provider
↓
Webhook
↓
Signature Verification
↓
Application
The application should verify authenticity before processing sensitive events.
Do not trust a webhook simply because it came to an internal endpoint.
---
# 68.22 Webhook Replay
A valid webhook can potentially be replayed.
Useful controls include:
* event IDs
* timestamps
* signature verification
* idempotency
* replay windows
Conceptually:
```text id="yq1r3m"
event_id = 12345
first request → accepted
second request → duplicate
↓
rejected
68.23 Database Credentials
Database credentials should be isolated from application code.
Preferred:
```text id="k4s8r9"
Application Identity
↓
Secret Manager
↓
Database Credential
↓
Database
Where supported, short-lived database authentication can further reduce exposure.
---
# 68.24 Database Credential Scope
Different applications may require different database permissions.
For example:
```text id="r8h6jo"
API
├── SELECT
├── INSERT
└── UPDATE
Reporting
└── SELECT
Migration Tool
├── schema modification
└── migration execution
The reporting service should not receive migration privileges.
68.25 Cloud Credentials
Cloud infrastructure credentials are especially sensitive.
Avoid placing administrator credentials inside application containers.
A better architecture uses workload identity:
```text id="n2f3kh"
Application
↓
Workload Identity
↓
Cloud IAM
↓
Allowed Resource
This reduces dependence on static access keys.
---
# 68.26 AI Provider Credential Isolation
If an AI platform supports multiple providers:
```text id="y3fj9g"
AI Orchestrator
├── Provider A credential
├── Provider B credential
├── Provider C credential
└── Local provider
Each credential should be:
- separately stored
- separately rotated
- separately monitored
- separately revocable
The orchestrator should not expose provider credentials to model prompts or user-visible output.
68.27 Provider Key Leakage Through Prompts
AI applications must consider an unusual risk:
```text id="v7dr1s"
Secret
↓
Prompt construction
↓
Model
Secrets should never be inserted into prompts unless absolutely necessary.
Do not assume the model will reliably keep secrets confidential.
Prefer:
```text id="t8g2pp"
AI
↓
tool request
↓
trusted backend
↓
secret retrieval
↓
external API
The model receives a controlled result rather than the underlying credential.
68.28 Agent Secret Boundaries
An AI agent should not have unrestricted access to secrets.
Unsafe:
```text id="n8z6av"
Agent
↓
all environment variables
↓
all credentials
Better:
```text id="g4yq3m"
Agent
↓
Tool
↓
Policy
↓
Specific credential
↓
Specific external operation
This makes the secret boundary explicit.
68.29 Tool-Based Credential Access
Suppose an agent needs to send an email.
The agent should not receive the email provider's master API key.
Instead:
```text id="c4e7by"
Agent
↓
email.send tool
↓
authorization policy
↓
notification service
↓
provider credential
↓
provider
This follows least privilege.
---
# 68.30 Secret Redaction
Application logs should automatically redact known secret patterns.
For example:
```text id="8u9u2n"
API_KEY=********
TOKEN=********
PASSWORD=********
Redaction should happen before logs leave the application.
But redaction is a secondary defense.
The preferred approach is:
Do not log secrets in the first place.
68.31 Error Messages
Secrets can accidentally appear in errors.
For example, an HTTP client exception might contain:
```text id="v5g4p2"
https://api.example.com?api_key=SECRET
The application should sanitize exceptions before logging or displaying them.
---
# 68.32 Debugging
Development debugging creates additional risk.
Avoid printing:
```text id="q7x8o5"
process.env
request headers
authorization headers
cookies
database URLs
A developer-friendly debugging system should deliberately exclude sensitive fields.
68.33 Source-Code Scanning
Repositories should be scanned for accidental secret exposure.
Detection can look for:
- API-key patterns
- private-key blocks
- cloud credential formats
- tokens
- passwords
- connection strings
Secret scanning should occur:
```text id="k1w0ar"
Developer
↓
Pre-commit
↓
CI
↓
Repository monitoring
---
# 68.34 If a Secret Is Committed
Deleting the secret from the latest file is not sufficient.
If a credential was committed to version control:
```text id="4p8b5z"
Assume compromised
↓
Revoke credential
↓
Issue replacement
↓
Investigate repository history
↓
Remove exposure where appropriate
The most important action is credential revocation.
68.35 Secret Access Auditing
Secret-management systems should provide visibility into:
```text id="0s5k6v"
who accessed
what secret
when
from which workload
success/failure
Unexpected access can indicate compromise.
---
# 68.36 Secret Usage Monitoring
Potential anomalies include:
* secret accessed by a new service
* unusual geographic access
* sudden request volume
* access outside normal deployment windows
* secret accessed by a development environment
* provider calls from unexpected infrastructure
Monitoring should correlate identity, network and application telemetry.
---
# 68.37 Secret Lifecycle
A mature lifecycle is:
```text id="8lq1yr"
Generate
↓
Register
↓
Store securely
↓
Authorize access
↓
Use
↓
Monitor
↓
Rotate
↓
Revoke
↓
Destroy
Each transition should have clear ownership.
68.38 Secret Inventory
Maintain an inventory of important credentials.
Example:
| Secret | Owner | Used By | Rotation | Criticality |
|---|---|---|---|---|
| AI Provider A | AI team | AI service | scheduled | High |
| DB credential | Platform | API | scheduled | Critical |
| Webhook secret | Integration | Billing | scheduled | High |
| Storage credential | Media | Worker | scheduled | High |
Without an inventory, organizations often discover forgotten credentials during incidents.
68.39 Secret Ownership
Every production secret should have:
- owner
- purpose
- service
- environment
- creation date
- rotation policy
- emergency contact/process
- retirement condition
A secret without an owner can remain active indefinitely.
68.40 Development and Production Separation
Never reuse production credentials in local development.
Prefer:
```text id="r4x7tu"
Development
└── development credentials
Staging
└── staging credentials
Production
└── production credentials
A compromised laptop should not automatically expose production infrastructure.
---
# 68.41 Test Credentials
Automated tests should use:
* mock credentials
* sandbox credentials
* temporary credentials
* isolated test environments
Avoid embedding real production API keys into test suites.
---
# 68.42 Container Secret Handling
Secrets should not be baked into container images.
Unsafe:
```text id="4ylr1f"
Docker image
└── production API key
Anyone who obtains the image may potentially recover the secret.
Prefer runtime injection through secure infrastructure.
68.43 Kubernetes Secret Handling
Kubernetes deployments can integrate with external secret managers.
A mature architecture might be:
```text id="e2zq2u"
Pod
↓
Workload Identity
↓
Secret Manager
↓
Specific Secret
This avoids turning a static configuration file into the primary security boundary.
---
# 68.44 HSM
Hardware Security Modules can provide stronger protection for highly sensitive cryptographic keys.
Conceptually:
```text id="ny4yq7"
Application
↓
Crypto Operation
↓
HSM
↓
Protected Key Material
HSMs are especially relevant for:
- signing infrastructure
- root cryptographic keys
- certificate authorities
- high-value financial systems
They add cost and operational complexity, so they should be used according to risk.
68.45 Key Rotation
Encryption-key rotation must be designed carefully.
A typical strategy is:
```text id="1y3m6w"
Old Key
↓
New data → New Key
Old data
↓
Old Key
Existing encrypted data does not necessarily need immediate re-encryption.
The system can gradually migrate older data according to risk and operational requirements.
---
# 68.46 Key Versioning
Encrypted data should identify which key version protects it.
Conceptually:
```json id="x1n3fj"
{
"key_version": 7,
"ciphertext": "..."
}
This allows the application to select the correct key during decryption.
68.47 Destruction and Cryptographic Erasure
When data must become unrecoverable, destroying the associated encryption key can sometimes provide a powerful deletion mechanism.
Conceptually:
```text id="2g7j0s"
Encrypted Data
+
Encryption Key
↓
Readable
Destroy Key
↓
Data becomes cryptographically inaccessible
This must be carefully designed because backups and copies may use different keys.
---
# 68.48 Backup Keys
Backup encryption should not depend on casually shared production credentials.
Protect backup keys independently.
A compromise of production credentials should not automatically provide unrestricted access to every backup.
---
# 68.49 Disaster Recovery
A secret-management architecture must survive infrastructure failure.
The recovery plan should answer:
* How are keys restored?
* Who can restore them?
* How is identity established?
* Where are recovery credentials stored?
* How are emergency credentials rotated?
* How is access audited?
Disaster recovery should not require weakening security.
---
# 68.50 Break-Glass Access
Emergency access can be necessary.
A break-glass mechanism should be:
* exceptional
* strongly authenticated
* monitored
* logged
* time-limited
* reviewed afterward
It should not become the normal operational path.
---
# 68.51 Secret Exposure Incident
A secret exposure incident should follow a predictable response:
```text id="7d2s0a"
Detect
↓
Classify
↓
Revoke
↓
Rotate
↓
Contain
↓
Investigate
↓
Review logs
↓
Patch root cause
↓
Monitor
Do not wait for the investigation to finish before revoking a clearly compromised credential.
68.52 AI-Specific Secret Threat Model
AI applications introduce additional secret-exposure paths:
```text id="d9y8v4"
Secrets
├── prompts
├── logs
├── traces
├── model context
├── tool calls
├── agent memory
├── error messages
├── browser bundles
├── generated documents
└── third-party integrations
Therefore, secret management must extend beyond environment variables.
---
# 68.53 Memory and Secret Leakage
Long-term AI memory should not automatically store secrets.
If a user accidentally gives the system:
```text id="j5o8u0"
API key
the memory system should not blindly persist it.
Secret detection and filtering should be considered before storing long-term conversational information.
68.54 RAG and Secrets
Documents used for RAG may contain credentials.
The ingestion pipeline should therefore consider:
```text id="e7m0s8"
Document
↓
Secret detection
↓
Classification
↓
Redaction / restricted storage
↓
Chunking
↓
Embedding
Otherwise, a secret could become retrievable through semantic search.
---
# 68.55 Embeddings and Secrets
Even if the original secret is removed, sensitive information may remain indirectly represented in embeddings or derived artifacts.
Therefore, deleting sensitive source data may require considering:
* chunks
* embeddings
* caches
* indexes
* backups
* derived summaries
The data lifecycle must include derived AI artifacts.
---
# 68.56 Secure Secret Architecture
A complete architecture can look like:
```text id="v9bq7m"
Application
│
Workload Identity
│
▼
Secret Manager
│
┌────────────┼────────────┐
▼ ▼ ▼
AI Key DB Key Storage Key
│ │ │
▼ ▼ ▼
AI Provider Database Object Storage
Cryptographic operations can additionally use:
```text id="m0x7xj"
Application
│
▼
KMS / HSM
│
▼
Encryption / Signing
---
# 68.57 Security Checklist
```text id="2uk2z5"
[ ] Production secrets are centrally managed
[ ] Secrets are not committed to source control
[ ] Development and production credentials are separated
[ ] Service credentials are unique
[ ] Least privilege is enforced
[ ] Long-lived credentials are minimized
[ ] Rotation procedures exist
[ ] Emergency revocation exists
[ ] Secret access is audited
[ ] Secret usage is monitored
[ ] Logs redact sensitive values
[ ] Error messages are sanitized
[ ] Container images contain no production secrets
[ ] Browser bundles contain no server secrets
[ ] AI prompts do not unnecessarily contain secrets
[ ] Agent tools do not expose master credentials
[ ] Webhooks are authenticated
[ ] Webhook replay is controlled
[ ] Encryption keys are separated by purpose
[ ] Key versions are tracked
[ ] Backups are separately protected
[ ] Recovery procedures are tested
[ ] Break-glass access is controlled
[ ] RAG ingestion considers secret detection
[ ] AI memory does not blindly retain credentials
68.58 Final Architecture Principle
Secrets should never be treated as ordinary application data.
A mature AI security architecture separates:
```text id="w6q7g2"
Identity
↓
Credential
↓
Authorization
↓
Secret Access
↓
Operation
↓
Audit
The most important principles are:
**Never expose server-side secrets to clients.**
**Never commit production secrets to source control.**
**Never give every service the same credential.**
**Never give an AI agent unrestricted secret access.**
**Never rely on secrecy instead of authorization.**
**Rotate credentials and keys.**
**Make emergency revocation possible.**
**Audit secret access.**
**Treat AI prompts, memory, RAG data, logs and generated outputs as possible secret-leakage channels.**
The ultimate goal is not simply to hide credentials.
It is to create a system where:
> **Even if one credential, service, worker, agent or application component is compromised, the attacker cannot automatically obtain the keys to the entire platform.**
This is the foundation of compartmentalized AI security.
The next logical chapter is:
**Chapter 69 — Secure AI Cryptography & Data Protection: Encryption at Rest and in Transit, AES-GCM, Hashing, Password Hashing, Digital Signatures, Key Derivation, Token Security, Cryptographic Randomness, Key Rotation, Data Integrity & Cryptographic Failure Modes.**
Top comments (0)