Outpost Credential Intelligence

Outpost Credential Intelligence adds a real-time credential leak detection layer directly at the outpost edge. Prompts are checked against a continuously updated database of known compromised credentials — API keys, tokens, and secrets — before being forwarded to the upstream provider.

When a credential match is detected, the outpost can block the request or redact the matched value, depending on the configured policy action.

How it works

Credential Intelligence uses a bloom filter to perform high-throughput matching with a bounded false positive rate and no sensitive data stored on the outpost:

The platform generates a compact bloom filter from the current credential breach database (sourced from HaveIBeenPwned, internal threat intelligence, and partner feeds).
The filter is published to a CDN endpoint and updated on a regular refresh schedule.
Each outpost downloads and caches the filter locally. Checks are performed in-memory — no network call is made at request time.
When a candidate credential extracted from a prompt matches the filter, the outpost emits a CredInt hit event and applies the configured policy action.

This architecture means Credential Intelligence works in air-gap deployments with a pre-imported filter file, and adds negligible latency to the proxy path.

Setup

Online mode (CDN refresh)

credential_intelligence:
  enabled: true
  mode: cdn
  cdn_url: https://credint.arbitex.ai/v1/filter.bloom
  refresh_interval_hours: 6
  policy_action: BLOCK   # BLOCK or REDACT

The outpost fetches the filter from cdn_url at startup and re-fetches every refresh_interval_hours. The filter is applied to all requests immediately after a successful download.

Air-gap mode (pre-imported filter)

credential_intelligence:
  enabled: true
  mode: airgap
  filter_path: /etc/arbitex/credint.bloom
  policy_action: BLOCK

In air-gap mode, the outpost reads the filter from a local file path. Refresh requires re-running the air-gap bundle generator with --include-credint to produce an updated credint.bloom file and copying it to the outpost. See Air-gap operations guide for bundle regeneration procedures.

CDN refresh schedule

The platform publishes new bloom filter snapshots when a new batch of credentials is ingested. The outpost checks for updates at the configured refresh_interval_hours interval (default: 6 hours). The refresh is a conditional GET — if the filter has not changed since the last download, no update is applied.

To force an immediate refresh without restarting the outpost:

POST /admin/credint/refresh

The admin API returns the new filter metadata (snapshot timestamp, entry count, false positive rate) on success.

Admin status panel

The outpost admin interface exposes a Credential Intelligence status panel at /admin/credint/status:

{
  "enabled": true,
  "mode": "cdn",
  "filter_loaded": true,
  "filter_snapshot_at": "2026-03-12T08:00:00Z",
  "filter_entry_count": 4200000,
  "filter_fp_rate": 0.001,
  "last_refresh_at": "2026-03-12T08:00:04Z",
  "last_refresh_status": "ok",
  "hits_last_24h": 3,
  "policy_action": "BLOCK"
}

Field	Description
`filter_loaded`	Whether a filter is currently active
`filter_snapshot_at`	When the active filter snapshot was generated
`filter_entry_count`	Number of credential hashes in the filter
`filter_fp_rate`	Configured false positive rate (typically 0.001 = 0.1%)
`last_refresh_at`	Timestamp of the most recent filter download attempt
`last_refresh_status`	`"ok"`, `"unchanged"`, `"error"`
`hits_last_24h`	Credential matches detected in the last 24 hours

False positive handling

Bloom filters have an inherent false positive rate. A false positive occurs when the filter indicates a credential match but the value is not actually a known-compromised credential.

At the default 0.1% false positive rate, roughly 1 in 1000 credential-like strings will produce a spurious hit. For most deployments this is acceptable. If false positives are causing production disruption:

Switch to REDACT action instead of BLOCK — the value is masked but the request proceeds.
Report the false positive via the admin panel using the POST /admin/credint/report-fp endpoint, which submits the hash of the matched value to the platform for exclusion in the next filter snapshot.
Increase the filter size — contact Arbitex support to request a lower-fp-rate filter build for your deployment.

False positive reports are collected and applied to the next filter generation cycle (typically within 24 hours for confirmed false positives).

Audit events

Each Credential Intelligence hit generates an audit event with the following fields:

Field	Value
`action`	`credint_block` or `credint_redact`
`credint_hit`	`true`
`credint_bucket`	Bucket identifier for the matched hash category
`credint_confidence`	Confidence score (0.0–1.0)

These events are visible in the audit log with action=credint_block or action=credint_redact. Use the Audit event API to query them.