跳到主要内容

FAQ

Common questions about Memory Defense, organized by topic.

Tier reminder

Most questions on this page concern Cloud Enterprise behaviour. Basic ships only the 44-pattern sensitive_data rule with action redact; the block action is silently downgraded to redact, and there is no security_events audit trail, no webhook delivery, no Console, and no support for detect_secrets, base64_decode, llm_screen, prompt_injection, size_anomaly, or protected_keys rules. Answers below that apply to both tiers say so explicitly.

Latency and Cost​

How much latency does each detector add per retain?​

The sensitive_data rule (which is the only rule on Basic, and also runs on Cloud Enterprise) adds under 50ms per retain item in typical content. The remaining latency figures are Cloud Enterprise only: detect_secrets adds under 50ms, base64_decode adds under 100ms because it expands and re-screens, and prompt_injection, size_anomaly, and protected_keys are all under 50ms. llm_screen is the outlier: 500ms to 2 seconds per unique payload on a cold cache, under 10ms on a warm cache hit. Cumulative latency for a full Enterprise policy without LLM screen is well under 200ms per retain.

Does the LLM screen really add LLM cost on every retain?​

(LLM screen is Cloud Enterprise only.) Only on cache misses. Decisions are cached on a content hash, so identical content costs zero LLM tokens on repeat. Document re-ingestion, replayed conversations, and idempotent retries are effectively free after the first screen. For workloads with high content turnover the cost is meaningful, which is why llm_screen is recommended only for banks where conversational secrets are a real threat.

Why doesn't Memory Defense verify whether a captured token is still alive?​

That used to ship as the "validity check" Cloud Enterprise feature. We removed it. The pitch was clean ("tell me if the leaked key is still active") but the implementation forced Hindsight to (a) retain plaintext credentials in security_events.event_metadata.hits so the worker could re-send them and (b) call customer provider APIs from Hindsight's network with customer credentials. Both raised reasonable compliance and authorization objections during early enterprise reviews. The current shape captures a redacted-identifiable fingerprint of every hit (e.g. ghp_AAAA...BBBB) and the Hindsight API key name that submitted the retain, then ships both to your SIEM. You verify on your terms, against your own audit log, from your network. If you want the live-vs-dead signal restored as a customer-side webhook handler, see the webhook integration guide.

False Positives and Tuning​

The LLM screen flagged something that was not a real secret. How do I tune?​

(LLM screen is Cloud Enterprise only.) The LLM screen does not expose a tuning knob in the Console today. False positives are surfaced in security_events for review. If a specific content pattern repeatedly false-positives, contact support and we can adjust the screen's prompt or add a content-class exclusion. In the meantime, the redacted content is still searchable and the original is preserved in the security event for forensic review.

A legitimate provider token is being redacted. Can I whitelist it?​

(Applies to both tiers, with the caveat below.) On Cloud Enterprise, per-bank whitelisting is not exposed in the Console today. The intended workflow is to keep the redaction in place (since most "legitimate" tokens in agent memory are leaks waiting to happen) and route the captured value through your normal secret-handling pipeline. If you have a bank where a specific token must pass through unmodified (for example, a bank that intentionally stores test fixtures), contact support to discuss the right approach. On Basic, the 44-pattern sensitive_data rule has no whitelist mechanism and runs unconditionally; if you need exemptions, run Cloud Enterprise.

size_anomaly is blocking normal large documents. What threshold should I use?​

(Cloud Enterprise only; size_anomaly is not implemented in Basic.) The default 200 KB is conservative. Banks that ingest knowledge-base articles or long transcripts commonly settle between 500 KB and 1 MB. Observe a week of normal traffic in the Console's storage analytics, find the 99th percentile retain size, and set detector_overrides.size_anomaly.max_size to roughly 2x that value. Any single retain larger than 1 MB should still be reviewed even if you raise the threshold, because legitimately huge retain items are usually a sign the calling integration is misconfigured.

Data Handling and Compliance​

What does event_metadata.hits actually contain?​

(Cloud Enterprise only; Basic does not maintain a security_events table.) Each hit is a dict of {detector, preview} — for example {"detector": "GitHub Token", "preview": "ghp_AAAA...BBBB"}. The preview is a redacted-identifiable fingerprint of the captured value: the recognizable prefix plus the 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 against the provider to obtain access. Plaintext is never retained.

Who can read security events for a bank?​

(Cloud Enterprise only.) Org admins, bank admins, and members of the bank can all read security events. Because the table never carries plaintext credentials, the row-level access is the same shape as any other recall surface — only the fingerprint and metadata are visible.

Is the security_events table encrypted at rest?​

(Cloud Enterprise only.) Yes. All Hindsight Cloud data including the security_events table is encrypted at rest with platform-managed keys. Customer-managed keys for the security events table specifically are not exposed in the Console today. Contact support if you need a custom key arrangement for compliance reasons.

Does Memory Defense data leave the Hindsight tenant?​

(Cloud Enterprise only; Basic has no webhook delivery and no LLM screen.) The one egress path from Memory Defense is your configured webhooks, which deliver the full event payload to your destination URLs. The payload is fingerprint-only — Hindsight never sends customer credentials to provider APIs or third parties. The llm_screen runs on Hindsight-hosted infrastructure and does not send content to a third-party model provider unless you have explicitly configured one.

Operational​

I added a rule and got HTTP 400. What does that mean?​

(Cloud Enterprise only; Basic has no policy API to return 400 from.) The most common cause is referencing a detector that your org does not have entitlements for. The error body lists the offending detector names. An org owner can grant the entitlement on the Admin Feature Flags page, then the bank admin can re-save the policy. See the error-case section in Building Policies for details. Other 400 causes are an invalid action for a detector (such as redact for prompt_injection) and a malformed detector_overrides payload.

How do I write a custom detector that does not exist out-of-the-box?​

(Cloud Enterprise only.) Custom detectors are not exposed in the Console today. The detector pipeline is extensible internally and we have shipped custom detectors for individual customers as part of an Enterprise engagement. Contact support to discuss the use case.

Tier and Pricing​

What is the difference between Basic and Cloud Enterprise again?​

Basic is the free open-source version of Hindsight. It ships exactly one thing: the 44-pattern sensitive_data rule with action redact. The block action is silently downgraded to redact, and there is no security_events audit trail.

Cloud Enterprise adds everything else:

  • The 176 additional provider patterns (from detect-secrets, GitLeaks, and Hindsight-native sources, for a total of 220)
  • The base64_decode rule
  • The llm_screen rule
  • The prompt_injection rule
  • The size_anomaly rule
  • The protected_keys rule
  • Real block action enforcement
  • The security_events audit trail (with captured-secret fingerprints and the submitting Hindsight API key name)
  • Webhook delivery to SIEM
  • The per-bank security policy editor in the Console

The full matrix is on the overview page.

Is there a per-detection fee?​

No. Memory Defense is included in Basic (free) and Cloud Enterprise (within the tier). The llm_screen detector (Enterprise only) consumes LLM tokens against your bank's existing LLM budget on cache misses (the LLM is the one running on Hindsight-hosted infrastructure for managed banks, or your configured provider for BYO-LLM banks).