DCL Secret Leak Detector

Instruction-only runtime secret and credential leak detector for AI agents and LLM pipelines. Catches API keys, tokens, private keys, database URLs, and .env...

DCL Secret Leak Detector — Leibniz Layer™

Publisher: @daririnch · Fronesis Labs
Version: 1.0.0
Part of: Leibniz Layer™ Security Suite

---

What this skill does

DCL Secret Leak Detector scans AI agent outputs, tool results, and pipeline data for exposed secrets and credentials — before they reach users, logs, or downstream systems.

This skill is 100% instruction-only. No text is sent to any external server. No webhook is called. The entire analysis runs inside the agent's context window using the detection checklist below. The scanned text never leaves the agent.

Every detection produces a deterministic dcl_fingerprint — a self-contained audit proof compatible with the Leibniz Layer™ chain.

What gets detected

Category	Pattern class
api_key	Provider-prefixed keys: OpenAI, Anthropic, Stripe, GitHub, Slack patterns
cloud_credential	AWS access key IDs, GCP service account fragments, Azure client secrets
token	Bearer tokens, JWT strings, OAuth access tokens, high-entropy credential-context strings
private_key_pem	PEM header/footer blocks for any private key type
database_url	Connection strings with embedded credentials: proto://user:pass@host
connection_string	ADO.NET, ODBC, SQLAlchemy strings containing password fields
env_assignment	.env-style lines where variable name matches known secret patterns
webhook_secret	Signed secrets for Stripe, GitHub, Twilio webhook endpoints
internal_endpoint	URLs containing API keys or tokens as query parameters

---

How to run a scan

The user provides text to scan directly in the conversation — model output, tool result, generated code, retrieved document chunk, or any pipeline data. This skill makes no network requests and does not transmit content anywhere.

Step 1 — Confirm content is in context

Verify the text to scan is present in the conversation. If not provided, ask the user to paste it.

Step 2 — Compute content fingerprint

content_hash = SHA-256(raw text submitted for scanning)

Record this as the immutable identifier for this scan event.

Step 3 — Run the detection checklist

Work through every category in the Detection Checklist below. For each match found, record:

• type — which category triggered
• provider — which service the credential belongs to (if identifiable)
• position — approximate character offset in the text
• redacted_sample — masked version showing only first 2 and last 4 chars
• severity — critical, major, or minor

If no patterns match a category, mark it CLEAR.

Step 4 — Apply verdict logic

Condition	Verdict
Any finding at any severity	NO_COMMIT
No findings	COMMIT

Any detected secret, regardless of severity, results in NO_COMMIT. Secrets have no safe threshold.

Step 5 — Compute DCL proof

analysis_content  = verdict + all findings serialized + timestamp
analysis_hash     = SHA-256(analysis_content)
dcl_fingerprint   = "DCL-SLD-" + date + "-" + content_hash[:8] + "-" + analysis_hash[:8]

---

Detection Checklist

Work through each item. Mark CLEAR or record finding with redacted evidence.

S1 — API Keys (Critical)

• Short prefix followed by 20+ alphanumeric chars matching known provider key formats
• Live payment key prefixes (distinct from test/publishable key prefixes)
• Version control platform personal access token prefixes
• Messaging platform bot/user token prefixes
• Email delivery platform key prefixes
• Communications platform account SID patterns

S2 — Cloud Credentials (Critical)

• Cloud provider access key ID patterns (uppercase alpha + numeric, fixed length)
• Cloud provider secret key context: high-entropy base64 string near credential field names
• Service account JSON fragments: private key fields, client email fields
• Client secret values in tenant/application ID combinations

S3 — Tokens & JWTs (Critical)

• JWT pattern: three base64url segments separated by dots, first segment decodes to JSON header
• Bearer token context: authorization header values or token field assignments with high-entropy values
• High-entropy strings (40+ chars) appearing in credential assignment context

S4 — Private Keys (Critical)

• PEM block opening markers: -----BEGIN + key type descriptor + -----
• PEM block closing markers: -----END + key type descriptor + -----
• Base64-encoded content between PEM markers

S5 — Database & Connection Strings (Critical)

• URI with embedded credentials: protocol + :// + username + : + password + @ + host
• Database protocols: postgres, mysql, mongodb, redis, amqp, and their variants
• ORM/driver connection strings containing password parameter fields
• Connection strings with User ID= and Password= or Pwd= fields

S6 — Environment Variable Assignments (Major)

• Variable assignments where name contains: KEY, SECRET, TOKEN, PASS, PWD, CREDENTIAL, AUTH
• Assignment format: VARNAME=value where value is non-trivial (not placeholder, not empty)
• Shell export statements with credential variable names

S7 — Webhook & Signed URL Secrets (Major)

• Webhook secret prefixes for known payment and developer platforms
• Signed URL patterns where the signature or secret appears as a query parameter

S8 — Internal Endpoints with Auth (Minor → Major)

• Internal hostnames (.internal, .local, .corp, .intra) with auth query parameters
• Any URL where api_key=, apikey=, token=, secret=, or access_token= appears with a non-trivial value (Major)

---

Output schema

{
  "verdict": "COMMIT | NO_COMMIT",
  "risk_score": 0.0,
  "content_hash": "sha256:<64-char hex>",
  "analysis_hash": "sha256:<64-char hex>",
  "dcl_fingerprint": "DCL-SLD-2026-04-14-<content_hash[:8]>-<analysis_hash[:8]>",
  "detections": [
    {
      "type": "api_key",
      "provider": "identified provider name",
      "redacted_sample": "[PREFIX]-****...****[SUFFIX]",
      "position": 87,
      "severity": "critical"
    }
  ],
  "detection_count": 0,
  "categories_checked": ["S1","S2","S3","S4","S5","S6","S7","S8"],
  "categories_clear": ["S1","S2","S3","S4","S5","S6","S7","S8"],
  "timestamp": "2026-04-14T09:00:00Z",
  "powered_by": "DCL Secret Leak Detector · Leibniz Layer™ · Fronesis Labs"
}

detections is an empty array [] when verdict is COMMIT.

---

Secret Leak Detector vs DCL Sentinel Trace

These two skills are complementary, not competing. Run both.

	DCL Sentinel Trace	DCL Secret Leak Detector
Focus	Personal identity data	Technical credentials
Catches	Emails, phones, SSNs, IBANs, card PANs	API keys, tokens, private keys, DB URLs
Regulation	GDPR, HIPAA	SOC 2, ISO 27001, internal SecOps
Primary risk	Privacy breach	Security breach / credential compromise
External calls	Via webhook	None — instruction-only

A response can be PII-clean and still contain a live credential. Both checks are necessary for complete output coverage.

---

Where Secret Leak Detector fits in the DCL pipeline

Untrusted input
        │
        ▼
DCL Prompt Firewall          ← blocks malicious input
        │ COMMIT
        ▼
      LLM call
        │
        ▼
DCL Policy Enforcer          ← compliance & jailbreak check
        │ COMMIT
        ▼
DCL Sentinel Trace           ← PII redaction
        │ COMMIT
        ▼
DCL Secret Leak Detector     ← credential & secret scan (instruction-only)
        │ COMMIT
        ▼
DCL Output Sanitizer         ← final sweep: toxic, unsafe commands
        │ COMMIT
        ▼
DCL Semantic Drift Guard     ← hallucination & grounding check
        │ IN_COMMIT
        ▼
Safe to deliver

---

High-risk agent patterns

Coding agents — generate shell scripts, Dockerfiles, CI configs, Terraform. Common vector for hardcoded credentials appearing in generated output.

DevOps / infrastructure agents — read deployment configs, env files, Kubernetes secrets. May quote them verbatim in responses.

RAG pipelines over internal docs — internal wikis and runbooks routinely contain credentials left by engineers. Retrieved chunks can carry them into LLM context and outputs.

Tool-calling agents — an agent that calls an API internally may reproduce the key in its reasoning trace or final response.

---

Privacy & Data Policy

This skill is operated by Fronesis Labs and is 100% instruction-only.

No data leaves the agent. The text submitted for scanning is analyzed entirely within the agent's context window. No content is transmitted to any server — including Fronesis Labs infrastructure.

No retention. Nothing is stored, logged, or transmitted. The only artifact produced is the structured JSON output and dcl_fingerprint, which remain within the agent's session unless the caller saves them.

Detected secrets: Only redacted samples are included in output. Raw credential values are never reproduced in the result.

Full policy: https://fronesislabs.com/#privacy · Browse the full DCL Security Suite: hub.fronesislabs.com · Questions: [e-mail]

---

Related skills

• dcl-sentinel-trace — PII redaction and identity exposure detection
• dcl-prompt-firewall — Input-layer injection and jailbreak detection
• dcl-output-sanitizer — Final output sweep: toxic content, unsafe commands
• dcl-secret-leak-detector-crypto — Specialist version for wallet keys, seed phrases, exchange credentials

Leibniz Layer™ · Fronesis Labs · fronesislabs.com