Credential Intelligence

Credential Intelligence (CredInt) checks credential-like material found in AI traffic against a corpus of 861M+ compromised credentials. When the gateway’s 3-tier DLP pipeline detects a credential — a password, API key, token, or connection string — CredInt determines whether that specific credential has appeared in known breach data. A CredInt match does not simply mean a credential is present; it means the credential has already been exposed and is likely in active use by attackers.

CredInt adds a second signal to DLP detection:

• DLP: “This request contains a credential” (detection)
• CredInt: “This credential has been seen in breach data” (exposure assessment)

flowchart TD
    DLP["DLP pipeline detects\ncredential-like material"]
    DLP --> Hash["SHA-1 hash credential"]
    Hash --> Prefix["Extract 8-char prefix"]
    Prefix --> Bloom{"Bloom filter\nprefix lookup"}
    Bloom -- "no match" --> Safe["credint_hit: false\nNot in breach corpus"]
    Bloom -- "prefix match" --> Full{"Full hash check\nagainst prefix bucket"}
    Full -- "match" --> Hit["credint_hit: true\nAssign frequency bucket"]
    Full -- "no match" --> Safe

What CredInt does

CredInt is a Bloom filter data structure loaded at startup with a corpus of 861M+ compromised credentials indexed by SHA-1 prefix, following the k-anonymity model used by the Have I Been Pwned (HIBP) service:

1. The gateway extracts credential-like material detected by the DLP pipeline
2. The credential is hashed with SHA-1
3. The first 8 characters of the hash (the prefix) are looked up in the Bloom filter
4. If the prefix matches, the full hash is checked against corpus entries for that prefix
5. A match means the credential has appeared in at least one known breach dataset

The Bloom filter is loaded entirely into memory at startup. Lookups are sub-millisecond with no network overhead — there is no external API call and no runtime dependency on the HIBP service.

How it integrates with the DLP pipeline

CredInt runs in the payload analysis stage, alongside the DLP pipeline. It does not run independently — it processes only credentials that the DLP pipeline has already identified. The integration is:

• Asynchronous and non-blocking. CredInt lookups run concurrently with DLP processing. If the Bloom filter lookup exceeds the processing window, the request continues without waiting. CredInt fields in the audit log are set to null if the check did not complete.
• Fail-open. If CredInt encounters an error (memory pressure, corrupted corpus data), the gateway continues processing the request. A failed CredInt check does not block the request.
• Automatic health monitoring. After 3 consecutive CredInt failures, the module disengages for 60 seconds before attempting to recover. This prevents a CredInt fault from adding latency to every request during a failure condition.

Configuration

CredInt is enabled at the platform level. No per-organization configuration is required. When the corpus is loaded and healthy, CredInt runs automatically for all organizations.

The /readyz health check endpoint includes a credint component that reports whether the Bloom filter corpus is loaded and operational:

GET /readyz

{
  "status": "ok",
  "components": {
    "credint": "ok",
    "dlp_tier1": "ok",
    "dlp_tier2": "ok",
    "dlp_tier3": "ok"
  }
}

If credint reports degraded or unavailable, CredInt checks are suspended for all organizations until the corpus reloads successfully.

What happens on a hit

When CredInt detects a match:

1. The audit log entry for that request is written with credint_hit: true
2. The frequency_bucket field is populated with the exposure severity
3. The finding is included in the SIEM event forwarded to your connected platform

Important: A CredInt hit does not automatically block the request. CredInt enriches the audit log and feeds into policy rule conditions (via user_risk_score_min), but the enforcement action is determined by your Policy Engine configuration. To block requests where a CredInt hit is detected, configure a policy rule that references the appropriate risk score threshold.

Frequency buckets

When CredInt detects a match, it assigns a frequency bucket indicating how widely the credential has been exposed across breach datasets:

Bucket	Meaning
Critical	Credential appears in multiple major breach datasets and is likely in active use by attackers
High	Credential appears in at least one major breach dataset
Medium	Credential appears in smaller or older breach datasets
Low	Credential appears in a single minor dataset

Frequency bucket assignments are computed at corpus build time, not at query time. A Critical bucket credential is one the corpus has already classified as widely circulated among threat actors.

False positive rate and handling

The Bloom filter is configured with a 0.1% false positive rate:

• A match (credint_hit: true) means the credential was found in breach data with 99.9% confidence
• A non-match (credint_hit: false) is definitive — the credential is not in the corpus

Approximately 1 in 1,000 lookups may incorrectly report a match. If your security team investigates a credint_hit and determines the credential is not compromised, record this assessment in your case management system alongside the sha1_prefix value from the audit log entry. The audit log stores the 8-character SHA-1 prefix rather than the full hash or the credential itself — this supports cross-request correlation without retaining the sensitive material.

False positives do not indicate a system error; they are a known characteristic of the Bloom filter design and are within the configured tolerance.

Audit log fields

Every request processed by the gateway includes six CredInt fields in the audit log entry:

Field	Type	Description
credint_enabled	boolean	Whether CredInt was active for this request
credint_hit	boolean	Whether any credential material in the request matched the corpus
frequency_bucket	string	Exposure severity: Critical, High, Medium, Low, or null if no match
context_type	string	The context in which the credential appeared: password, api_key, connection_string, or similar
sha1_prefix	string	The 8-character SHA-1 prefix used for the lookup — not the full credential hash
credint_confidence	float	Detection confidence score (0.0–1.0)

When CredInt is enabled but the DLP pipeline finds no credential material, credint_hit is false and the remaining fields are null.

See also

• DLP Overview — the 3-tier DLP pipeline that detects credentials before CredInt checks them
• Audit Log — how CredInt fields appear in audit exports and SIEM integration
• Policy Rule Reference — user_risk_score_min condition for risk-based enforcement using CredInt findings