Skip to main content

Webhook Notifications and SIEM

Cloud Enterprise

Webhook delivery is a Cloud Enterprise feature. Basic has no webhook infrastructure, no security_events audit trail to fire from, and no Console where subscriptions can be configured. Every workflow on this page (Splunk HEC, Datadog, Slack, PagerDuty) requires Cloud Enterprise.

Memory Defense publishes a webhook event for every non-ALLOW decision and ships the captured detail to whatever security operations tooling you already run. Splunk, Datadog, Slack, and PagerDuty are the common destinations.

What Gets Delivered​

Memory Defense publishes a memory_defense.violation webhook event for every non-ALLOW decision (REDACT, BLOCK). Deliveries are HMAC-signed with the bank's webhook secret. The payload is MemoryDefenseViolationData with fields detector, severity, action_taken, memory_unit_id, receipt_uri, document_id, api_key_name, and hits.

api_key_name carries the human-readable Hindsight API key name that submitted the retain — your SIEM can attribute the leak to a specific agent or service without you maintaining a separate lookup.

Each entry in hits is {detector, preview} — for example {"detector": "GitHub Token", "preview": "ghp_AAAA...BBBB"}. The preview is a redacted-identifiable fingerprint of the captured value (recognizable prefix plus first four and last four characters of the body). It is enough for a SOC analyst to match against a credential inventory and identify which specific key leaked, but it cannot be replayed to authenticate against the provider. Plaintext is never delivered.

Subscribing​

In the Console, open Bank Settings, click Webhooks, and click Add Webhook. Provide the destination URL, a shared secret for HMAC verification on your side, and check memory_defense.violation in the event-type list. Deliveries are signed with HMAC-SHA256 in the X-Hindsight-Signature header, computed over the raw request body. Receiving systems should:

  • Verify the signature before processing the payload
  • Treat the event id as a dedupe key (deliveries can repeat on retry)
  • Ack with a 2xx response within 15 seconds, otherwise the delivery is considered failed and retries

Per-Platform Setup​

Splunk HEC​

Point the webhook URL at your Splunk HTTP Event Collector. Use the HEC token as the shared secret (Splunk verifies the token in the Authorization header, and Hindsight will pass the configured secret along). Configure a sourcetype of hindsight:memory_defense for indexing.

A sample SPL search for high-severity hits:

sourcetype=hindsight:memory_defense severity=high
| stats count by detector, identity

Triage signal: alert when any event with detector="GitHub Token" and severity="high" lands. The event payload includes api_key_name (the Hindsight API key that submitted the retain) and hits[].preview (a fingerprint of the captured token), so the alert message can name exactly which agent or service leaked which key in your inventory.

Datadog Logs​

Point the webhook URL at Datadog's logs intake endpoint. Add a custom pipeline that parses the JSON body and promotes detector to a tag for easy filtering. Use your Datadog API key as the shared secret.

Create a monitor on the resulting logs:

@evt.detector:"AWS Access Key" @evt.severity:"high" count > 0 over 5m

That monitor pages when a high-severity AWS credential leak is captured. Pivot to the originating retain using document_id, and attribute it to the submitting agent via api_key_name. Add similar monitors for the providers that matter to you (Stripe, OpenAI, GitHub, internal service tokens).

Slack Channel​

Use a Slack incoming webhook URL as the destination. Hindsight does not transform the payload for Slack, so the body arrives as raw JSON. That works for low-volume operational channels where someone reads every message, but it is not ideal for human triage at scale.

Most teams point at a forwarder instead: a Datadog log monitor that posts to Slack, a PagerDuty notification rule, or a small Cloudflare worker that pretty-prints the JSON into Slack-friendly markdown. The forwarder pattern also lets you filter (only post severity=critical, only post events with api_key_name matching production keys) before the message hits the channel.

PagerDuty Service​

Use PagerDuty's Events API V2 endpoint as the webhook URL. The shared secret becomes the integration key (routing key in PagerDuty's terminology). PagerDuty will treat each delivery as an event and apply your service's escalation policy.

Filter at PagerDuty (or upstream in a forwarder) to only page on severity=critical and known production-agent api_key_name values, so on-call wakes up for high-impact leaks and not for noise. Without that filter, a single regex-heavy bank can generate enough pages to burn out the rotation in a week.

Sample Alerting Playbook​

A practical tiering for the common patterns:

  1. High severity, production-agent api_key_name: page on-call. Match the hits[].preview fingerprint against your credential inventory to identify the specific leaked key, rotate it immediately, notify the credential owner, and pivot to the retain source via document_id to find the exposure path.
  2. High severity, dev-only api_key_name: weekly hygiene review. The leak vector is still worth fixing so production keys do not end up in the same retain path later.
  3. Prompt injection blocks above a per-hour threshold (for example, more than 20 per hour from a single bank): investigate the source agent or tool. A sustained injection rate is a strong signal of compromise or a misconfigured upstream tool that scrapes hostile content.
  4. Repeated size anomaly blocks from the same agent over a short window: investigate the source agent or tool. The pattern is consistent with exfil staging or a runaway integration dumping internal documents.
  5. Protected key violations: always investigate immediately, regardless of count. A write to a protected namespace almost always indicates intent, since legitimate services use the elevated path that bypasses the detector.

Delivery Guarantees​

Webhook deliveries retry on 5xx responses and timeout failures with exponential backoff up to 24 hours. After 24 hours, the delivery is marked failed and abandoned. The Console's Webhook Delivery Log surfaces every attempt for investigation, including the response code, the response body, and the retry schedule. Receiving systems should be idempotent and use the event id as a dedupe key, since the same event may be delivered more than once across the retry window.

For receivers that cannot be idempotent, the recommended pattern is a small forwarder (a Cloudflare worker, an AWS Lambda) that dedupes on event id before passing the event to the downstream system. Splunk HEC, Datadog logs, and PagerDuty all tolerate duplicate events well, so dedupe is not required for those destinations in practice.