APRF-12 · Secrets

Purpose

Prevent API keys, credentials, tokens, and other secrets from entering prompts, completions, logs, training/fine-tuning corpora, or client-visible surfaces.

Mandatory checks

Gate controls. Each check is pass/fail via artifact + pass condition. Expected from the annotated capability level when the system meets the minimum criticality tier.

SEC2-M1L2 · ManagedTier 1 · InternalhybridE3
Production secrets shall resolve from a secrets manager at runtime and must not appear in repos, prompt registries, or client bundles—proven by secrets-manager wiring plus a fresh secret-scan covering prompts/fixtures, not by CI ${{ secrets.* }} alone.
Artifact
Secrets-manager / sealed-secrets / cloud secret-ref wiring for production runtime; CI/repo secret-scan config covering prompts and fixtures; Latest secret-scan report with 0 privileged findings (measuredAt ≤90 days); Attest or inventory showing 100% of production runtime secrets resolve from the secrets manager
Pass condition
Secrets-manager wiring covers production runtime secrets; 100% of those secrets resolve from the secrets manager; the latest secret scan covering repos, prompt registries, and client bundles finds 0 privileged production secrets (measuredAt ≤90 days). If no production runtime secrets exist, score NOT_APPLICABLE.
Why this control exists
Threat map
Keep production secrets out of prompts, source control, and notebooks.
Threats mitigated
Secret LeakagePrivilege EscalationIdentity SpoofingData Exfiltration
Protects
SecretsIdentityAPIsInfrastructure
MITRE: ATLAS AML.T0055 · ATLAS AML.T0083 · ATLAS AML.T0037 · ATT&CK T1552 · ATT&CK T1552.001 · ATT&CK T1078
Credentials embedded in prompts and agent configuration are recoverable through prompt extraction and repository search, and they are almost never rotated. Centralizing them in a secrets manager removes the unsecured-credential path that these techniques depend on.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
SEC2-M2L3 · DefinedTier 2 · ProductionhybridE3
Logging and tracing pipelines shall redact secret-like patterns—proven by redaction/masking config plus a fresh canary harness that injects API key/bearer/AWS-key patterns and shows 100% redaction in persisted logs/traces, not by filter code alone.
Artifact
Redaction/masking config for logging and/or tracing pipelines; Synthetic secret-injection canary harness covering API key/bearer/AWS-key patterns; Canary results showing 100% detection/redaction in persisted logs/traces (measuredAt ≤90 days)
Pass condition
Logging/tracing secret-redaction config is present; a canary harness injects synthetic API key/bearer/AWS-key patterns and shows 100% redaction in persisted logs/traces (measuredAt ≤90 days). If no production logging or tracing pipelines exist, score NOT_APPLICABLE.
Why this control exists
Threat map
Prevent secrets from being persisted into logs and traces.
Threats mitigated
Secret LeakageSensitive Information DisclosurePrivilege Escalation
Protects
SecretsLogsAudit Trail
MITRE: ATLAS AML.T0055 · ATLAS AML.T0037 · ATT&CK T1552 · ATT&CK T1552.001
AI traces capture tool arguments and headers where credentials commonly appear, then copy them into log stores with much broader access. Redaction at ingest prevents observability from becoming the easiest credential target in the environment.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
SEC2-M3L3 · DefinedTier 2 · ProductionhybridE3
Provider and cloud keys shall be rotatable and least-privilege scoped, and client apps shall not hold privileged keys—proven by a key inventory with scope and rotation evidence plus a client-bundle/scan report, not by secrets-manager presence alone.
Artifact
Inventory of production provider/cloud keys with least-privilege scope; Rotation dates or provider-managed short-lived credential evidence within policy; Client bundle/scan report showing 0 privileged provider/cloud keys (measuredAt ≤90 days)
Pass condition
Inventory of production provider/cloud keys exists; 0 privileged provider/cloud keys are embedded in client apps; 100% of production keys have a documented least-privilege scope and are within rotation policy (≤90 days or provider-managed short-lived credentials) (measuredAt ≤90 days). If no production provider/cloud keys exist, score NOT_APPLICABLE.
Why this control exists
Threat map
Ensure AI credentials are narrowly scoped, rotatable, and never shipped to clients.
Threats mitigated
Secret LeakageDenial of WalletPrivilege EscalationIdentity Spoofing
Protects
SecretsIdentityAPIsCost
MITRE: ATLAS AML.T0055 · ATLAS AML.T0040 · ATLAS AML.T0034 · ATT&CK T1552 · ATT&CK T1078
Provider keys embedded in mobile or browser clients are trivially extracted and then used for free inference billed to the owner. Scoping and rotation limit both the reach and the lifetime of any key that does escape.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

Evidence required

Secrets management design
Redaction configuration evidence
Key rotation records

Recommended checks

Strengthen posture beyond the gate. Same measurable structure; non-blocking unless elevated by organizational policy.

SEC2-R1L3 · DefinedTier 2 · ProductionhybridE3
Pre-commit and CI secret scanning shall cover application code, prompts, and fixtures and block on high-confidence secrets—proven by scanner config plus a fresh green main-branch (or PR-merge) scan ≤7 days, not by a secrets-manager or a single ≤90-day content scan alone.
Artifact
Pre-commit secret-scan hook/config covering prompts and fixtures; CI secret-scan workflow covering prompts and fixtures; Proof scanning blocks on high-confidence secrets; Latest green main-branch or PR-merge secret-scan evidence (measuredAt ≤7 days)
Pass condition
Pre-commit and CI secret scanning are configured; both cover application code, prompts, and fixtures; scanning blocks on high-confidence secrets; the latest green main-branch scan (or last PR-merge scan evidence) is ≤7 days (measuredAt ≤7 days). If no application code, prompts, or fixtures exist, score NOT_APPLICABLE.
Why this control exists
Threat map
Detect committed secrets before they reach a shared repository.
Threats mitigated
Secret LeakageSupply Chain Compromise
Protects
SecretsIdentity
MITRE: ATLAS AML.T0055 · ATT&CK T1552 · ATT&CK T1552.001
Prompt templates, evaluation fixtures, and notebooks are common secret-leak locations that default scanner configurations often exclude. Extending scanning to those paths closes the gap before a credential becomes permanent repository history.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
SEC2-R2L4 · Quantitatively ManagedTier 2 · ProductionhybridE3
Egress controls shall limit where runtime credentials can be used—proven by an allowlist/policy for runtimes that hold credentials plus ≥1 observed deny event in test or production logs within 90 days, not by secrets-manager presence or model-path trust-boundary docs alone.
Artifact
Egress allowlist/policy config for runtimes that hold credentials; Documented allowed destinations for those credentials; Sample deny (and optionally allow) logs proving enforcement (measuredAt ≤90 days)
Pass condition
Egress allowlist/policy is configured for production runtimes that hold credentials; destinations are documented; ≥1 deny event is observed in test or production logs proving enforcement (measuredAt ≤90 days). If no production runtimes hold credentials, score NOT_APPLICABLE.
Why this control exists
Threat map
Constrain where a leaked runtime credential can actually be used from.
Threats mitigated
Secret LeakageData ExfiltrationPrivilege Escalation
Protects
SecretsNetworkData
MITRE: ATLAS AML.T0025 · ATLAS AML.T0055 · ATT&CK T1041 · ATT&CK T1567
Network and identity conditions on credential use mean a stolen token is not usable from attacker-controlled infrastructure. This devalues any credential that escapes the other secrets controls.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
SEC2-R3L4 · Quantitatively ManagedTier 2 · ProductionhybridE3
Fine-tune and eval corpora shall be scanned for secrets/PII before publish—proven by a publish-blocking scan gate plus linked scan reports for 100% of corpora published in the last 90 days, not by dataset cards or repo secret scanning alone.
Artifact
Dataset secret/PII scan gate config before fine-tune or eval corpus publish; Proof publish is blocked when critical findings are open; Linked scan reports covering 100% of fine-tune/eval corpora published in the last 90 days (measuredAt ≤90 days)
Pass condition
A secret/PII scan gate is configured before fine-tune or eval corpus publish; publish is blocked when critical findings are open; 100% of fine-tune/eval corpora published in the last 90 days have a linked scan report (measuredAt ≤90 days). If no fine-tune or eval corpus publish exists, score NOT_APPLICABLE.
Why this control exists
Threat map
Prevent secrets and sensitive data from being baked into models or published corpora.
Threats mitigated
Secret LeakageSensitive Information DisclosureData and Model Poisoning
Protects
SecretsDataModels
MITRE: ATLAS AML.T0055 · ATLAS AML.T0057 · ATLAS AML.T0020
Secrets present in fine-tuning data can be memorized and later emitted by the model, at which point rotation is the only remedy and the model must be retrained. Scanning before training or publication is the last point at which that outcome can still be prevented.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

More detailPhilosophy, failures, practices, validations, examples, crosswalks, and evolution

Engineering philosophy

Secrets never belong in context windows as data. Treat any path that can echo or store model I/O as a potential secret exfiltration channel.

Why it matters

Models and logs are high-bandwidth leak channels. A single leaked provider key or cloud credential can escalate into full environment compromise and unbounded spend.

Common failures

API keys in frontend code or mobile apps
Secrets pasted into prompts for 'debugging'
Tool results returning credentials into context
Fine-tuning on datasets that include secrets

Severity & risk

Severity: critical; Impact if violated
Risk level: critical; Typical residual risk (impact × likelihood)

Engineering best practices

Use short-lived credentials for tools
Strip Authorization headers and env dumps from error payloads to models
Educate builders: never ask the model to 'remember' a key
Separate build-time and runtime secrets

Automatic validations

Secret scanners in CI and image builds
Runtime detectors blocking known secret formats in prompts
Alerts on anomalous provider API key usage

Manual validations

Review of new logging fields for secret risk
Incident drills for leaked model API keys

Examples

A developer tool refuses to send .env contents into an LLM chat
Tracing middleware redacts AWS keys and bearer tokens before persistence

References

Crosswalks

Show 17 peer mappingsexpand

Secure & Resilient Secure and Resilient
NIST AI Risk Management Framework · aligns-with
§7 Support
ISO/IEC 42001 · partial
LLM02 Sensitive Information Disclosure
OWASP Top 10 for Large Language Model Applications · supports
LLM07 System Prompt Leakage
OWASP Top 10 for Large Language Model Applications · aligns-with
C2.1 Prompt Injection Defenses
OWASP AI Application Security Verification Standard (AISVS) · supports
C5.1 Authentication
OWASP AI Application Security Verification Standard (AISVS) · aligns-with
C5.2 AI Resource Authorization & Classification
OWASP AI Application Security Verification Standard (AISVS) · supports
C5.3 Multi-Tenant Isolation
OWASP AI Application Security Verification Standard (AISVS) · partial
C7.3 Output Safety
OWASP AI Application Security Verification Standard (AISVS) · supports
C8.1 Access Controls on Memory & RAG Indices
OWASP AI Application Security Verification Standard (AISVS) · supports
C12.1 Request & Response Logging
OWASP AI Application Security Verification Standard (AISVS) · supports
CWE-200 Exposure of Sensitive Information
OpenCRE (Open Common Requirements Enumeration) · aligns-with
CWE-327 Use of a Broken or Risky Cryptographic Algorithm
OpenCRE (Open Common Requirements Enumeration) · partial
CWE-798 Use of Hard-coded Credentials
OpenCRE (Open Common Requirements Enumeration) · aligns-with
CC6 Logical and Physical Access
SOC 2 Trust Services Criteria · evidence-for
C1 Confidentiality
SOC 2 Trust Services Criteria · evidence-for
Security Security
AWS Well-Architected Framework · aligns-with

Future evolution

Native provider APIs that never accept raw secrets in prompt fields, with automatic scrubbing attestations.