Model Secret Rules

Detects credentials, private keys, tokens, and sensitive data embedded in model artifacts and adjacent files.

Definition

The Secrets rule family turns findings on this surface into actionable records with rule ID, severity, CWE, OWASP LLM mapping, owner, release decision, and retest command.

Model repositories often include notebooks, configs, cards, and logs. A leaked key in a model bundle can become immediate cloud, API, or data access.

Canonical help URL

Supported inputs

model cards
configs
tokenizer files
notebooks
binary strings
container layers

Typical attack scenarios

A training notebook stores an API key in the release bundle.
A model card includes a bearer token from a demo curl command.
A private key remains inside a checkpoint directory.

Detection logic

Sentinel ties Secrets evidence to reproducible signals such as file path, metadata, opcode, AST node, manifest field, dependency, or archive entry. The same signal should disappear when the finding is closed.

Triage

Do not read Secrets findings as scanner noise. Verify the evidence first, map the finding to a severity-based release decision, and then produce closure evidence with the same Sentinel command.

Operational checklist

Source: where did the file, manifest, prompt, archive, or dependency come from?
Impact: code execution, data leakage, supply chain, or resource consumption?
Control: allowlist, hash, sandbox, egress policy, or secret rotation?
Evidence: does the same rule category return clean after the fix?

Remediation

Remediation should change the risk boundary, not merely silence the finding: remove executable formats, pin source or hash, narrow tool permissions, rotate secrets, or add runtime sandboxing.

CI policy

sentinel-policy.yml

category: MODEL-SECRET
fail_on:
  - CRITICAL
  - HIGH
ticket_on:
  - MEDIUM
retest: "sentinel secrets-scan ./repo/"

Rule index

Rule ID	Severity	Title	CWE	Fix Hint
MODEL-SECRET-API-KEY	CRITICAL	API Key in Model Bundle	CWE-798	Rotate exposed API keys immediately.
MODEL-SECRET-PRIVATE-KEY	CRITICAL	Private Key in Artifact	CWE-522	Never publish private keys in model repositories.
MODEL-SECRET-PII	HIGH	Sensitive Personal Data in Model Context	CWE-200	Keep real user data out of model release bundles.

MODEL-SECRET-API-KEY — API Key in Model Bundle

CRITICAL

Rule ID	MODEL-SECRET-API-KEY
Category	MODEL-SECRET
Severity	CRITICAL
CWE	CWE-798
OWASP LLM	LLM02 — Sensitive Information Disclosure, LLM03 — Supply Chain
FP Risk	LOW
Owner	Security operations and the relevant secret owner
Release decision	Block release; do not promote the artifact or code path until it is isolated.

Description

Detects high-confidence API keys, tokens, and credentials in model-adjacent files.

Why it matters

Model repositories often include notebooks, configs, cards, and logs. A leaked key in a model bundle can become immediate cloud, API, or data access.

When it fires

Sentinel fires this rule in the Secrets category when it sees entropy + provider regex match in configs, model cards, notebooks, or extracted binary strings.. The finding should be reported with reproducible evidence such as file name, metadata, opcode, AST node, or manifest field.

Evidence format

Entropy + provider regex match in configs, model cards, notebooks, or extracted binary strings.

Expected evidence

The report should include the affected file or manifest path, observed signal, rule ID, severity, owner, and retest command required for closure.

False-positive notes

False-positive probability is low. If evidence points directly to a file, opcode, secret pattern, path, or manifest field, treat it as real and require closure evidence.

Triage

Operational checklist

Owner: Security operations and the relevant secret owner.
Decision: Block release; do not promote the artifact or code path until it is isolated.
Evidence: Entropy + provider regex match in configs, model cards, notebooks, or extracted binary strings.
Closure: sentinel secrets-scan ./repo/ must return clean output.

How to fix

Revoke and rotate the credential, remove it from history, and publish a cleaned release.

CLI

sentinel secrets-scan ./repo/

Policy example

sentinel-policy.yml

rules:
  MODEL-SECRET-API-KEY:
    owner: "Security operations and the relevant secret owner"
    fail_on: ["CRITICAL", "HIGH"]
    retest: "sentinel secrets-scan ./repo/"

Expected output

MODEL-SECRET-API-KEY CRITICAL
API Key in Model Bundle
Rotate exposed API keys immediately.

Example

Bad

OPENAI_API_KEY=sk-live-example
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Good

# .env.example
OPENAI_API_KEY=<set in secret manager>

Related rules

MODEL-SECRET-PRIVATE-KEY: Private Key in Artifact
MODEL-SECRET-PII: Sensitive Personal Data in Model Context

MODEL-SECRET-PRIVATE-KEY — Private Key in Artifact

CRITICAL

Rule ID	MODEL-SECRET-PRIVATE-KEY
Category	MODEL-SECRET
Severity	CRITICAL
CWE	CWE-522
OWASP LLM	LLM02 — Sensitive Information Disclosure
FP Risk	LOW
Owner	Security operations and the relevant secret owner
Release decision	Block release; do not promote the artifact or code path until it is isolated.

Description

Flags private keys or signing keys shipped with model artifacts.

Why it matters

Model repositories often include notebooks, configs, cards, and logs. A leaked key in a model bundle can become immediate cloud, API, or data access.

When it fires

Sentinel fires this rule in the Secrets category when it sees pem private key blocks, ssh private key markers, or key-like binary strings.. The finding should be reported with reproducible evidence such as file name, metadata, opcode, AST node, or manifest field.

Evidence format

PEM private key blocks, SSH private key markers, or key-like binary strings.

Expected evidence

The report should include the affected file or manifest path, observed signal, rule ID, severity, owner, and retest command required for closure.

False-positive notes

False-positive probability is low. If evidence points directly to a file, opcode, secret pattern, path, or manifest field, treat it as real and require closure evidence.

Triage

Operational checklist

Owner: Security operations and the relevant secret owner.
Decision: Block release; do not promote the artifact or code path until it is isolated.
Evidence: PEM private key blocks, SSH private key markers, or key-like binary strings.
Closure: sentinel secrets-scan ./repo/ must return clean output.

How to fix

Revoke the key, rebuild trust chains if needed, and remove the key from all published artifacts.

CLI

sentinel secrets-scan ./repo/

Policy example

sentinel-policy.yml

rules:
  MODEL-SECRET-PRIVATE-KEY:
    owner: "Security operations and the relevant secret owner"
    fail_on: ["CRITICAL", "HIGH"]
    retest: "sentinel secrets-scan ./repo/"

Expected output

MODEL-SECRET-PRIVATE-KEY CRITICAL
Private Key in Artifact
Never publish private keys in model repositories.

Example

Bad

OPENAI_API_KEY=sk-live-example
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Good

# .env.example
OPENAI_API_KEY=<set in secret manager>

Related rules

MODEL-SECRET-API-KEY: API Key in Model Bundle
MODEL-SECRET-PII: Sensitive Personal Data in Model Context

MODEL-SECRET-PII — Sensitive Personal Data in Model Context

HIGH

Rule ID	MODEL-SECRET-PII
Category	MODEL-SECRET
Severity	HIGH
CWE	CWE-200
OWASP LLM	LLM02 — Sensitive Information Disclosure
FP Risk	MEDIUM
Owner	Security operations and the relevant secret owner
Release decision	Treat as a release gate; remediation or explicit risk acceptance is required.

Description

Detects PII-like values in model cards, examples, datasets, logs, or prompt fixtures.

Why it matters

Model repositories often include notebooks, configs, cards, and logs. A leaked key in a model bundle can become immediate cloud, API, or data access.

When it fires

Sentinel fires this rule in the Secrets category when it sees configured pii detectors match emails, national ids, phone numbers, addresses, or customer identifiers.. The finding should be reported with reproducible evidence such as file name, metadata, opcode, AST node, or manifest field.

Evidence format

Configured PII detectors match emails, national IDs, phone numbers, addresses, or customer identifiers.

Expected evidence

The report should include the affected file or manifest path, observed signal, rule ID, severity, owner, and retest command required for closure.

False-positive notes

False-positive probability is medium. Verify source, expected use, and owner first; add an allowlist if needed, but do not remove evidence from the report.

Triage

Operational checklist

Owner: Security operations and the relevant secret owner.
Decision: Treat as a release gate; remediation or explicit risk acceptance is required.
Evidence: Configured PII detectors match emails, national IDs, phone numbers, addresses, or customer identifiers.
Closure: sentinel secrets-scan ./repo/ must return clean output.

How to fix

Remove sensitive examples, regenerate synthetic fixtures, and review data handling controls.

CLI

sentinel secrets-scan ./repo/

Policy example

sentinel-policy.yml

rules:
  MODEL-SECRET-PII:
    owner: "Security operations and the relevant secret owner"
    fail_on: ["CRITICAL", "HIGH"]
    retest: "sentinel secrets-scan ./repo/"

Expected output

MODEL-SECRET-PII HIGH
Sensitive Personal Data in Model Context
Keep real user data out of model release bundles.

Example

Bad

OPENAI_API_KEY=sk-live-example
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Good

# .env.example
OPENAI_API_KEY=<set in secret manager>

Related rules

MODEL-SECRET-API-KEY: API Key in Model Bundle
MODEL-SECRET-PRIVATE-KEY: Private Key in Artifact

References

PreviousRAR NextSize limits