DEV Community: Stella Lin

A HIPAA-safe alert pipeline checklist (8 controls)

Stella Lin — Fri, 08 May 2026 22:08:52 +0000

Originally published at theculprit.ai/blog/hipaa-checklist-for-alert-pipelines.

The compliance review for a healthtech SaaS usually treats the alert pipeline as a footnote.

The product is HIPAA-ready, the database is encrypted, the BAAs are signed, the access controls are documented. Then someone runs grep on a week of monitoring logs and finds patient IDs, member emails, and the occasional plaintext SSN sitting in alert payloads — copies of which were forwarded to a third-party log aggregator (without a BAA), surfaced to an LLM-based incident-analysis tool (also without a BAA), and rendered in plaintext inside a Slack channel that a contractor was a member of last month.

The product wasn't the leak. The alert pipeline was. And alert pipelines are a near-universal blind spot because the engineering team that built the application isn't the same team that wired up the alerting, and the alerting tools don't advertise themselves as PHI-handling systems.

This post is the checklist a healthtech engineering team can hand a HIPAA auditor and say "here's how the alert path is treated like the rest of the data path." Eight controls, mapped to the HIPAA Security Rule's Technical Safeguards (45 CFR 164.312), with concrete pointers to what each one looks like in code.

Where PHI gets into alert payloads

Before the controls, the threat model. A few common paths PHI takes into a monitoring alert:

Stack traces from production exceptions. A NullReferenceException in a patient-record handler captures the request URL, often containing patient identifiers. A failed insert captures the row being inserted, often containing PHI fields. Your error-tracking vendor will happily forward these verbatim to whichever notification channels you've configured — usually without a redaction step in between.
Webhook payloads from third-party services. A claims-clearing house's status webhook may include the member identifier in the body. A pharmacy benefit manager's notification includes the prescription. The alert that fires when the webhook 500s contains the full payload.
Database query timeouts. Slow-query log lines often include the bound parameters of the query — patient IDs, dates of birth, diagnosis codes. The alert that fires on "slow query" forwards the line.
Application logs surfaced into alerts. A log line emitted by your code with logger.warn({ user, request }) becomes the body of an alert when an aggregator's threshold fires. The full user object — email, phone, SSN-last-4 — rides along.
Health-check failure responses. A health-check endpoint that returns the failing patient-record's ID in its error body propagates that ID into the uptime monitor's alert.

In each case, PHI lands somewhere outside the application's authorized data path: a log aggregator, a notification channel, an incident-analysis tool, an on-call engineer's phone screen. Most of those somewheres are vendors who have not signed a BAA with you.

What HIPAA's Technical Safeguards actually require

The relevant subsection of the Security Rule (45 CFR 164.312) names five Technical Safeguards. Five sound like a lot; the load-bearing ones for an alert pipeline are:

§ 164.312(a)(1) Access control — only authorized personnel can decrypt PHI; the system enforces this in code, not by trust.
§ 164.312(b) Audit controls — every access to PHI is recorded; the audit trail itself is tamper-evident.
§ 164.312(c)(1) Integrity — PHI cannot be altered or destroyed by unauthorized parties; this includes side-channel destruction (e.g. a forgotten log retention deletes the only audit trail of a breach).
§ 164.312(d) Person or entity authentication — every PHI-accessing actor is authenticated with traceable identity, not "the on-call account."
§ 164.312(e)(1) Transmission security — PHI is encrypted in transit; this includes intra-system hops, not just the user-facing TLS layer.

The piece that catches most alert pipelines isn't any single safeguard — it's that the alert path is not treated as a PHI path, so none of these safeguards are applied to it specifically. The Notice of Privacy Practices doesn't mention monitoring alerts. The internal access-control matrix lists the application's data store but not the log aggregator. The audit log captures application-level reads but not "the on-call engineer saw the alert payload."

The checklist below addresses each gap.

The 8-item checklist

1. Tokenize PHI at ingest, before any storage

The first system that receives an alert payload (your ingestion edge) replaces every PHI value with an opaque token before writing the payload to any backing store. Concretely: a regex pass over the raw payload identifies high-confidence PHI shapes (emails, IPs, SSNs, common ID formats), each match gets replaced with <EMAIL_a3f9> / <SSN_b8c4> / <IP_2c1e>, the token-to-real mapping is encrypted with the customer's per-tenant key and stored in a vault separate from the alert event row.

After this step, the alert row in the operational store contains tokens only. Every downstream stage (correlation, LLM analysis, notification fan-out, log retention) operates on the tokenized form. The vault is read only by code paths that pass an authorization check.

What this earns: the alert pipeline now satisfies §164.312(a)(1) and §164.312(e)(1) for everything past the ingest edge — there is no PHI to access without going through the vault, and there is no PHI in transit to any downstream system.

2. Encrypt the vault at rest with customer-controlled keys

The vault that holds the token-to-real mapping is encrypted at rest with a customer-specific symmetric key. Postgres's pgcrypto extension gives you pgp_sym_encrypt() for this — the encrypted bytes go into a bytea column, and only the application's authorized code paths know the key.

Two decisions that matter:

Key per tenant, not key per row. Per-row keys are a key-management nightmare and don't add real security. Per-tenant keys mean a key rotation only requires re-encrypting one tenant's vault.
The key never enters the alert row's storage system. Keys live in your secret store (1Password / AWS Secrets Manager / Cloudflare Workers' bindings) and are pulled into the application process at startup. A snapshot of the database without the keys is not a PHI breach.

What this earns: §164.312(c)(1) integrity (the vault is tamper-evident — modifying ciphertext without the key produces decryption failure) and one half of §164.312(e)(1) (encrypted at rest).

3. Use SECURITY DEFINER functions for vault access, not direct SELECTs

Application code never SELECTs from the vault directly. Instead, it calls a SQL function defined as SECURITY DEFINER (in Postgres) that:

Verifies the caller is authorized to decrypt this specific record (the tenant matches, the actor has the right role, the access is being made in the context of an active incident, etc.)
Decrypts the requested tokens using the tenant's key
Writes an audit row capturing who decrypted what, when
Returns the plaintext to the caller

Wrapping decryption in a function gives you a single chokepoint to enforce all the access-control and audit-logging rules. Without it, every code path that wants to display PHI has to remember to do those checks, and the checks will drift.

What this earns: §164.312(a)(1) access control (the function is the access enforcement) plus §164.312(b) audit controls (the function writes the audit row).

4. Send only tokens to LLM analysis, never raw PHI

Any LLM-driven analysis (root-cause inference, correlation, summarization) operates on the tokenized payload. The model sees <EMAIL_a3f9> instead of alice@example.com. The model's output, similarly, contains tokens — your UI rehydrates them into plaintext only on display, only for authenticated users with the right access.

Why this matters even with a BAA-covered LLM vendor: the model's training data, the model's prompt cache, the model's logs, the inference platform's debug surfaces, the conversation context an engineer might paste into a developer console — all of these are surfaces where the prompt could end up being retained or visible. Sending tokens means none of those surfaces ever holds PHI.

What this earns: closes the most common HIPAA-blast-radius gap in modern alert pipelines (LLM analysis was a 2023 addition for many teams, and the controls didn't get updated).

5. Audit every PHI rehydration

Every time a token is decrypted to plaintext (a UI that shows the original value, an export to PDF, a customer-support tool that surfaces the data), an audit row is written. The audit row captures: who (authenticated user ID), what (which tokens), when (timestamp), in what context (incident ID, ticket ID, support session ID).

The audit table is append-only — no updates, no deletes from the application — and is itself protected (separate access control, separate retention).

What this earns: §164.312(b) audit controls. A HIPAA auditor's standard test is "show me a record of every time PHI for patient X was accessed in the last 90 days." If you can produce that report from one audit table, you pass; if you have to assemble it from log files across five vendors, you fail.

6. Default-deny on outbound notifications

Every channel the alert pipeline can fan out to (PagerDuty, Slack, email, webhook) receives the tokenized payload by default. To send plaintext, the channel configuration must explicitly opt in — and the opt-in is logged + reviewed quarterly.

The default matters because new channels get added regularly ("can we send these to the new on-call rotation in the platform team?"), and the safe default is "yes, with tokens." If the default were "yes, with plaintext," every new channel introduces a fresh BAA conversation that's likely to be skipped under deadline pressure.

What this earns: §164.312(e)(1) transmission security (PHI doesn't leave the system in plaintext); also a major reduction in BAA scope (you only need BAAs with vendors that actually receive plaintext, which is a much smaller set).

7. Auto-resolve quiet alerts to limit retention

The HIPAA Security Rule doesn't specify a retention period for alerts, but the principle behind §164.312(c)(1) is that PHI shouldn't sit indefinitely in places where it's not actively serving a clinical or operational purpose.

A practical control: incidents that have been quiet for 30 minutes and don't have an active investigation get auto-resolved. Auto-resolve doesn't delete the underlying tokenized payloads (you may need them for a future investigation), but it moves the incident out of the on-call queue and out of the active dashboard. The vault retention policy (separately) governs how long the encrypted plaintext is kept; a defensible default is "as long as the corresponding incident is needed for audit, then deleted via a periodic sweep."

What this earns: bounded retention of accessible PHI, which limits both the §164.312(c)(1) integrity surface and the volume that has to be re-reviewed during a periodic access audit.

8. Tenant-isolation at the database, not at the application

Multi-tenant SaaS architectures often enforce tenant isolation in application code ("the application only queries rows where tenant_id matches the authenticated session"). For HIPAA, this is too weak — a single bug in any code path that omits the predicate is a cross-tenant breach.

The control: enforce tenant isolation at the database level via Row-Level Security (Postgres's RLS), where every row in every PHI-adjacent table has a tenant_id column and the database itself rejects queries that don't match the active session's tenant. Application code can still construct the query without the predicate; the database refuses to return cross-tenant data.

What this earns: §164.312(a)(1) access control, with the enforcement layer being the database (not the application). A bug in application code can no longer cause a cross-tenant PHI leak — the bug would have to be in the RLS policy itself, which is much smaller surface area to review.

What this looks like in practice

Three concrete patterns from a production alert pipeline that ships with these controls:

Edge tokenization in TypeScript:

// Conceptual; production code wraps this in vault writes + key resolution.
const sanitized = payload.replace(EMAIL_REGEX, (match) => {
  const token = `<EMAIL_${hmac(match, salt).slice(0, 4)}>`;
  vault.set(token, encrypt(match, tenantKey));
  return token;
});

The hmac slice keeps tokens deterministic per-value within a tenant — the same email always produces the same token, so correlation across alerts works.

SECURITY DEFINER decryption in Postgres:

CREATE FUNCTION token_decrypt(p_incident_id uuid, p_tokens text[])
RETURNS TABLE(token text, plaintext text)
SECURITY DEFINER
LANGUAGE plpgsql
AS $$
BEGIN
  -- Authorization: caller must have read access to this incident's tenant.
  IF NOT EXISTS (
    SELECT 1 FROM tenant_members
    WHERE tenant_id = (SELECT tenant_id FROM incidents WHERE id = p_incident_id)
      AND user_id = auth.uid()
  ) THEN RAISE EXCEPTION 'forbidden'; END IF;

  -- Audit the decryption.
  INSERT INTO token_decrypt_audit (incident_id, actor_id, token_count)
  VALUES (p_incident_id, auth.uid(), array_length(p_tokens, 1));

  -- Decrypt + return.
  RETURN QUERY
    SELECT v.token, pgp_sym_decrypt(v.encrypted_value, key())::text
    FROM vault v WHERE v.token = ANY(p_tokens);
END;
$$;

This is the only path application code uses to see plaintext. Direct SELECT FROM vault is rejected by RLS; token_decrypt is the chokepoint.

Token-only LLM prompt:

const prompt = `Analyze the following sanitized incident events:
${sanitizedEvents.join('\n')}
The events contain placeholder tokens like <EMAIL_x> for redacted PII.
Do not attempt to infer the actual values; reason about the patterns.`;

The LLM never sees plaintext. Its output cites the tokens; the UI rehydrates them via token_decrypt only when an authorized user clicks "show plaintext."

What you sign up for

These controls aren't free. Three honest tradeoffs:

Cluster quality drops slightly when the LLM can't see literal values. Two alerts that both reference alice@example.com cluster trivially when the LLM sees the email; with tokens, the cluster has to come from the surrounding context. Mitigations exist (deterministic tokens that produce the same placeholder for the same value, so co-occurrence is preserved) but don't fully close the gap.
The audit table grows. Every rehydration writes a row. At healthcare-SaaS scale (thousands of incidents per month per tenant) the table grows into the millions of rows per year. Plan for this with partitioning + a separate retention policy.
The on-call experience adds one click. Engineers who used to see the patient ID inline now see <EMAIL_a3f9> and click "show plaintext." For most incidents the click is unnecessary (the tokens are enough to triage); for the 10% where it matters, the extra click is the cost of the audit trail.

The alternative is the status quo: PHI in alerts, scattered across vendors, audit trails that don't exist, and the cheerful assumption that nobody on the security team will think to look at the alert pipeline during the next audit. That assumption holds until it doesn't.

Where this generalizes

The controls above are written for HIPAA but apply with minor edits to any compliance regime that requires (a) data classification, (b) access control, and (c) audit logging on a sensitive-data path. SOC 2's Common Criteria 6 (Logical and Physical Access Controls) maps to controls 1, 3, 5, 8. ISO 27001's Annex A.9 (Access Control) maps to controls 3, 5, 8. GDPR's Article 32 (Security of Processing) maps to controls 1, 2, 4, 6.

The pattern is universal: treat the alert pipeline as a sensitive-data path, not as a footnote. Every piece of PHI / PII / PCI that flows through the alert path should be tokenized, encrypted, audited, and tenant-isolated by the same primitives that protect the application's data store. Once those primitives exist (controls 1-3 are the foundation), the rest follows.

This is the architecture behind Culprit's edge tokenization model — every alert payload arrives, gets tokenized, gets stored encrypted, and downstream tools see only tokens. The /security page documents the specific control mapping if your security team wants to review the architecture during a vendor review.

Anthropic prompt caching cut our RCA cost by 90%

Stella Lin — Fri, 08 May 2026 21:44:26 +0000

Originally published at theculprit.ai/blog/anthropic-prompt-caching-90-percent.

LLM costs in production scale faster than the post-mortem of the demo bill suggests they will.

The shape of the problem: you ship a feature that calls Claude on every meaningful event. The first month the bill is rounding error and nobody looks at it. The second month a customer's traffic ramps and the line item is suddenly five percent of revenue. The third month your finance person sends a polite Slack about whether this is "a real cost trend or a one-time spike," and everyone on the engineering team has to defend an architecture decision they made eight weeks ago when the bill was rounding error.

You can reduce this. Not by being clever about how you call the model — by being clever about what's constant across your calls. Anthropic's prompt caching, in our case, takes the per-RCA input cost from full-rate to one-tenth of full-rate on a 90%+ cache-hit rate. That's not a hypothetical; it's what we measure in production, and the math is simple enough to walk through here so you can run the numbers on your own pipeline.

The pricing structure

Anthropic publishes four price points per model. For Claude Haiku 4.5, the model we run as the default for incident root-cause analysis, those points are (verified from the Anthropic API docs):

Token category	Haiku 4.5
Base input	$1.00 per million tokens
Cache write (5-minute TTL)	$1.25 per million tokens
Cache read	$0.10 per million tokens
Output	$5.00 per million tokens

Two things to read from that table:

Cache read is 10x cheaper than base input. Same tokens in the request body, ten percent of the cost — if you can get them into the cache.
Cache write is 25% more expensive than base input. First time you send a cached segment, you're paying a small premium so the next request can pay the discount. The math only pays off if you call the model with the same cached segment more than ~1.25 times on average within the 5-minute TTL window.

That second point is the one most teams miss. If your call pattern is "one-shot, cold cache every time," prompt caching makes you slightly worse off. The win comes from repeatable structure across calls.

What's actually cacheable in an RCA call

A typical RCA call has five sources of tokens:

System prompt. Defines the role ("you are an SRE analyzing an incident"), the JSON schema for the response, and any guardrails. Identical across every call across every tenant. Maybe 800-1500 tokens depending on how rigorous your schema is.
Retrieval context ("here are 3 prior incidents from this same service that resolved similarly"). Static for a few minutes within a Batch run on one tenant + service. Maybe 400-800 tokens depending on how aggressive the retrieval is.
Per-incident events ("event 1 at 14:32:01: ConnectionPoolExhausted...; event 2 at 14:32:04: ..."). Unique to the incident under analysis. Cannot be cached across incidents. Typically 1500-3000 tokens.
Per-incident metadata (incident ID, service ID, severity). Tiny but unique.
Output tokens. The model's response. Cost is fixed at the output rate; caching doesn't apply.

Sources 1 and 2 are cacheable. Sources 3 and 4 are not. Source 5 is irrelevant.

In our distribution, sources 1 + 2 are roughly 70-80% of the input tokens for a typical RCA call. Cache them at 0.10 per million; pay full rate on the remaining 20-30%; total input cost drops by about 60-70% from the naive baseline. The "90%" headline number rounds up because we measure cache hits, not total cost, and within the cached portion the savings really are 90%.

The two-segment trick

Anthropic's API takes a cache_control marker per segment in your system array. Each marker is an independent breakpoint — the cache stores tokens up to the marker. If you have two segments, the API caches each one separately:

// Conceptual shape — see rca-prompt.ts for the exact code we run.
const system = [
  {
    type: 'text',
    text: SYSTEM_PROMPT,                    // ~1200 tokens, identical everywhere
    cache_control: { type: 'ephemeral' },
  },
  {
    type: 'text',
    text: priorIncidentsContext,            // ~600 tokens, per-tenant per-service
    cache_control: { type: 'ephemeral' },
  },
];

Why two segments instead of one? Because the cache lifetime for those two pieces is different.

The system prompt almost never changes — every RCA call across every tenant hits the cache. Cache read essentially every time after the first call.

The retrieval context (prior similar incidents for this service) changes whenever a new incident on that service resolves and shifts the top-K. Within a single Batch run on one tenant + service, repeats hit the cache. Across tenants, never.

If you stuff both into a single segment, the moment the retrieval context for tenant A changes, tenant B's hit rate drops too — because the one combined segment hashes differently. Two segments → independent cache lifetimes → tenant A's churn doesn't punish tenant B.

The order matters. Anthropic caches up to each marker, so the more-static segment must come first. If you put per-tenant retrieval first and the static system prompt second, the static prompt's cache key now includes the per-tenant content above it; you've just made the most cacheable segment uncacheable across tenants.

What kills the cache

In rough order of frequency:

The 5-minute ephemeral TTL. A cached segment expires 5 minutes after its last write. If your call pattern is bursty (RCA calls cluster around incidents, then quiet for an hour), a long quiet period will let every cached segment expire and you'll pay cache write (slightly above base rate) on the next batch. Spread your calls if you can; if you can't, accept that the first few calls after a quiet period pay full freight.

Whitespace drift. If you concatenate the system prompt with \n\n in one place and \n in another, you have two distinct cache keys. The cache hashes the literal token sequence, not the semantic meaning. Pick one separator and lint for it.

Trailing dynamic content. A common bug: someone adds a timestamp to the "system prompt" — Today's date is 2026-05-08T14:32:01Z — for "context". The timestamp changes every call. Now nothing cached after the timestamp survives. Keep dynamic content out of cached segments entirely; pass it as a user-message turn instead.

Schema version churn. If you're iterating on your JSON output schema (a normal early-product activity), every schema edit invalidates every cached system prompt. The cost of "tuning the schema" is partly paid in cache misses. Plan for one or two big schema-stabilization sweeps rather than continuous tweaks.

The production numbers

Per-RCA cost on Haiku 4.5 with prompt caching enabled, Batch API (which itself adds another 50% off both input and output), 4000 input tokens + 500 output tokens, ~75% of input tokens cached:

Input (cached portion, 3000 tokens × 0.5 batch × 0.10 cache-read): $0.00015
Input (uncached portion, 1000 tokens × 0.5 batch × 1.00 base): $0.00050
Output (500 tokens × 0.5 batch × 5.00): $0.00125
Cache write amortized (1200 tokens × 0.5 batch × 1.25, divided across ~30 cache hits per write cycle): ~$0.00003

Total: ~$0.0033 per RCA call.

Without caching, same call shape, real-time API: input would be ~$0.004, output would be ~$0.0025, total ~$0.0065. Caching alone gets us a ~50% reduction on input. Batch API gets us another 50% on top. Caching + Batch is what makes the per-RCA cost sit around a third of a cent.

A cluster of typical incidents at this rate is the difference between "a flat-rate pricing model that works" and "a flat-rate pricing model with worst-case unit economics that don't." We document this in our pricing rationale — the discipline isn't a marketing posture, it's the load-bearing constraint that lets the price stay flat.

Where this generalizes

If you're calling Claude on a per-event or per-incident schedule, the structure above applies to whatever shape your calls take. The questions to answer:

What in your prompt is identical across every call? That's segment 1. If the answer is "nothing," your prompt isn't designed for caching yet — find the constants. There almost always are some.
What is per-tenant or per-context but reused within a short window? That's segment 2. Common cases: retrieval context, customer-specific style guidelines, account metadata.
What's truly per-call? Goes in the user message turn, never in the cached system block.
Is your call rate above the break-even threshold? If you call the same cached prompt fewer than ~1.25 times per 5-minute window, you'll lose money on caching. For a noisy production system this is rarely the bottleneck, but for a low-volume tool it can be.

The pattern doesn't apply only to Claude. OpenAI's prompt caching follows similar economics with different numbers; Gemini's context caching has a different TTL but the same "what's static, what's dynamic" decomposition. The work of setting up your prompts so the static parts cluster at the front pays off across every model that supports caching, which is increasingly all of them.

A single test

If you're considering whether prompt caching applies to your pipeline, the cheapest first measurement is also the most informative one: count how many tokens of your typical request are byte-for-byte identical to the previous request. Not "semantically the same" — literally identical. If the answer is more than 50%, you're leaving money on the table; ship cache_control on the static prefix and watch the input-cost line item drop on the next billing day.

If the answer is less than 20%, your prompts are designed for context, not for repetition, and caching probably won't help much without a structural rewrite. Either way, knowing the number is a one-hour exercise that beats arguing about whether caching is worth the complexity.

The architecture above is what makes Culprit's flat-rate pricing economically defensible — RCA calls cluster around incidents, the system prompt and retrieval context dominate the input tokens, and the cache hit rate sits comfortably above 90%. Same primitives, different vertical: if you're shipping LLM features into production at any scale where the bill is starting to matter, this is the lowest-effort high-yield refactor you have available.

6 regexes for detecting PII in event payloads

Stella Lin — Fri, 08 May 2026 11:49:03 +0000

Originally published at theculprit.ai/blog/detecting-pii-in-event-payloads.

This is a working document, not a survey. The patterns below are the ones we actually run against inbound alert payloads in Culprit's tokenizer. They are tuned for one job: catch as much PII in unstructured event text as a regex layer can plausibly catch, while erring toward false positives over false negatives. Where they fail, we say so and describe the fallback.

If you're building a similar pipeline — observability tool, log sanitizer, ingestion middleware in front of an LLM — you can copy the set as-is, but the more useful thing is to read the failure modes and decide whether they apply to your traffic.

The set

Six patterns. All are stateless, all use the global flag so a single String.prototype.matchAll(regex) walks the entire payload, all are scoped to word boundaries to avoid eating the surrounding text. The full source is in packages/shared/src/pii-detect.ts; this is the load-bearing part:

export const PII_PATTERNS = [
  { type: 'email',
    regex: /\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b/g },
  { type: 'ipv4',
    regex: /\b(?:(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\b/g },
  { type: 'ipv6',
    regex: /\b(?:[0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}\b/g },
  { type: 'phone',
    regex: /(?:\+?1[-.\s]?)?(?:\(?\d{3}\)?[-.\s]?)?\d{3}[-.\s]?\d{4}\b/g },
  { type: 'ssn',
    regex: /\b\d{3}-\d{2}-\d{4}\b/g },
  { type: 'high_entropy',
    regex: /\b[A-Za-z0-9+/=_-]{40,}\b/g },
];

What each one catches, what it misses, and what we do about it:

01 — `email`

\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b

Catches: the overwhelming majority of email addresses you'll see in practice — paula.holman@acme.com, user+tag@subdomain.example.co.uk, a@b.io.

False negatives: RFC 5322 is much wider than the regex. Quoted local parts ("weird name"@example.com), addresses with comments, IDN domains in their unicode form (user@münchen.de). In several years of looking at production alert payloads we have seen exactly zero of these. They are theoretical.

False positives: anything formatted like an email but used as something else — service-account names that happen to look like addresses, fixture data, JIRA mention syntax in some custom apps. These tokenize harmlessly. The downstream consumer sees an opaque token; the engineer can reveal it if they need to.

Tradeoff: the bracket-class [._%+-] does not include all RFC-permitted characters. We've never regretted that.

02 — `ipv4`

\b(?:(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\b

Catches: every well-formed IPv4. The octet alternation 25[0-5]|2[0-4]\d|[01]?\d\d? rejects out-of-range numbers like 999.1.1.1, which keeps the false-positive rate low.

False negatives: zero. Any string that parses as an IPv4 matches this regex.

False positives: version strings (10.4.2.1), build numbers, dates rendered as 2026.05.05 — wait, that one fails the leading-zero rule, never mind. The real false-positive class is software version strings like 10.4.2.1, which the regex cannot distinguish from a private IP. We accept this. A version string tokenized as <TOKEN_…> in an alert is annoying; an exfiltrated customer IP is a breach.

Tradeoff: consider whether you actually want to tokenize private-range IPs (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12). They are usually internal infrastructure, not customer data. We tokenize them anyway because the line between "internal" and "customer" gets blurry when you're hosting webhooks for customer-on-premise systems, and the asymmetry from §01 still applies.

03 — `ipv6`

\b(?:[0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}\b

Catches: fully-expanded IPv6 addresses. 2001:0db8:85a3:0000:0000:8a2e:0370:7334.

False negatives: every common form of IPv6 you'll actually see. ::1, 2001:db8::1, fe80::1%eth0, IPv4-mapped IPv6 (::ffff:192.168.1.1). The :: zero-compression syntax is not handled; neither is the scope identifier; neither is mixed IPv4/IPv6 notation.

False positives: rare. The : separator and the strict colon count make accidental matches uncommon.

Tradeoff: this is the worst pattern in the set, and we have not yet replaced it. The reason is that "ungrep'd IPv6" is itself a small class of leaks compared to email and bearer tokens. When we do replace it, the right move is two patterns — one for full form, one for compressed — both rooted in word boundaries with the high-entropy fallback as a backstop.

04 — `phone`

(?:\+?1[-.\s]?)?(?:\(?\d{3}\)?[-.\s]?)?\d{3}[-.\s]?\d{4}\b

Catches: North American number formats: 5551234567, 555-123-4567, (555) 123-4567, +1 555 123 4567, +1.555.123.4567.

False negatives: non-NANP numbers (UK, EU, Asia). International formatting beyond +1. Numbers written without separators that don't begin with the country code (5551234567 matches; 442012345678 does not, by design — that pattern catches too many order numbers).

False positives: seven-to-ten-digit numbers that are not phone numbers. Order IDs. Tracking codes. Long invoice numbers. The regex tokenizes all of them. This is the pattern with the highest false-positive rate in the set, and we accept it for the same reason as §02.

Tradeoff: if your traffic is global, swap this for libphonenumber or a per-country regex set. The performance cost is real (tens of milliseconds per payload) but tractable for a worker that runs after the ingest 200 has already returned.

05 — `ssn`

\b\d{3}-\d{2}-\d{4}\b

Catches: US Social Security Numbers in their canonical hyphenated form.

False negatives: SSNs without dashes (123456789). SSNs with spaces (123 45 6789). All non-US national-ID formats.

False positives: anything formatted like XXX-XX-XXXX. Some product SKUs, some legacy account numbers, some date-range strings if your team uses an unusual format. Low rate in practice.

Tradeoff: the regex is conservative on purpose. A payload containing 123456789 is more likely to be an order number, an internal ID, or a build artifact than an SSN, and tokenizing every nine-digit run produces a meaningful fraction of false positives in observability traffic. If you specifically need to catch un-hyphenated SSNs (healthcare, payments, government), add a structural rule instead — a ssn field in your event schema that you tokenize regardless of contents.

06 — `high_entropy`

\b[A-Za-z0-9+/=_-]{40,}\b

Catches: the long, opaque strings you don't have a more specific pattern for. Bearer tokens. JWTs. Most provider API keys (Stripe sk_live_…, AWS AKIA… keys when emitted with the secret, GCP service-account JSON values). Session IDs. Most cryptographic hashes used as identifiers.

False negatives: anything under 40 characters. Some short access keys (a few cloud providers issue 32-char keys; those slip through). UUIDs without dashes (32 chars) — usually not credentials, but worth knowing.

False positives: long base64-encoded blobs that are not credentials — encoded protobufs, serialized state strings, image data URIs, signed-but-not-secret payloads. These tokenize as opaque. Engineers occasionally complain that "the tokenizer redacted my decoded protobuf"; we ask them whether the protobuf contained a customer's name and they reread their own alert and stop complaining.

Tradeoff: the threshold is the entire pattern. We picked 40 by walking back from "what's the shortest credential we want to catch" (≈40-char JWT header) and "what's the longest non-credential we don't want to catch" (32-char dashless UUID, hex SHA-256). There is no universally correct number. Instrument the false-positive rate against your traffic and iterate. If you change the number, change it once and write down why; do not let it drift.

What the regex set does not catch

Four categories of PII do not yield to regex, and pretending they do is how detectors gain a reputation for being theater.

Personal names. "John Smith" is two common English nouns concatenated. There is no regex that distinguishes "John Smith reported the issue" from "John Smith Auto Parts." The right answer is a structural rule: any field whose schema name is name, customer_name, display_name, full_name, first_name, last_name, account_holder — tokenize unconditionally, regardless of contents.

Addresses. Free-text street addresses are unbounded. Same answer: structural rule on field name (address, street, mailing_address, billing_address).

Free-text disclosures. "The customer mentioned their phone is 5551234567 and their kid's birthday is on the 5th" — the regex set catches the phone number, but the surrounding context is itself revealing. There is no good regex defense. The defense is a structural rule that says any field named notes, comment, description, support_message, customer_message, summary is tokenized as a whole field rather than scanned for patterns.

Account numbers, license plates, and other domain-specific identifiers. These vary too much across industries. If you have them, you know their format; write a domain-specific regex and add it to the set. If you don't know your domain's identifier formats, you have a discovery problem before you have a detection problem.

The pattern: regex catches the universal cases; structural rules on field names catch the contextual cases. A serious tokenizer does both. A toy tokenizer does only the first and lets the second class slip through. If you only have time to build one layer, build the structural rules — most of the high-value leaks are in notes-shaped fields, not in stringified payloads.

A note on order and replacement

The detection regexes return (type, value, index) triples. To turn them into a sanitized payload, you have to replace each match with a placeholder without invalidating the indices of subsequent matches.

The naive approach replaces left-to-right and adjusts every later index by the length delta. This works but is fiddly. The cleaner shape is to sort matches by index and replace right-to-left, which leaves earlier indices untouched. The cleanest shape is to split the original string on the match boundaries and join with placeholders, which sidesteps index arithmetic entirely.

Whichever you pick, the relevant invariant is: deduplicate matches that overlap. The high-entropy pattern can match a substring that also matches the email pattern (a long enough local-part). Pick one — the more specific pattern wins, every time — and discard the other before replacement.

The shipping bar

If you're building this for production, the bar to clear before you trust the detector with real traffic:

A hand-labeled sample of 200+ alerts from your actual pipeline, not synthetic data. Run the detector against it, count false negatives by category. If any category exceeds 5%, fix the regex or add a structural rule before shipping.
A way to measure false-positive rate continuously in production. A weekly report of "tokens issued per category, normalized to traffic volume" — sudden spikes mean the regex started matching something it didn't before.
A reveal flow for the engineer who needs to see the original. Without a fast reveal flow, the false-positive rate stops being free — every false positive becomes a pager-duty for some on-call engineer who needs to know what <TOKEN_a1b2c3> actually was.

The first regex you ship will not be the last one. Plan the iteration loop in.

The pattern set above is the production set as of the date on this post. If you want to read the full module — including the detector function, the sort-by-index ordering, and the rationale comments — it's at packages/shared/src/pii-detect.ts in the Culprit repo. The companion piece, on the rest of the pipeline (encrypt-at-ingest, per-tenant token dictionary, audited reveal), is How to keep PII out of your alert pipeline.

How to keep PII out of your alert pipeline

Stella Lin — Fri, 08 May 2026 11:47:34 +0000

Originally published at theculprit.ai/blog/keep-pii-out-of-alert-pipeline.

Every alert that crosses your wire has a PII problem you have not yet acknowledged.

This is not a sermon. It is a thing you can verify in about ten minutes. Open the last hour of whatever your team uses for paging — Slack, email, a webhook fan-out, a chat-ops channel — and grep for @. You will find customer email addresses in stack traces. You will find them in user-supplied form data echoed back into the error message. You will find them in the body of "user X did Y and it failed" notifications that someone wrote in 2022 and nobody has touched since. Now grep for 192., 10., 172.16. — there are your customer IPs, surfaced into a chat tool whose retention you do not control. Now grep for Bearer — those are the API tokens your authentication middleware accidentally included in the panic dump.

The reason this happens is not negligence. The reason it happens is that the alert pipeline is the one place in your stack where the rules of "what data is allowed to leave the boundary" were never written down. The application layer has an ORM that knows which fields are PII. The data warehouse has a column-level access policy. The customer-facing API has a serializer with explicit field allowlists. The alert pipeline has a console.error(err) and the assumption that whoever reads the alert is sufficiently trustworthy. That assumption stops being true the moment the alert routes to a third-party LLM, a vendor support portal, or a Slack workspace whose member list has drifted.

This piece is about what to actually do about that.

01 — Why the obvious fixes don't survive contact with reality

There are three obvious fixes. All three fail in interesting ways. Walking through why is most of the work.

Fix one: strip PII at the application layer before the alert is emitted. The pitch is clean — every logger.error() call site gets wrapped in a sanitizer that knows the domain types and redacts accordingly. In practice this fails along two axes. The first is enforcement: you cannot reliably grep your codebase for "every place a user-supplied string ends up in an error path." Stack traces capture local variables in some runtimes. Third-party libraries throw errors whose messages include the offending input verbatim. A request-validation middleware throws Invalid email: customer@example.com and there is no place in your application code where you "decided" to log that. The second is drift: even if you ship a sanitizer today, the next engineer adds a new field, a new exception type, a new integration that emits its own errors, and the sanitizer's allowlist quietly stops keeping up. The fix degrades to a security checklist item that nobody owns.

Fix two: drop alerts that contain PII. This sounds principled until you remember why you have an alert pipeline. The whole point is that something is broken, and the alert is your evidence. If your detector flags an alert as containing PII and your response is to discard it, you have built a system that hides the bugs that involve customer data — which is approximately every interesting bug. The detector also has false positives. Drop on false positive and you have built a system that drops random alerts at random rates. This fix tends to get rolled out enthusiastically, generate one P0 about a missed page, and get rolled back within a week.

Fix three: redact in the LLM prompt. This one is recent. The shape is "we use an AI tool to triage incidents; we'll add a redaction layer in front of the prompt." It fails because by the time the data reaches that redaction layer, it has already been written to your alert store, your queue, your log aggregator, your chat tool, and probably your email. The LLM prompt is not the boundary. The ingest path is the boundary. Redacting at the prompt is solving a symptom three hops downstream of the cause.

The pattern in all three is the same: each fix tries to add a filter at one specific point in the pipeline, while the real problem is that the pipeline has many exit points and the data is in plaintext at all of them.

02 — The shape of a fix that does work

The architecture worth building has four properties. None of them are novel. Most of them appear in compliance-driven sectors — healthcare, payments — where the obvious fixes have been tried and discarded for thirty years. They are unfamiliar to the observability stack only because observability has historically been treated as an internal tool, not as a data plane that crosses trust boundaries.

The properties:

The boundary is at ingest, not at presentation. The first thing that happens to an inbound alert is encryption-and-vault. Plaintext does not survive the receiving handler.
PII is replaced with reversible placeholders before any downstream consumer sees the payload. Correlation, LLM analysis, notification, log aggregation — all of these operate on a sanitized event whose fields read like <TOKEN_a1b2c3> rather than paula.holman@acme.com.
The placeholder ↔ value map is per-tenant and encrypted with a tenant-scoped key. A leak of one tenant's vault cannot unlock another tenant's tokens. A leak of the application database without the per-tenant key cannot unlock anything.
Reveal is a single audited route. When an authorized user needs to see the original value — debugging a customer-reported incident, responding to a subpoena — they do so through one endpoint that checks tenant scope on every call and writes to an append-only audit log.

The composite property: there is no path through the system that produces plaintext PII as a byproduct. Producing plaintext requires a deliberate, authenticated, audited request. That is the bar.

Below is a sketch of the data flow. It is deliberately minimal — every edge here is load-bearing, and every node corresponds to a thing you have to either build or buy.

Two observations about this sketch. First, every arrow that leaves the tokenizer carries <TOKEN_…> placeholders, including the one to the LLM. Second, the REVEAL ROUTE is the only edge in the entire diagram where plaintext crosses a process boundary, and that crossing is audited.

03 — The four hard parts

The architecture above is easy to describe and tedious to build. Each of the four properties from §02 has a "how do we actually" attached to it that takes a week or two to get right.

03.1 — Encrypt before vault, with no plaintext window

The naive ingest handler looks like this:

export async function POST(req: Request) {
  const body = await req.json();
  await db.from('raw_alerts').insert({ payload: body });
  await queue.send({ alert_id: body.id });
  return new Response('ok');
}

This is wrong in a way that is not visible from the code. The raw_alerts table holds plaintext. Every backup of that table holds plaintext. Every read replica holds plaintext. Anyone with read access to the application database — your DBA, your ops engineer with break-glass credentials, the support engineer who joined last month and got read-only access by default — has plaintext access to every alert your customers have ever sent. The encryption needs to be inside the same statement as the insert, with the key sourced from a place that the application database does not itself hold.

The fixed shape uses Postgres' pgcrypto extension and a server-held symmetric key:

export async function POST(req: Request) {
  const rawBody = await req.text();
  const { error } = await db.rpc('vault_alert', {
    p_payload_text: rawBody,
    p_signature: req.headers.get('x-aiops-signature'),
  });
  if (error) return new Response('rejected', { status: 400 });
  await queue.send({ /* opaque pointer, no body */ });
  return new Response('ok');
}

The vault_alert RPC, defined once in a migration, performs the HMAC verification and the pgp_sym_encrypt(p_payload_text, current_setting('app.vault_key')) insert atomically. The application code never holds the key. The database never holds plaintext. The queue carries an opaque identifier — if the queue gets backed up, leaks, or is replayed, no PII is exposed.

The instinct to skip this step and "just trust the database" is strong. Resist it. The threat model is not "an attacker has root on Postgres." The threat model is "a backup ends up in S3 with the wrong ACL." Encryption-at-rest provided by the platform does not protect you from that. Per-row encryption with an application-held key does.

03.2 — A per-tenant token dictionary that does not become a privacy hole itself

The tokenizer's job is to walk a payload, find every PII match, and emit a sanitized version where each match is replaced with a placeholder. The natural shape is a dictionary table:

create table token_dictionary (
  tenant_id    uuid not null,
  placeholder  text not null,    -- e.g. "TOKEN_a1b2c3"
  encrypted_value bytea not null,
  pii_type     text not null,    -- "email" | "ipv4" | ...
  created_at   timestamptz not null default now(),
  primary key (tenant_id, placeholder)
);

There are three traps here. The first is using a global placeholder space — if TOKEN_a1b2c3 means customer@acme.com for tenant A and 192.168.1.1 for tenant B, you have inadvertently built a side channel where tenant B's reveal endpoint can confirm whether a given placeholder was issued in tenant A. Always scope the lookup by (tenant_id, placeholder).

The second is encrypting the value with a single global key. The dictionary is, by construction, a high-value target — it is the table that, if leaked, undoes all the work above. The encryption key for encrypted_value should be derived per-tenant, ideally from a master key combined with tenant_id. A leak of the dictionary alone yields ciphertext you cannot decrypt without the master key. A leak of the master key alone yields nothing without the dictionary. You have to lose both.

The third is determinism. If you regenerate placeholders on every ingest, the same email address shows up under five different tokens across five alerts and your correlation engine can no longer tell that "the same customer keeps tripping the same bug." The fix: hash (tenant_id, normalized_value) and use the hash as the placeholder identifier. Same value within a tenant → same placeholder, every time. Different value or different tenant → different placeholder.

03.3 — Match gracefully: false positives are noise, false negatives are leaks

The detection layer is a regex set. Six patterns will catch most of what a typical alert payload contains:

export const PII_PATTERNS = [
  { type: 'email',        regex: /\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b/g },
  { type: 'ipv4',         regex: /\b(?:(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\b/g },
  { type: 'ipv6',         regex: /\b(?:[0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}\b/g },
  { type: 'phone',        regex: /(?:\+?1[-.\s]?)?(?:\(?\d{3}\)?[-.\s]?)?\d{3}[-.\s]?\d{4}\b/g },
  { type: 'ssn',          regex: /\b\d{3}-\d{2}-\d{4}\b/g },
  { type: 'high_entropy', regex: /\b[A-Za-z0-9+/=_-]{40,}\b/g },
];

Two notes on this set. The phone pattern is intentionally loose — it will match some things that look phone-shaped but are not (long order numbers, tracking IDs). That is the right tradeoff. A false positive becomes an opaque token in the alert; the engineer can still triage the alert and, if needed, reveal the original value. A false negative becomes a customer phone number sitting in your Slack history forever. The asymmetry is real. Tune toward false positives.

The high-entropy bucket exists because the most consequential leaks are not patterns we know about — they are bearer tokens, session IDs, and API keys whose format depends on whoever issued them. A 40+ character base64-ish blob is not always a credential, but it is almost never something you want surfaced to a third party. The threshold of 40 is tuned to skip UUID-without-dashes (32 chars) and short build SHAs while still catching JWTs and most provider tokens. Lower the threshold and you'll start catching legitimate identifiers; raise it and you'll start missing short access keys. There is no universally correct value. Pick one, instrument the false-positive rate against your traffic, and iterate.

What this set does not catch: free-text personal names ("John Smith"), structured-but-non-regex identifiers (most account numbers, license plates), and natural-language disclosures ("the customer mentioned their address is …"). For these you need either an ML-based classifier in front of the regex set or a structural rule that says "fields named customer_name, address, notes always tokenize regardless of contents." The structural rule is cheaper, more predictable, and much easier to audit.

03.4 — Reveal as a single audited route

Engineers will, eventually, need to see the original value. That is fine. The mistake is to scatter "decrypt this token" calls throughout the application. The right shape is a single route:

POST /api/incidents/:id/reveal
  body: { placeholders: ["TOKEN_a1b2c3", "TOKEN_b2c3d4"] }

The route checks: (a) the requesting user is authenticated; (b) the user's tenant matches the incident's tenant; (c) the user has the appropriate role for reveal (operator, admin); (d) the incident is one the user is permitted to view at all. Then, and only then, it pulls the encrypted values from the per-tenant dictionary, decrypts them server-side, returns plaintext over HTTPS, and writes a row to the audit log: who, when, which placeholders, which incident.

The audit log is not optional. It is the thing that turns "I trust my own employees" from an aspiration into something you can demonstrate to an auditor. It is also what lets you answer the question "did anyone access this customer's data between 2026-04-12 and 2026-04-19?" without combing through application logs. Build it as part of the reveal route from day one; retrofitting it later is annoying.

One subtle point: the reveal route should not return the entire decrypted payload by default. The caller has to name the placeholders they want. This sounds like friction, but it is what makes the audit log useful — instead of "user accessed incident 1234" (which tells you nothing about what was exposed), you get "user accessed TOKEN_a1b2c3 (email) and TOKEN_b2c3d4 (ipv4) on incident 1234" (which tells you exactly what data crossed the boundary). The friction is the point.

04 — What you give up

This is honest-tradeoffs time. Edge tokenization is not free.

Latency. The ingest handler now does an HMAC verify, an encrypted insert, and a queue publish before returning 200. On a warm Worker with the database in the same region, this is roughly 30–80ms more than a no-op write. For most alert pipelines, this is invisible — the sender does not care whether the 200 takes 5ms or 80ms. For pipelines where the sender is a tight retry loop with a low timeout, you may need to instrument and tune.

Cost. You are paying for: a worker invocation per alert, a queue message per alert, an encrypted column write per alert, a tokenizer invocation per alert, a sanitized-event write per alert. None of these are individually expensive. At a million alerts a day, the storage and compute add up to dollars, not hundreds of dollars. The expensive thing in this architecture is the LLM call for root-cause analysis, and that is bounded separately.

Operational complexity. You now have a key-rotation procedure. You have a backup-and-restore procedure that has to handle the dictionary as a separate concern. You have a "what do we do if the per-tenant key is lost" runbook (answer: you cannot recover the data, which is the point). You have an audit log that needs its own retention policy. None of these are crushing — they are all things compliance-driven sectors have been doing for decades — but they are real engineering work.

05 — What you get back

The thing you get back is not "compliance." Compliance is a side effect. The thing you get back is that the question "what would happen if our chat tool's history were leaked" stops requiring a long answer. You can route alerts to a third-party LLM without first negotiating a BAA, because there is no PHI in the prompt. You can grant a new vendor — error tracking, on-call, an analytics dashboard — read access to your alert stream without staging a security review for each one, because the alert stream does not contain customer data. You can ship faster.

The compliance posture follows. SOC 2 Type II's common criteria around confidentiality become almost mechanically satisfiable: encryption at rest (vault), in transit (HTTPS only), and a documented incident-response procedure with a 72-hour notification window. HIPAA's technical safeguards — access control, audit controls, integrity, person/entity authentication, transmission security — map cleanly onto the routes and tables described above. None of this means you are certified. It means that when you decide to pursue certification, the architecture work is already done and the auditor's questions become procedural rather than structural.

The other thing you get back is unchecked-code-review time for the rest of your team. Every PR no longer has to be scrutinized for "did this introduce a path that logs customer data." That path doesn't exist. There is one place in the codebase where plaintext appears, and it is a route handler with seventeen lines of authorization logic in front of it.

06 — Where to start, if you want to start

If you're convinced and looking at your own pipeline, the order matters. Do not start with the tokenizer; start with the vault.

Pick the first byte of plaintext PII to remove from a downstream consumer. A reasonable first target is your incident-management tool, since it is usually the most-shared and the least-controlled. The goal of week one is "no plaintext customer email addresses in any incident-management notification we send."
Build the encryption-at-ingest path. Move every alert-emitting service to write to the encrypted vault first; let the existing pipeline keep running off the encrypted blob, decrypted in the consumer. This is the dangerous step — get this wrong and you lose alerts. Run it in shadow mode for a week.
Build the tokenizer. Start with the four highest-confidence patterns (email, IPv4, IPv6, SSN). Run it against historical traffic; measure your false-positive and false-negative rates against a hand-labeled sample of 200 alerts. Iterate the regex set until you can defend the numbers.
Cut over the downstream consumers to the sanitized events. Keep the vault as a fallback for "we lost an alert" debugging.
Build the reveal route and the audit log. Migrate any "I'll just SSH in and SELECT it" workflows to use the route. Turn on RLS and the lint rules that prevent the back door from being reopened.

You can be at step 5 in six to eight weeks of focused work. The thing that gates the timeline is not the engineering — it is figuring out which integrations in your existing pipeline are actually emitting PII, and what the structural rules need to be to stop them. That part is investigative.

If you'd rather not build the pipeline yourself, that is exactly what Culprit is. The architecture above is a description of what we ship. The piece is here because we want the architecture to be the default approach to alerting, not a thing you have to discover by getting bitten.

DEV Community: Stella Lin

A HIPAA-safe alert pipeline checklist (8 controls)

Where PHI gets into alert payloads

What HIPAA's Technical Safeguards actually require

The 8-item checklist

1. Tokenize PHI at ingest, before any storage

2. Encrypt the vault at rest with customer-controlled keys

3. Use SECURITY DEFINER functions for vault access, not direct SELECTs

4. Send only tokens to LLM analysis, never raw PHI

5. Audit every PHI rehydration

6. Default-deny on outbound notifications

7. Auto-resolve quiet alerts to limit retention

8. Tenant-isolation at the database, not at the application

What this looks like in practice

What you sign up for

Where this generalizes

Anthropic prompt caching cut our RCA cost by 90%

The pricing structure

What's actually cacheable in an RCA call

The two-segment trick

What kills the cache

The production numbers

Where this generalizes

A single test

6 regexes for detecting PII in event payloads

The set

01 — email

02 — ipv4

03 — ipv6

04 — phone

05 — ssn

06 — high_entropy

What the regex set does not catch

A note on order and replacement

The shipping bar

How to keep PII out of your alert pipeline

01 — Why the obvious fixes don't survive contact with reality

02 — The shape of a fix that does work

03 — The four hard parts

03.1 — Encrypt before vault, with no plaintext window

03.2 — A per-tenant token dictionary that does not become a privacy hole itself

03.3 — Match gracefully: false positives are noise, false negatives are leaks

03.4 — Reveal as a single audited route

04 — What you give up

05 — What you get back

06 — Where to start, if you want to start

01 — `email`

02 — `ipv4`

03 — `ipv6`

04 — `phone`

05 — `ssn`

06 — `high_entropy`