Secrets Management Policy

1. Objective

This policy defines the requirements for managing the complete lifecycle of secrets - API keys, access tokens, passwords, certificates, database credentials and any other values that, if exposed, allow unauthorised access to systems, data or infrastructure.

Secrets are one of the most frequent and most damaging compromise vectors: exposed in repositories, logs, container images or pipelines, they often persist for months without being rotated, turning a temporary exposure into a permanent risk. Effective secrets management is not merely a matter of technical hygiene - it is a fundamental security control whose failure can compromise the organisation's entire security posture.

The objective of this policy is to ensure that:

• No secret is stored in code repositories, logs, images or build artefacts
• Secrets are managed centrally in secrets vaults with controlled and audited access
• Secrets in pipelines are injected ephemerally, preferably via OIDC/workload identity
• Rotation is automated or scheduled, with TTLs defined by type and criticality level
• Revocation in the event of exposure is immediate and verifiable

---

2. Scope

This policy covers all secrets used in the development, pipeline, runtime and infrastructure contexts, regardless of type:

• Access credentials for databases, caches, queues and messaging systems
• API keys for external services
• Access tokens for cloud systems, image registries and artefact repositories
• CI/CD tokens (pipeline tokens, deploy keys)
• TLS/mTLS certificates and their associated private keys
• Encryption keys for data at rest or in transit
• Service account passwords

---

3. Absolute prohibitions

The following practices are prohibited regardless of criticality level or context:

Prohibited practice	Justification
Hardcoding secrets in source code	Propagation through version history; impossible to rotate without changing code
Secrets in versioned configuration files (e.g. committed .env, application.yml with passwords)	Exposure to everyone with read access to the repository
Secrets in environment variables that are not masked in pipeline logs	Exposure in logs, often stored without adequate access control
Secrets embedded in container images	Impossible to rotate without a rebuild; exposure in the image layers
Secrets in build artefacts (JARs, wheels, binaries)	Uncontrolled distribution of the secret along with the artefact
Use of "global secrets" shared across multiple pipelines or environments	Violation of the principle of least privilege; compromising one pipeline compromises all of them
Production secrets accessible in development environments	Unnecessary exposure; risk of leakage through a less controlled environment

warning

Detection of hardcoded secrets in code or configuration must be automated in the pipeline (secret detection). Any finding blocks the merge at L2/L3, regardless of the severity of the other gates.

---

4. Centralised storage

All secrets must be stored in a centralised secrets vault, with controlled and audited access:

Requirement	L1	L2	L3
Centralised secrets vault in use	Recommended	Mandatory	Mandatory
Vault access controlled by RBAC with least privilege	Recommended	Mandatory	Mandatory
Vault access audited and log retained	Recommended	Mandatory	Mandatory
Production secrets segregated from the other environments	Recommended	Mandatory	Mandatory
Vault with high availability and backup	Recommended	Mandatory	Mandatory

Reference tools: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager.

---

5. Runtime injection

Secrets must be injected into applications and pipelines exclusively at execution time - never persisted permanently in the file system or in environment variables:

5.1 Applications

• Secrets injected via environment variable at runtime (not at build time)
• Environment variables holding secrets not exposed in diagnostic endpoints or health checks
• Preferred alternative at L2/L3: direct access to the vault via SDK at runtime, using the workload's identity

5.2 CI/CD pipelines

• Secrets referenced via the CI system's native mechanism (secrets.*, CI/CD Variables masked, Variable Groups)
• Output of commands that access secrets masked in the logs
• Cloud credentials via OIDC/workload identity (ephemeral token, TTL ≤ 1h) - eliminates long-lived static keys

5.3 Containers

• Secrets mounted as orchestrator secret volumes (e.g. Kubernetes Secrets, with encryption at rest)
• Preferred alternative at L3: access via the vault with workload identity (e.g. Vault Agent, AWS IRSA, GCP Workload Identity)
• Secrets never passed as a Docker ARG during the build

---

6. TTL, rotation and revocation

6.1 TTL by secret type

Secret type	Recommended maximum TTL	L3 (mandatory maximum TTL)
Pipeline tokens (ephemeral OIDC)	≤ 1 hour	≤ 1 hour
API access tokens (short-lived)	≤ 24 hours	≤ 8 hours
Database credentials (automatic rotation)	30 days	15 days
API keys for external services	90 days	30 days
TLS certificates (application)	1 year	90 days
Data encryption keys	1 year (with envelope rotation)	90 days

6.2 Rotation

• Automated rotation wherever the issuing system supports it (e.g. Vault dynamic secrets, AWS IAM roles, OIDC)
• Scheduled manual rotation for secrets without automatic rotation support, with alerts before expiry
• Rotation verifiable without code changes or image rebuilds
• Auditable rotation history

6.3 Revocation on suspected exposure

When the exposure of a secret is suspected or confirmed:

1. Revoke the secret immediately (do not wait for the TTL)
2. Issue a new secret and distribute it to the systems that depend on it
3. Review the vault access logs to assess misuse during the exposure period
4. Record the incident and notify in accordance with the Traceability Policy and the IRP process

6.4 Key lifecycle and certificate inventory

The application's cryptographic keys (data encryption, signing, TLS) follow a lifecycle defined per key type (ENC-007):

Phase	What is required
Generation	In a vault or HSM, with an approved random generator and the algorithm and size from the list of primitives (ENC-003)
Distribution	Only over an encrypted and authenticated channel, to the systems that use it
Storage	In a vault or HSM; never in code, images or versioned configuration files
Backup and archiving	Encrypted, with restricted access and kept separate from the backups of the data the key protects
Recovery	Documented and tested procedure, recording who recovered the key
Rotation and retirement	Within the periods of §6.1; a retired key is kept only to decrypt existing data
Revocation	Immediate in case of exposure (§6.3)
Destruction	When no data depend on the key any longer, with a record

Certificate inventory. The application keeps an inventory of all its certificates (TLS, signing, mTLS clients), with owner, issuer, validity and where the private key is kept (vault, HSM, device). There is an alert before expiry (at least 30 days; 90 days at L3) and automated renewal where the issuer allows it. The organisation's public key infrastructure is out of scope for this Manual.

---

7. Third-party secrets and integrations

Secrets received from third parties (e.g. supplier API keys) must be:

• Stored in the centralised vault, not in shared files or ticketing systems
• With minimum scope and permissions negotiated with the supplier
• With a known validity period and a renewal alert
• Revoked immediately when the integration is terminated

---

8. Responsibilities

Role	Responsibility
Developer	Never hardcode secrets; use approved injection mechanisms; report accidentally exposed secrets
DevOps / SRE	Manage the secrets vault; configure rotation; implement OIDC/workload identity; monitor access
AppSec Engineer	Define TTLs and the rotation policy; configure secret detection in the pipeline; audit vault access
Tech Lead	Ensure the team knows and follows this policy; do not approve PRs with hardcoded secrets
GRC / Compliance	Audit compliance; verify that production secrets are segregated; verify access logs

---

9. AI agents as non-human principals

The previous chapter describes secrets for traditional CI identities (runners, workloads). When an AI agent comes to operate the organisation's pipeline or resources — Claude Code executing tool calls, Copilot Workspace acting on PRs, in-house agents via SDK — that agent is one more non-human principal subject to the same principles as this policy, with three specialisations.

9.1 Dedicated identity per agent and per environment

• Each AI agent has a distinct ephemeral workload identity (OIDC) — no reuse of human credentials, no reuse across environments (dev / staging / prod) or across agents.
• TTL ≤ 1h (the same rule as for the other workload identities).
• The identity is declared in the agent's mandate (field identity_ref — see Policy 38 — AI Agent Mandates).

9.2 Per-tool scoping

The agent's identity receives only the scopes needed for the tools declared in the tools_allowlist of the mandate — not the maximum scopes supported by the runtime. Practical examples:

• Agent that opens PRs: gh:pr:write, gh:repo:read. Not gh:repo:write or gh:repo:delete.
• Agent that applies Kubernetes manifests in staging: k8s:deploy:staging:apply. Not cluster-admin.
• Agent that publishes packages: npm:publish:scoped-package. Not npm:publish:*.

Changing the tools_allowlist or the scopes is a change structurally equivalent to changing an IAM policy — it requires a new mandate approval cycle (see Policy 38 §5).

9.3 Operational kill-switch

For agents at level A2+, the immediate revocation procedure (REQ-AGN-003) must be exercised periodically:

Autonomy level	Minimum exercise cadence
A2	Annual (in sandbox/staging)
A3	Quarterly (in sandbox/staging)
A4	Monthly (in sandbox/staging)

The exercise measures the total time between triggering and effective revocation (OIDC revocation + runtime termination + namespace isolation). The result is recorded; a failed exercise is treated as operational degradation and blocks new activations of A3/A4 agents until it is resolved.

9.4 Specific prohibitions

• ❌ Reusing human credentials to authenticate the agent — violates the fundamental principle of this policy as applied to AI principals.
• ❌ A long-lived token (>1h) in any AI agent identity — the same rule that applies to CI runners.
• ❌ A scope that exceeds the mandate's tools_allowlist — silent over-privilege is an operational incident.
• ❌ Sharing an identity between two agents or between an agent and a human — breaks the audit trail.
• ❌ Operating at A3/A4 without a kill-switch exercised within the required cadence — the kill-switch is decorative if it has never been measured.

📌 Everything else in this policy (absolute prohibitions §3, centralised storage §4, runtime injection §5, TTL/rotation §6) applies without rewording to the case of AI agents.

---

10. PII and sensitive data in prompts (cross-link GDPR)

The previous chapters cover classic secrets — tokens, keys, credentials. When an AI agent receives user input (chat, document upload, form), personal data enter the prompt and, by extension, may travel all the way to the model AI service vendor. The category of the problem is similar — sensitive information flowing through an uncontrolled channel — but the applicable legal regime is the GDPR, not this policy. This section explicitly links the two so that operational coherence is not lost at the boundary.

10.1 Minimisation principle

• The prompt sent to the model must contain only the personal data strictly necessary for the task. The GDPR minimisation principle of Art. 5(1)(c) applies directly.
• Redaction / pseudonymisation before sending where feasible — replace names, e-mails and IDs with placeholders (<USER_X>, <EMAIL_REDACTED>) and remap them in the output.
• Where redaction is not feasible (e.g. tasks that require the literal content), the decision is recorded and reviewed at the mandate's cadence (Policy 38).

10.2 Explicit legal basis

Each operational use in which the agent sees PII has a declared GDPR legal basis — Art. 6 (consent, contract, legal obligation, legitimate interest, etc.) and, for special categories (Art. 9), a reinforced legal basis. The legal basis is part of the agent's mandate (Policy 38 — add the field legal_basis where applicable) or of the project's processing record, and it is revisited in the periodic reviews.

10.3 Processors

The model AI service vendor is a processor when it processes personal data on behalf of the organisation (GDPR, Art. 28); if the organisation is itself a processor, the AI service vendor is «another processor» (Art. 28(2) and (4)). The contractual clause set out in Policy 33 §10 applies:

• Contract with the processor (GDPR, Article 28(3)) with explicit clauses (retention, training opt-out, audit rights).
• Processing location documented; Standard Contractual Clauses (SCCs) or another valid mechanism for international transfers (GDPR Arts. 44–49) when the AI service vendor processes outside the EEA.
• No PII to AI service vendors outside the approved list (DEP-014).

10.4 Mandatory training opt-out for PII

When the content of the prompt includes personal data, the AI service vendor is contractually required not to use that content for future training of the model. Zero retention is preferred for PII; where the AI service vendor keeps operational logs, retention is minimised and its purpose declared.

10.5 Telemetry under the control of the deployer

Inference logs under the organisation's control (AI Act, Article 19(1), for the provider, and Article 26(6), for the deployer / GDPR Art. 5) comply with OPS-003 (retention: at least six months for high-risk AI systems, AI Act, Articles 19(1) and 26(6)) and OPS-012 (audit per tool invocation) with PII redaction in the args — the audit trail preserves enough to answer an audit without replicating the personal data.

10.6 Data subject rights

When the user's interaction with the agent generates personal data, the GDPR rights apply (access Art. 15, rectification Art. 16, erasure Art. 17, objection Art. 21). In particular:

• Erasure of the audit events under the deployer's control when the data subject exercises the right to be forgotten (subject to competing legal retention obligations).
• Non-retention by the AI service vendor — verified contractually. Where retention by the AI service vendor exists, the data subject must be able to exercise the right there too.

10.7 Proportionality

Requirement	L1	L2	L3
Minimisation / redaction before sending	Recommended	Mandatory where feasible	Mandatory (special categories always redacted)
Declared legal basis	Recommended	Mandatory	Mandatory (GRC review)
Processor with Article 28 clauses	Mandatory (whenever there is PII)	Mandatory	Mandatory + Legal review
Contracted training opt-out	Mandatory (whenever there is PII)	Mandatory	Mandatory
EEA location / SCCs where applicable	Mandatory (when there is PII and processing outside the EEA)	Mandatory	Mandatory (preference for processing in the EEA)
Redaction of PII in the audit events (OPS-012)	Recommended	Mandatory	Mandatory
Procedure for data subject rights	Recommended	Mandatory	Mandatory (incl. erasure under the deployer's control)

10.8 Anti-patterns

• ❌ Sending PII to an AI service vendor outside the approved list — shadow AI with GDPR risk.
• ❌ Logging prompts with PII without redaction in OPS-012 — the audit trail itself becomes a repository of personal data with no specific legal basis.
• ❌ Trusting that the AI service vendor "does not use it for training" without a contractual clause — operational statements do not replace Art. 28.
• ❌ Ignoring special categories (Art. 9 GDPR) in the prompt — health, biometric data for the purpose of uniquely identifying a natural person, racial or ethnic origin, etc. — or children's data (Art. 8), which require reinforced conditions that many chatbot use cases do not meet.
• ❌ Treating redaction as sufficient obfuscation — pseudonymisation (GDPR) is not anonymisation; pseudonymised PII remains personal data.

10.9 Crossover with the GDPR cross-check

For detailed alignment with the regulation, see the GDPR cross-check. This section maintains operational coherence at the AppSec ↔ GDPR boundary; the cross-check deals with the legal obligations in detail.

---

11. Review and audit of this policy

This policy must be reviewed annually or after any of the following events:

• An incident originating from an exposed or unrotated secret
• Adoption of a new secrets vault or cloud platform
• A change of supplier with an impact on integration keys

---

12. Normative and technical references

Reference	Relevance
SbD-ToE Ch. 07 - Secure CI/CD	Secrets management and injection in the pipeline; US-19 — AI agents as principals in the pipeline
SbD-ToE Ch. 09 - Containers and Images	Secrets kept out of images; workload identity
SbD-ToE Ch. 11 - Secure Deployment	Secrets in the deploy runtime
SbD-ToE Ch. 04 — Secure Architecture (ARC-015)	Agent as an isolated principal; least privilege per tool
Secure CI/CD Policy (17_policy-cicd-seguro.md)	Secret detection in the pipeline; log masking
Policy 38 — AI Agent Mandates	Operationalises REQ-AGN-001: mandate, ownership, kill-switch
Policy 16 — Use of Support Tools	A2+ operational rules for agents
NIST SP 800-207 — Zero Trust Architecture	Principles applied to non-human principals (including AI agents)
OWASP Secrets Management Cheat Sheet	Reference for good secrets management practices
HashiCorp Vault Documentation	Reference vault; dynamic secrets; OIDC
NIST SP 800-57	Key Management Guidelines
CIS Benchmark - Secrets Management	Reference controls
SSDF PO.5.2	Implement and maintain secure environments for software development