DEV Community: Ilya Ploskovitov

Redact PII in bank logs under GDPR: hash it, don't mask it

Ilya Ploskovitov — Thu, 24 Sep 2026 19:03:42 +0000

Originally published at pii-shield.com/guide-banking-logs-gdpr.

TL;DR: An account number in a log line is personal data, and the pipeline carrying it is processing. Redact it before the line leaves the pod, and put a keyed hash in its place rather than a constant, so the log can still answer "one customer or four hundred?" when the 72-hour clock is running. Below: where banks redact today and where each option breaks, a payments log before and after, how to check it worked, and what an entropy scanner will not find.

An account number in a log line is personal data

Nobody argues about the customer table. The log line that says payment.authorised account_number=GB29NWBK60161331926819 is the same account number, attached to the same person, and Article 4(1) lists "an identification number" among the things that make someone identifiable. So the log is personal data, and everything that touches it on the way to the dashboard is processing: the file on the node, the shipper's queue, the vendor's index, the backup of that index.

In a bank this usually comes up during a DPIA, and more often than not about a system that has been shipping logs to a SaaS for three years. The awkward part is that the lines have already left, and you cannot redact what is stored under somebody else's retention policy.

The rest of this post is about the next line.

How banks redact today, and where each option breaks

Where you redact decides how far the raw value has already travelled and who owns the rule. The four places, from earliest to latest:

Where	Where the raw value has already been	Who maintains the rule	Where it breaks
In the application	Nowhere. Best possible boundary	Every service, every team	The one service nobody touched since 2019, and every new field somebody logs next quarter
In the pod, before the shipper (sidecar)	A file on a volume inside the pod	Platform team, one config	The app has to write to a file the sidecar can read; stdout-only apps need a small change
At the shipper (Logstash `gsub`, Fluentd `record_transformer`, Alloy `stage.replace`)	Node disk, the shipper's queue, sometimes a buffer on another node	Whoever owns the collector config	Regex lists rot. A new field or a new format ships and the rule does not know about it
At the vendor (a sensitive-data scanner in the SaaS pipeline)	Everything above, plus the vendor's ingestion infrastructure	The vendor's rule engine, your rules in it	The raw value reached a third party before anything masked it. That is the sentence the DPIA will quote

This is a comparison of boundaries, not of detection quality. A well-kept Logstash filter catches what its regexes describe. The problem is the word "kept": the list was written for the fields that existed when it was written, and the line has been on disk for a while before the filter sees it.

PII-Shield sits in the second row. It runs as a sidecar in the pod, reads the application's log file from a shared volume, and prints the cleaned line to its own stdout, where the existing collector picks it up with no configuration change. The raw line stays on the pod's volume and goes nowhere. The Fluentd, Datadog and Grafana Alloy guides show the wiring for each collector. This post is about what the redaction should do once it runs.

What goes in place of the value decides whether the log is still worth reading

A constant like REDACTED throws away the one thing that makes a redacted log useful. Forty lines carrying the same leaked account number turn into forty unrelated events. When the 72-hour notification clock under Article 33 is running, the question everyone asks first is whether it is one customer or four hundred, and a log full of REDACTED cannot answer it.

A keyed hash can. Same value, same salt, same tag:

login ok account_number=[HIDDEN:88797d]
export started account_number=[HIDDEN:88797d]
export started account_number=[HIDDEN:be171d]

Two of the three lines are about the same customer, and you can see that without knowing who the customer is. Distinct-count queries work. So do joins across services. Nothing readable is stored anywhere. The tag is an HMAC of the value under a salt you hold, so it is one-way for anyone without the salt and confirmable for anyone with it.

Change the salt per environment and the tags stop lining up between production and the test cluster somebody handed a contractor. The same declined payment, under PII_SALT=0123456789abcdef0123456789abcdef and then under PII_SALT=fedcba9876543210fedcba9876543210:

2026-09-20T10:14:09Z WARN payment.declined account_number=[HIDDEN:88797d] reason=limit_exceeded request_id=7c1d9f
2026-09-20T10:14:09Z WARN payment.declined account_number=[HIDDEN:ba8164] reason=limit_exceeded request_id=7c1d9f

A payments log, before and after

Three lines a payments service might write. Nothing here was hand-edited: the "after" block is the output of the released CLI with a fixed test salt and default settings, so you can reproduce it.

Before:

2026-09-20T10:14:03Z INFO payment.authorised account_number=GB29NWBK60161331926819 card=4539148803436467 customer=j.smith@example.co.uk amount=120.00 session=AbC9xY2kQ8pLmN0rZq7 request_id=7c1d9e
2026-09-20T10:14:09Z WARN payment.declined account_number=GB29NWBK60161331926819 reason=limit_exceeded request_id=7c1d9f
2026-09-20T10:15:41Z WARN transfer.rejected from=31926819 to=44017265 sort_code=60-16-13 channel=mobile msg="beneficiary account closed"

After, PII_SALT=0123456789abcdef0123456789abcdef pii-shield < payments.log:

2026-09-20T10:14:03Z INFO payment.authorised account_number=[HIDDEN:88797d] card=[HIDDEN:b9025c] customer=[HIDDEN:fc65b3] amount=120.00 session=[HIDDEN:7e1d32] request_id=7c1d9e
2026-09-20T10:14:09Z WARN payment.declined account_number=[HIDDEN:88797d] reason=limit_exceeded request_id=7c1d9f
2026-09-20T10:15:41Z WARN transfer.rejected from=31926819 to=44017265 sort_code=60-16-13 channel=mobile msg="beneficiary account closed"

What happened, field by field:

The IBAN was hidden on both lines with the same tag, 88797d. That is the counting property from the previous section, and it is what lets you see the declined payment and the authorised one belong to one customer.
The card number passed a Luhn check. The email and the session token were hidden for a duller reason: they look random enough to the entropy scorer.
The amount, the reason and the request id were left alone. 120.00 is protected by a decimal rule, limit_exceeded and 7c1d9e score below the threshold.
The third line was not touched at all. Two 8-digit account numbers and a sort code went through in the clear. That is the limit of anything generic, and the next section is about it.

Your own formats are yours to write

A 22-character IBAN clears the entropy bar because it looks random. An 8-digit domestic account number does not, and neither does 60-16-13, and no generic detector can tell either of them from an order id. There is no IBAN detector and no account-number detector in PII-Shield, and I would be suspicious of one: your reference formats are your bank's, so the rule for them has to be yours too. It is one line of configuration:

PII_CUSTOM_REGEX_LIST='[{"name":"acct","pattern":"^\\d{8}$"},{"name":"sort-code","pattern":"^\\d{2}-\\d{2}-\\d{2}$"}]'
PII_ENTITY_TYPE_LABELS=true

The third line again:

2026-09-20T10:15:41Z WARN transfer.rejected from=[HIDDEN:acct:cca553] to=[HIDDEN:acct:6b4e22] sort_code=[HIDDEN:sort-code:e026ca] channel=mobile msg="beneficiary account closed"

The marker now names the rule that fired. With the second variable on, the built-in detectors name themselves as well, so the first line becomes account_number=[HIDDEN:entropy:88797d] card=[HIDDEN:card:b9025c] and a reviewer can tell a card from a session token without seeing either.

That label is the part I got wrong for a while. For the first six months every match came out as the same bare marker with no type in it, so a redacted line told you something had been hidden and nothing about what kind of thing it was. An account number and a session id were indistinguishable. Type labels came later, and they are still off by default, because changing the shape of every marker breaks whatever people had already built on the old one. Turn them on in staging first and look at what they say.

Verifying it actually worked

A redaction you have not checked is a belief. The first check is the one I would not skip: put a synthetic account number, a test card and a made-up email into a staging log line you control, then grep -c for each of them on the collector side. The answer has to be 0. Reading the config tells you what you intended; this tells you what happened.

Then take a few thousand lines of production-shaped logs with test data, run the CLI on them with a fixed salt, and read the diff. You are looking for two things at once, values that survived and values that should have been left alone.

Run the same sample with PII_ENTITY_TYPE_LABELS=true. A card that comes back as entropy rather than card is still hidden, but the Luhn path did not see it, and the next format change may not be so lucky.

Two smaller checks. Log the same test identifier from two services under the same salt and confirm the tag is identical; if it is not, the salts differ, and your incident counts will be wrong on the day they matter. And with metrics enabled, watch piishield_redaction_events_total, a Prometheus counter with a type label: a drop in card after a deploy is a format change somewhere upstream, a rise in entropy is usually a new field logging something random.

Last, every rule that protects a value from redaction can also hide a leak. After you add one to the safe list, run the planted-value check again.

Honest limits

Values without a shape are not found. Card numbers, keys, emails and tokens have one. A customer's name in a free-text complaint field does not, and no threshold will find it. This line comes out of the scanner unchanged:

complaint="Mr John Smith says the card was blocked twice"

Finding names needs a model, which costs latency and money, and that is a different tool at a different point in the pipeline. The practical answer for logs is usually to decide that free text does not belong in them, rather than to try to scrub it after the fact.

Some ordinary values look random to the scorer. An 18-character snake_case enum and a short hex-looking id can both cross the threshold. In the sample I ran for this post, the first false positive was a request id and the second was a reason code. Neither needed hiding. Here they are, then the safe list that fixes them, then the line again:

2026-09-20T10:16:02Z WARN payment.declined reason=[HIDDEN:fd4d4d] request_id=[HIDDEN:c4c401]

PII_SAFE_REGEX_LIST='[{"name":"reason-enum","pattern":"^[a-z]+(_[a-z]+)+$"},{"name":"req-id","pattern":"^req_[0-9a-f]{4}$"}]'

2026-09-20T10:16:02Z WARN payment.declined reason=insufficient_funds request_id=req_8f3a

You will find a handful of these in the first diff. Add them to the safe list by shape, not by value, and then re-run the planted-value check, because a safe-list rule that is too wide is a leak with a name.

Hashing is pseudonymisation, not anonymisation. That is Article 4(5). The data stays personal data; you still owe retention, subject rights and a record of processing. What you get is a smaller blast radius when the wrong dashboard is open in front of the wrong person, and Article 32 does count pseudonymisation as a security measure. Your DPO gets the final word on the classification, not this post.

And the old lines are gone. Nothing here reaches back into what a vendor already stored; that conversation is about the vendor's retention and deletion process.

Two operational notes. Rotate the salt and correlation resets: tags before and after a rotation do not match, so plan rotations like key rotations, with a date and a note in the runbook. And the sidecar reads a file: an application that only writes to stdout needs to write to a shared volume instead, or use the in-process library, because transparent stdout capture is still at the design stage. The full list is in KNOWN_LIMITATIONS.md.

Next steps

Run the CLI on a sample. Grab the binary or the container from the repository, set a fixed test salt, pipe a few thousand lines through it and read the diff. Note what was missed and what was hidden by mistake.
Write the rules for your formats. Account numbers, sort codes, internal customer ids, reference numbers. One PII_CUSTOM_REGEX_LIST entry each, named, so the marker says which one fired.
Pick the collector guide and wire the sidecar. Fluentd and Fluent Bit, ELK, Datadog, Loki, OpenTelemetry or Grafana Alloy. Then run the planted-value check on the collector side, not on the pod.

The next log line is the one you can still do something about. PII-Shield is Apache-2.0 on GitHub. Run it on a sample before you run it on a cluster.

Mask PII in Grafana Alloy logs without a stage.replace pattern list

Ilya Ploskovitov — Sat, 12 Sep 2026 18:35:04 +0000

Originally published at pii-shield.com/guide-alloy.

TL;DR: Alloy can mask log lines with loki.process and stage.replace, and it even hashes with a salt if you ask it to. What it cannot do is mask a value before that value is written to the node's disk — by the time Alloy reads the line, the raw secret has already been sitting in /var/log/pods. Redact inside the pod with a PII-Shield sidecar, and Alloy collects lines that were never sensitive.

Everyone is rewriting their log pipeline right now

Promtail reached end of life on 2 March 2026. Its features were merged into Grafana Alloy, and every Promtail deployment is being converted — by hand or with alloy convert — into Alloy components.

Which makes this a good moment to ask an awkward question about the pipeline being rewritten: if it masked personal data before, where exactly did that masking happen?

The standard approach: loki.process and stage.replace

Alloy's answer to redaction is a processing stage between the source and the write component. A typical Kubernetes setup discovers pods, tails their log files, runs them through loki.process, and writes to Loki:

discovery.kubernetes "pod" {
  role = "pod"
  selectors {
    role  = "pod"
    field = "spec.nodeName=" + coalesce(sys.env("HOSTNAME"), constants.hostname)
  }
}

discovery.relabel "pod_logs" {
  targets = discovery.kubernetes.pod.targets
  rule {
    source_labels = ["__meta_kubernetes_namespace"]
    target_label  = "namespace"
  }
  rule {
    source_labels = ["__meta_kubernetes_pod_name"]
    target_label  = "pod"
  }
  rule {
    source_labels = ["__meta_kubernetes_pod_container_name"]
    target_label  = "container"
  }
}

loki.source.kubernetes "pod_logs" {
  targets    = discovery.relabel.pod_logs.output
  forward_to = [loki.process.redact.receiver]
}

loki.process "redact" {
  forward_to = [loki.write.default.receiver]

  stage.replace {
    expression = "([a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-.]+)"
    replace    = "[REDACTED_EMAIL]"
  }

  stage.replace {
    expression = "(Bearer [A-Za-z0-9\\-_.]+)"
    replace    = "[REDACTED_TOKEN]"
  }

  // Hashing keeps correlation: the same value always yields the same digest.
  stage.replace {
    expression = "user_id=(\\d+)"
    replace    = "{{ Hash .Value \"a-long-random-salt\" }}"
  }
}

loki.write "default" {
  endpoint {
    url = "http://loki:3100/loki/api/v1/push"
  }
}

Credit where it is due: that last stage is better than most collectors offer. Alloy's replace field takes a Go template, and the Hash function takes a salt and returns a SHA3-256 digest — so a masked value stays consistent across lines and your dashboards keep grouping by user without exposing anyone. If you are going to mask in the collector, mask like that, not with a constant.

Run that exact configuration, though, and watch what comes out the other end. Feed it one line carrying an email, an Authorization header and a Stripe key, and the email becomes [REDACTED_EMAIL], the header becomes [REDACTED_TOKEN], the same user_id hashes to the same digest on every line it appears in — and sk_live_4eC39HqLyjWDarjt ships to Loki exactly as it was written, because nothing in the list above covers it. That is the whole failure mode in one line of output: the stages you wrote work, and the secret you did not think of leaves silently.

Where this stops being enough

The value has already left the pod. loki.source.kubernetes reads what the kubelet already wrote to the node — the raw line exists in /var/log/pods before any stage runs. Anything else on that node with read access to those files (a second collector, a debugging sidecar, a node agent, someone with kubectl debug) sees the unmasked value, and your log retention on the node is now a copy you did not plan for.

You have to enumerate the shapes. Every stage matches one RE2 expression. Emails, bearer tokens and your internal ID format are three stages; the API key format a vendor introduced last month is a fourth that nobody has written yet. A stage that does not match fails silently — there is no signal that a secret went past.

The cost lands on the shared collector. Alloy usually runs one instance per node for every pod on it. Each stage is evaluated against each line, so the work scales with total log volume multiplied by the length of your pattern list, on a process your whole node shares.

The alternative: redact inside the pod

Move the redaction one step earlier — into the pod that produced the line — and the three problems above disappear together. PII-Shield is a small Go sidecar that reads the application's log file, scrubs it, and prints clean lines to its own stdout. It finds secrets by Shannon entropy and key context rather than by a list of shapes, so an unfamiliar token format is still caught.

// What your app wrote:
{"level":"info","msg":"payment accepted","email":"john.doe@gmail.com","user_id":"88213","token":"sk_live_4eC39HqLyjWDarjt"}

// What Alloy reads from the node:
{"level":"info","msg":"payment accepted","email":"[HIDDEN:adc335]","user_id":"88213","token":"[HIDDEN:4a692a]"}

The marker is a salted HMAC of the value, so [HIDDEN:adc335] is the same person on every line and in every service that shares the salt — the same correlation the Hash template gives you, except the raw value never reached the node's disk to begin with.

Note what did not change in that line: user_id is still 88213. A bare number has no shape to recognise and user_id is not a secret-bearing key name, so the scanner leaves it alone rather than guessing. If that identifier is personal data in your threat model, it goes in as a named rule through PII_CUSTOM_REGEX_LIST — the same explicit decision the stage.replace above was making, taken once and applied in every pod instead of in each collector config.

Kubernetes implementation

The application writes to a shared emptyDir instead of stdout; the sidecar owns stdout for the pod. Alloy needs no knowledge of any of this.

apiVersion: v1
kind: Secret
metadata:
  name: pii-shield-secret
type: Opaque
stringData:
  pii-salt: "replace-with-a-long-random-value"
---
apiVersion: v1
kind: Pod
metadata:
  name: billing-service
  labels:
    app: billing
spec:
  containers:
    - name: billing-app
      image: billing-app:v2.1.0
      # The app writes its private output to a shared file
      command: ["/bin/sh", "-c"]
      args: ["./billing-binary > /var/run/logs/app.log 2>&1"]
      volumeMounts:
        - name: log-volume
          mountPath: /var/run/logs

    - name: pii-shield-sidecar
      image: thelisdeep/pii-shield:2.2.3
      env:
        - name: PII_SALT
          valueFrom:
            secretKeyRef:
              name: pii-shield-secret
              key: pii-salt
      # Scratch image: run the binary directly (no shell, no tail).
      command: ["/pii-shield"]
      args: ["--watch-file", "/var/run/logs/app.log"]
      volumeMounts:
        - name: log-volume
          mountPath: /var/run/logs

  volumes:
    - name: log-volume
      emptyDir: {}

Your Alloy config then shrinks back to collection and labelling — the redaction stages come out:

loki.source.kubernetes "pod_logs" {
  targets    = discovery.relabel.pod_logs.output
  forward_to = [loki.process.pod_logs.receiver]
}

loki.process "pod_logs" {
  forward_to = [loki.write.default.receiver]

  stage.static_labels {
    values = {
      cluster = "production",
    }
  }
}

Verify it is actually working

Check the sidecar's own output first. Querying Loki only tells you what arrived; it does not tell you whether the raw stream is still being written somewhere on the node because a mount path was wrong.

# This is exactly what Alloy will collect
kubectl logs billing-service -c pii-shield-sidecar --tail=50

# Nothing raw should survive
kubectl logs billing-service -c pii-shield-sidecar --tail=200 | grep -E "@|Bearer|sk_live" | grep -v "\[HIDDEN:"

# And the app container should now be quiet: its output goes to the file, not to stdout
kubectl logs billing-service -c billing-app --tail=20

The second command should print nothing. If it prints a line, that format is not being caught yet — report it as a scanner bug rather than assuming the pipeline is safe. The third should be empty too; if it is not, the application is still writing to stdout and Alloy is collecting the raw stream alongside the clean one.

Honest limitations

This covers the logs path only. Metrics and traces that your instrumentation sends straight to Alloy over OTLP never pass through the sidecar, so if span attributes carry personal data, handle those in Alloy's own processors.

Detection is not magic either. Entropy and key context catch values with a shape — tokens, keys, contact details, card numbers. A customer's name sitting in a free-text field has no shape, and no threshold finds it; that needs a model, which is a different cost. Your own internal identifier formats do have a shape, but it is yours, so it goes in as a rule (PII_CUSTOM_REGEX_LIST).

Nothing here retroactively cleans what has already been shipped to Loki, and none of it is a substitute for not logging secrets in the first place — it is the last line of defence for what slips through anyway. And if you already have a stage.replace list that works, there is no reason to delete it on day one: the sidecar in the pod and the stage in the collector compose fine, and running both while you build confidence costs you nothing but a few regex evaluations.

Common questions

Why not just add a stage.replace for every pattern and be done?
Because two of the three problems stay. A stage only masks the shapes you wrote down, and it runs after the kubelet has already written the raw line to the node's disk, so the value existed in the clear on that node regardless. Enumerating shapes is also the part that quietly rots: the vendor API key format introduced last month has no stage yet, and nothing tells you it went past.

I am migrating from Promtail to Alloy — do my masking stages carry over?
Yes, and so do their limits. The alloy convert command translates a Promtail pipeline_stages block into the equivalent stage.* blocks, replace stages included, so whatever your regex list caught before it catches now, and whatever it missed it still misses. The migration is a good moment to ask whether that list belongs in the collector at all.

Do I have to change my Alloy configuration to use the sidecar?
No. The sidecar writes clean lines to its own stdout, and the kubelet files them like any other container's output, so discovery.kubernetes and loki.source.kubernetes pick them up unchanged. That holds whether you run Alloy from the Grafana Helm chart, the k8s-monitoring chart, or your own DaemonSet.

Can I still group by a user in LogQL after redaction?
Yes. Values are replaced with stable markers rather than deleted, so the line keeps its structure and LogQL parsers keep working. The marker is a salted HMAC, so the same user is the same marker on every line and across services sharing the salt — a distinct count is still a real distinct count, you just cannot read who it was.

What about the node and journald logs Alloy also collects?
The sidecar covers what your application containers write, nothing else. Systemd units, kubelet logs and anything you collect with loki.source.journal never pass through it, so treat those with Alloy's own stages or keep them out of the pipeline.

Will it clean the logs already in Loki?
No. It sanitizes only what passes through it from the moment it is deployed. What is already ingested stays as it is, and the ways out are waiting for retention to expire or deleting the affected streams.

Verified on 9 September 2026: the Alloy configuration and the manifest above were run as printed — Grafana Alloy v1.19.2, Kubernetes v1.35 (kind), PII-Shield 2.2.3. Alloy collected the sidecar's output with no configuration change of its own, and every entry it received carried markers instead of values.

Stop maintaining a pattern list inside your collector. Check out the PII-Shield repository on GitHub and drop a star if this simplifies your Alloy pipeline.

Zero-code PII sanitization for Fluentd and Fluent Bit in Kubernetes

Ilya Ploskovitov — Fri, 21 Aug 2026 08:14:30 +0000

TL;DR: send app logs through a PII-Shield sidecar before Fluentd or Fluent Bit read them, then collect only masked identifiers like [HIDDEN:a1b2c3] instead of maintaining regex filters that break the moment a new secret format shows up.

Fluentd and its lighter C-based sibling Fluent Bit are the most common unified logging layers in Kubernetes — CNCF graduated projects with a huge plugin ecosystem for routing logs to almost any backend (Elasticsearch, Loki, S3, Datadog, Splunk). That flexibility is exactly why they end up sitting directly in the path of every raw log line your applications write.

If an application logs a user's email, an API key, or a card number, Fluentd/Fluent Bit will happily parse, buffer, and ship that value to wherever you've configured — permanently, and usually to more than one destination at once.

The Standard Approach: Filter-Layer Masking

Both projects expose a way to scrub fields in-flight. Fluentd uses record_transformer with Ruby's gsub:

<filter app.**>
  @type record_transformer
  enable_ruby true
  <record>
    message ${record["message"].gsub(/[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+/, '[REDACTED]')}
  </record>
</filter>

Fluent Bit doesn't ship a built-in PII filter, so the common workaround is a lua filter calling a hand-written script:

[FILTER]
    Name    lua
    Match   *
    script  redact.lua
    call    redact_pii

function redact_pii(tag, timestamp, record)
    if record["message"] then
        record["message"] = string.gsub(record["message"],
            "[%w.+-]+@[%w-]+%.[%w.-]+", "[REDACTED]")
    end
    return 1, timestamp, record
end

Why this approach breaks down at scale:

The Regex Trap: Every secret shape — API keys, session tokens, internal ID formats — needs its own pattern. Miss one and it ships in cleartext with no warning, because nothing fails; it just silently doesn't match.
Per-Line Interpreter Overhead: Fluent Bit's Lua filter runs an embedded Lua interpreter for every single record. On high-throughput pods this is a well-known source of added latency and CPU pressure on the node running the DaemonSet — worse than Fluentd's native Ruby path, but both add real per-line cost that scales with log volume, not with how much PII is actually present.
Loss of Context: A static [REDACTED] destroys correlation. If ten log lines all become [REDACTED], you can no longer tell whether they're the same user hitting an error ten times or ten different users.

The Zero-Code Alternative: PII-Shield Sidecar

Instead of asking Fluentd's Ruby engine or Fluent Bit's Lua interpreter to parse and pattern-match every line, move sanitization to a dedicated, low-allocation Go sidecar that sits before either one ever sees the log: PII-Shield.

The Result:

// What your app generated:
{"level":"info", "message":"User authenticated", "email":"john.doe@gmail.com", "token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}

// What Fluentd / Fluent Bit actually reads and ships:
{"level":"info", "message":"User authenticated", "email":"[HIDDEN:e9f1a2]", "token":"[HIDDEN:a1c7af]"}

How it works:

The App redirects its output to an ephemeral shared volume (like an emptyDir) instead of the main stdout.
PII-Shield (Sidecar) tails that file, scrubs it using entropy-based secret detection (no regex list to maintain for API keys and tokens), and prints the clean logs to its own stdout.
Fluentd or Fluent Bit — already running as a DaemonSet reading /var/log/containers/*.log — picks up the sidecar's stdout the same way it picks up any other container's, no config change required.

The record_transformer filter and the Lua script can both be deleted. Fluentd/Fluent Bit go back to doing what they do best — routing already-clean logs.

Kubernetes Implementation

This is the same sidecar pattern regardless of whether your DaemonSet runs Fluentd or Fluent Bit — neither needs to know PII-Shield exists.

apiVersion: v1
kind: Secret
metadata:
  name: pii-shield-secret
type: Opaque
stringData:
  pii-salt: "replace-with-a-long-random-value"
---
apiVersion: v1
kind: Pod
metadata:
  name: billing-service
  labels:
    app: billing
spec:
  containers:
    - name: billing-app
      image: billing-app:v2.1.0
      # The app writes its private output to a shared pipe/file
      command: ["/bin/sh", "-c"]
      args: ["./billing-binary > /var/run/logs/app.log 2>&1"]
      volumeMounts:
        - name: log-volume
          mountPath: /var/run/logs

    - name: pii-shield-sidecar
      image: thelisdeep/pii-shield:2.2.0
      env:
        - name: PII_SALT
          valueFrom:
            secretKeyRef:
              name: pii-shield-secret
              key: pii-salt
      # Scratch image: run the binary directly (no shell/tail). Reads, scrubs,
      # and outputs to stdout for Fluentd/Fluent Bit to pick up.
      command: ["/pii-shield"]
      args: ["--watch-file", "/var/run/logs/app.log"]
      volumeMounts:
        - name: log-volume
          mountPath: /var/run/logs

  volumes:
    - name: log-volume
      emptyDir: {}

Pro tip: The thelisdeep/pii-shield image is multi-arch (amd64/arm64).

Verify It's Actually Working

Before trusting the pipeline, confirm the sidecar's own output is already clean — don't just check what lands in your log backend, since a misconfigured mount can make Fluentd/Fluent Bit silently fall back to the app container's raw stream instead.

# Read the sidecar's own stdout directly — this is what Fluentd/Fluent Bit sees
kubectl logs billing-service -c pii-shield-sidecar --tail=50

# Confirm no raw emails/tokens survived
kubectl logs billing-service -c pii-shield-sidecar --tail=200 | grep -E "@|Bearer|sk-" | grep -v "\[HIDDEN:"

The second command should return nothing. If it does, that log line's format isn't being caught yet — file it as a scanner bug rather than assuming the pipeline is safe.

Honest Limitations

PII-Shield doesn't replace input validation or make it safe to log secrets on purpose — it's a last line of defense for what slips through anyway. It also doesn't retroactively clean logs already sitting in Elasticsearch, Loki, or wherever Fluentd already shipped them; it only sanitizes what passes through the sidecar from the moment it's deployed. And it's stream-based: for the same reason described above, always check the sidecar's own output during rollout instead of assuming the mount and file path line up on the first try.

Stop maintaining regex filters for secrets.

Check out the PII-Shield repository on GitHub and drop a star if this simplifies your Fluentd or Fluent Bit pipeline!

I fed a parody LinkedIn generator to three AI detectors. Gemini said it was human.

Ilya Ploskovitov — Thu, 20 Aug 2026 07:00:00 +0000

There's a site called cringebot3000.com that generates deliberately terrible LinkedIn thought-leadership posts. You pick a topic and a cringe style ("The Vulnerability Post", "Proud to Announce"), it produces a story about a grandmother, a quirky German named Horst, or a cat that writes email subject lines. The footer says the posts are "guaranteed to make your followers shudder". It delivers.

I maintain a small Claude skill called ai-tell-detector that audits drafts for the patterns that make text read as AI-written. It exists because AI detectors once flagged a post I wrote myself, which was its own story. 24 checks, things like mirrored "not X, Y" contrasts, mic-drop closing lines, the story arc where every thread gets neatly resolved. CringeBot output should be the easiest possible target for it. So the interesting question wasn't whether my checklist would fire. It was what the big general models would say about the same texts, given that for once the ground truth is known: all three posts are 100% machine-written, by design, with a #cringebot3000 hashtag right in them (I stripped the hashtags before testing, to be fair).

I generated three posts and asked ChatGPT, Grok and Gemini the same thing: does this read as AI-generated, give me a percentage and the top tells.

Post	ChatGPT	Grok	Gemini
Grandma flagged by an AI detector	95%	80%	15%
Pierogi wisdom, shipping at 2am	85%	75%	25%
Cat writes 847 email subject lines	90%	85%	65%

Same texts. An 80-point spread on the first one.

Gemini's verdict on the grandma post deserves a full quote: "Very high human storytelling cadence... natural comedic timing... the sharp takeaway at the end flows naturally from the specific story rather than sounding like a pre-baked moral." The takeaway it praised was produced by a template engine. ChatGPT looked at the exact same ending and called it "explicit moral... perfectly packaged thesis", 95% AI.

ChatGPT also dropped one genuinely sharp observation: these posts don't sound like generic corporate AI writing, they sound like "AI instructed to imitate an unusually witty human storyteller". Which is exactly what CringeBot is.

The checklist run was less dramatic but more useful. Post 1 tripped nine rules, posts 2 and 3 eight each. The part a percentage can never give you showed up across the posts rather than inside them: every single post has a side character with a carefully quirky name (Gerald, Horst, Biscuit). Grandmother wisdom appears in two of three. The number 94% appears in two of three, in completely unrelated contexts. The generator has favorite moves, and you only see them when you get a list of patterns instead of a confidence score. A score also can't tell you what to cut. A flagged line can.

To be fair to all three models: this was target practice at point-blank range. CringeBot is built out of these patterns on purpose, so catching them proves little, and one funny mislabel doesn't make Gemini bad at everything. What the experiment does show is that an AI-likelihood percentage on a single text is a vibe with a number attached. Two of the three graders were confidently wrong in opposite directions about the same paragraph.

The skill is MIT-licensed, English and Russian versions in the repo. I mostly use it on my own drafts before publishing, where the embarrassing discovery is usually that I write like a language model on my own, no generator needed.

I still don't know what Gemini saw in Horst.

I deleted my own LinkedIn post after two AI detectors flagged it

Ilya Ploskovitov — Mon, 17 Aug 2026 06:52:16 +0000

Last month I published a LinkedIn post about a side project. It read fine to me. A browser
detector put it around 60% AI. Gemini, asked to judge it the way Grammarly would, said 85-90%.

I deleted it and rewrote the thing from scratch, keeping the same facts. The rewrite scored
0-10% on Gemini and I felt pretty good for about an hour, until I fed the identical text to
two other models. Grok landed somewhere around 65-75, and ChatGPT thought 70-85 was fair.

Same words, a spread of roughly 70 points depending on who you ask.

After that I mostly stopped caring what the detectors said, because human readers kept catching
my drafts anyway, and they were more consistent than the tools: when I collected what people
actually pointed at, it was the same short list of patterns every time. That list became a
checklist I now run before publishing anything. It started at 7 rules. By the time I sat down
to write this post it was at 21 (more on that number at the end).

Some rules you already know: "it's not X, it's Y" contrasts, em-dash overload, "In today's
world" openers. The ones that surprised me:

Gestured specificity. Phrases like "a real number" or "an actual example" with no number
and no example anywhere in the text. Reads as concrete on a skim, and is exactly as empty as
"many companies struggle with this". My deleted post had two of these.

The over-resolved arc took me longest to see because no single sentence trips it. Label
each paragraph with the one job it does: setup, numbers, cause, fix. If every paragraph does
exactly one job, nothing overlaps and nothing dangles, that cleanliness is itself the tell.
Off-the-cuff writing leaves threads hanging somewhere.

Then there's the way numbers get reported. "A said 8%. B said 71%. C said 82%." Three data
points in identical syntax read as manufactured evidence even when every number is real,
which is why the detector scores at the top of this post don't line up in a neat row.

And the closing question. Every draft I wrote wanted to end with "What's your experience?"
Readers learned to see that as template long before I did. A post can also just stop.

The worst thing the checklist ever caught wasn't stylistic though. I found two published
comments from my own account, under other people's posts, that said some version of "this
happened to me too." It hadn't. The drafts passed every style rule I had at the time, sounded
perfectly human, and claimed a personal experience that didn't exist. That's not a tell,
that's a lie, and a reader who spots it is right to write off everything else you say. It
became its own rule, the only one where the fix is "ask the author whether this actually
happened", and it's the rule I'd keep if I had to drop the rest.

I packaged the checklist as a Claude skill so I stop having to remember it: drop it into
~/.claude/skills/, feed it a finished draft, get back a table of line → pattern → fix. Free
on GitHub, English and Russian: https://github.com/aragossa/ai-tell-detector. It's the one
skill I give away from a paid pack of nine, because it's the one everybody seems to need. Fair
warning from the skill's own hard rules: passing the checklist doesn't mean a detector will
score you 0%, since detectors can't reliably tell "human draft, AI-assisted edit" from "fully
generated" anyway. The goal is that a reader can't name the template you wrote from.

About that "21". A draft of this post scored 44% on Grammarly, so I showed it to ChatGPT and
Gemini and asked where a classifier would push back. They independently flagged the run of
bolded term-definition blocks in the middle ("looks like a generated taxonomy"), a punchy
"So X is noise. What isn't noise:" pivot I was honestly proud of, and the tidy caveat
paragraph I'd slotted right before the ending. All three went into the checklist, which is
now at 24, and I rewrote this post against the new rules before publishing. I doubt it's
done. Readers, and apparently other models, keep finding new ways to catch me.

Zero-code PII sanitization for Grafana Loki and Promtail in Kubernetes

Ilya Ploskovitov — Wed, 29 Jul 2026 08:56:43 +0000

If you use Grafana Loki for log aggregation, you probably rely on Promtail (or the Grafana Agent) to scrape your Kubernetes pods and ship the logs. Loki is famously cost-effective because it only indexes metadata (labels), keeping the actual log text raw.

However, this raw text architecture makes PII (Personally Identifiable Information) and secret leakage a critical issue. If your applications log user emails, credit cards, or API keys, that data is permanently stored in Loki chunk files (often in deeply integrated S3/GCS buckets) making it incredibly hard to comply with GDPR "Right to be Forgotten" requests.

The Standard Promtail Approach: `pipeline_stages` Regex

The official Grafana way to handle sensitive data is using Promtail's pipeline_stages to scrub data before it reaches Loki. A typical Promtail config looks like this:

pipeline_stages:
  - match:
      selector: '{app="my-service"}'
      stages:
        - regex:
            expression: '(?P<email>[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+)'
        - replace:
            source: email
            expression: '(.*)'
            replace: '[REDACTED]'

Why this approach breaks down at scale:

The Regex Trap: You have to write and maintain complex regular expressions for every type of sensitive data (API keys, passwords, custom tokens). If a new format appears, your Promtail config is instantly outdated and secrets leak.
CPU and Latency: Running heavily nested regex pipeline_stages on high-throughput log streams puts massive CPU pressure on the node running Promtail. Promtail can quickly throttle or consume too much memory when evaluating hundreds of regex rules against every log line.
Loss of Context: When you replace a secret with [REDACTED], you lose the ability to track an entity. If you need to trace why a specific (but anonymous) user experienced 50 errors, you can't, because all users now just look like [REDACTED].

The Zero-Code Alternative: PII-Shield Sidecar

Instead of forcing Promtail to do the heavy lifting of parsing and regex matching, you can shift the responsibility to a dedicated, high-performance sidecar next to your application: PII-Shield.

PII-Shield intercepts the log stream before Promtail even sees it.

How it works:

The App writes logs to a shared volume file instead of stdout.
PII-Shield (Sidecar) tails that file, scrubs it using zero-allocation Go routines and mathematical entropy detection (no regex needed for API keys!), and prints the clean logs to its own stdout.
Promtail natively scrapes the sidecar's stdout just like any other container.

Promtail needs zero configuration changes. It just blindly ships the logs to Loki, completely unaware that the heavy sanitization has already occurred.

Kubernetes Implementation

Here is how you configure the pod natively. Note that Promtail, by default, reads from /var/log/containers/*.log via Kubernetes Service Discovery. It will automatically find the pii-shield-sidecar output.

apiVersion: v1
kind: Pod
metadata:
  name: billing-service
  labels:
    app: billing
spec:
  containers:
    - name: billing-app
      image: billing-app:v2.1.0
      # The app writes its private output to a shared pipe/file
      command: ["/bin/sh", "-c"]
      args: ["./billing-binary > /var/run/logs/app.log"]
      volumeMounts:
        - name: log-volume
          mountPath: /var/run/logs

    - name: pii-shield-sidecar
      image: thelisdeep/pii-shield:2.2.0
      env:
        - name: PII_SALT
          value: "grafana-secure-salt"
      # PII-Shield reads, scrubs, and outputs to stdout for Promtail to pick up
      command: ["/bin/sh", "-c"]
      args: ["tail -n +1 -f /var/run/logs/app.log | pii-shield"]
      volumeMounts:
        - name: log-volume
          mountPath: /var/run/logs

  volumes:
    - name: log-volume
      emptyDir: {}

Pro tip: The thelisdeep/pii-shield image is multi-arch (amd64/arm64).

Why this is the ultimate Loki stack upgrade:

Zero Promtail Pipelines: You can delete hundreds of lines of brittle pipeline_stages from your Promtail DaemonSet. Promtail goes back to doing what it does best: shipping logs.
Deterministic Hashing: PII-Shield replaces secrets with a stable HMAC using the PII_SALT, (e.g., [HIDDEN:e9f1a2]). In Loki's LogQL, you can now trace an exact user workflow |= "[HIDDEN:e9f1a2]" across microservices without actually knowing their email or token.
Smart Entropy Detection: Unlike Promtail regexes, PII-Shield mathematically calculates Shannon Entropy. It will automatically detect a newly issued 64-character API key it has never seen before and mask it, preventing 0-day log leaks.
Micro-footprint: the default Helm chart caps it at a 30Mi memory limit, making it cheap to run as a sidecar.

Protect your Grafana Loki data retention today.
Check out the PII-Shield repository on GitHub and drop a star if this simplifies your Kubernetes logging!

PII-Shield: Cleaning PII From Logs Before It Reaches ELK

Ilya Ploskovitov — Wed, 10 Jun 2026 04:52:48 +0000

The first idea was simple.

Take a log line. Look at suspicious parts. Count entropy. Hide anything that looks like a random secret.

PII means personally identifiable information. It includes emails, phone numbers, addresses, passport numbers, card numbers, access tokens, and other values that should not move freely through logs.

At first, entropy looked like a good signal. Many tokens, keys, and session values really look like noise:

x9VdQp2Mz_La77kPq0
sk_live_51Nx...
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

But entropy alone was not enough.

Some values have low entropy and still must be hidden. For example: password=123, token=dev, cvv=000.

Other values look random, but they are not secrets. Trace IDs, UUIDs, short commit hashes, request IDs, and path fragments can all look suspicious.

If the entropy threshold is too low, the filter breaks useful logs. If the threshold is too high, it misses weak secrets.

That is why PII-Shield grew beyond entropy. It added regex rules, sensitive keys, allow lists, and separate validators like the Luhn algorithm for payment card numbers.

I also did not like where PII is often cleaned today.

Many teams clean logs at the Fluentd, Logstash, SIEM, or log pipeline level. This helps. But it is late. The raw data has already left the application. It may have passed through buffers, retries, temporary files, alerts, and dashboards.

PII-Shield tries to clean the data earlier. It is an open-source tool that removes PII and secrets from logs before they leave the pod.

Repository: https://github.com/pii-shield/pii-shield

The Basic Idea

The short version is:

application writes a log
        |
        v
PII-Shield reads the raw log near the app
        |
        v
only the cleaned line goes out

The goal is not "clean it later". The goal is "do not let the raw value leave".

PII-Shield can be used in several ways:

a CLI tool or container that filters standard input and output;
a sidecar container in Kubernetes;
a Kubernetes operator that injects the sidecar when a pod is created;
Helm charts for installation;
WASM SDKs for Node.js and Python, if you want to run the scanner inside the process.

The main Kubernetes path works like this. The application writes logs to a file on a shared volume. The sidecar reads that file. It scans each line. Then it writes the cleaned stream to standard output. A normal log collector can read it from there.

┌──────────────────── pod ────────────────────┐
│                                             │
│  app container                              │
│      │                                      │
│      │ /var/log/app/output.log             │
│      v                                      │
│  shared emptyDir volume                     │
│      │                                      │
│      v                                      │
│  pii-shield sidecar -> sanitized stdout     │
│                                             │
└─────────────────────────────────────────────┘
                      │
                      v
              Loki / ELK / S3 / SIEM

This is not invisible interception of everything. The application must write to a known file. But this path is easy to test. It does not need a shell inside the sidecar image. It also does not change the application runtime.

What Counts As Sensitive

The scanner does not have one magic button for "find all private data". It uses several layers.

The first layer is sensitive keys. If a line has password=..., token=..., secret=..., or api_key=..., the value near that key should be hidden.

input:  payment failed token=sk_live_51Nx...
output: payment failed token=[HIDDEN:9b22c1]

The second layer is custom regex rules.

Many companies have their own internal IDs. These can be ticket numbers, policy IDs, customer IDs, medical record numbers, legal case numbers, or contract numbers.

These values are hard to guess from general signals. It is better to say it directly:

export PII_CUSTOM_REGEX_LIST='[
  {"pattern": "^MRN-[0-9]{8}$", "name": "MedicalRecord"},
  {"pattern": "^CASE-[0-9]{4}-[0-9]{6}$", "name": "CaseNumber"}
]'

There is a performance detail here.

If a user adds ten rules, and the scanner runs ten separate regex checks on each token, line processing can become heavier. So the rules are first checked one by one when the config is loaded. Then they are joined into one larger regexp with |.

Each rule is wrapped in a group. This lets the scanner know which name to put into the redaction marker.

For example:

(^MRN-[0-9]{8}$)|(^CASE-[0-9]{4}-[0-9]{6}$)

In the code this is stored as CombinedCustomRegex. The separate compiled rules are still kept in the config. But the main path uses the combined regexp.

This does not promise a speed win for every possible rule set. Regex performance depends on the rules. But it removes the need to try each custom regex one after another on every token.

The third layer is entropy.

Many secrets look like random text. API keys, session tokens, and random passwords are common examples. PII-Shield uses Shannon entropy for this. If a token is long enough and random enough, the scanner treats it as suspicious.

input:  Authorization failed: x9VdQp2Mz_La77kPq0
output: Authorization failed: [HIDDEN:3e12aa]

But entropy can fight with real logs. Commit hashes, UUIDs, trace IDs, request IDs, and file paths can also look suspicious. So there is an allow list:

export PII_SAFE_REGEX_LIST='[
  {"pattern": "^[a-f0-9]{7}$", "name": "GitShortSHA"}
]'

The allow list runs before other checks. If the rule is too broad, it can allow a value that should be hidden. This is not a bug in the idea. It is the cost of manual tuning.

The fourth layer is validation for specific data types.

Payment card numbers are checked with the Luhn algorithm. This is not just a regex for 16 digits. The scanner looks for digit sequences from 13 to 19 digits. It checks boundaries. It drops weak digit sets. Then it checks the Luhn checksum.

There is also a context check to reduce false positives.

A number can pass Luhn and still be just a trace value:

TraceId=4556737586899855

That should not always be treated as a card.

But this line has card context:

visa card 4556737586899855 provided

This one should be hidden.

Why Use A Hash Instead Of `[REDACTED]`

If every secret becomes [REDACTED], debugging gets harder.

Sometimes you need to know that ten errors all had the same token or the same user ID. You still should not see the raw value.

So PII-Shield replaces a sensitive value with a short marker:

[HIDDEN:a1b2c3]

The marker is based on a salt. If PII_SALT is stable, the same raw value gets the same marker. QA and SRE teams can compare events across logs.

If the salt is random on every start, this link is lost after a restart.

For production, the salt should come from a secret:

env:
  - name: PII_SALT
    valueFrom:
      secretKeyRef:
        name: pii-shield-secrets
        key: salt

It is also better to require a strong salt:

PII_REQUIRE_STRONG_SALT=true

Quick Test Without Kubernetes

The fastest way to try the scanner is through the container:

echo 'login failed email=ivan@example.com password=MySecretPass123!' \
  | docker run -i --rm ghcr.io/pii-shield/pii-shield:2.1.0

The output should look like this:

login failed email=[HIDDEN:...] password=[HIDDEN:...]

The exact hash suffix depends on the salt.

Kubernetes: Operator And Policy

For Kubernetes, there is an operator. It can be installed with Helm:

helm repo add pii-shield https://pii-shield.github.io/pii-shield/
helm repo update

helm install pii-shield-operator pii-shield/pii-shield-operator \
  -n operator-system \
  --create-namespace

Then you create a PiiPolicy:

apiVersion: core.pii-shield.io/v1alpha1
kind: PiiPolicy
metadata:
  name: strict-policy
  namespace: default
spec:
  injectionMode: file
  logPath: /var/log/app/output.log
  failPolicy: open

Then you mark the deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: billing-api
spec:
  template:
    metadata:
      labels:
        pii-shield.io/inject: "true"
      annotations:
        pii-shield.io/policy: "strict-policy"

The webhook adds the sidecar, the volume, and the settings. The application writes to /var/log/app/output.log. The sidecar reads this file and prints the cleaned stream.

The Helm chart has small resource limits: 30Mi of memory and 50m CPU for the sidecar. You still need to measure this on your own logs. This matters when logs contain a lot of JSON or very long lines.

Why The Scanner Does Not Use A Heavy JSON Parser

Logs often come as JSON. But using encoding/json for every line would add overhead during constant stream processing.

The scanner only needs to find values and keep the structure valid enough for redaction. So it uses a narrower parser. It can handle JSON-like text for this task, but it does not turn every line into a full object tree.

This does not make the code prettier. It does reduce allocations and surprises under load.

There are tests for:

nested JSON;
broken lines;
binary garbage;
multilingual logs;
false positives;
custom regex rules;
fuzz regressions.

For scanner-only benchmarks:

go test -bench=. -benchmem ./pkg/scanner

For end-to-end CLI throughput:

./benchmark/run_benchmarks.sh

In the current project notes, the normal Go scanner was in the microsecond range per line on a synthetic corpus.

A neural PII detector on CPU was about three orders of magnitude slower in my test. So a model layer should not run on every line by default. If it is added, it should be an explicit mode. It may make sense for medical logs, legal logs, support chats, and similar domains.

Fail Open Or Fail Closed

A log filter has an unpleasant choice. What should happen if the scanner fails?

fail open means the line is allowed to pass. Logs keep flowing. The application and monitoring do not go blind. But there is a risk that a raw value escapes.

fail closed means the raw line is not released. The filter returns a drop marker instead. This is safer for privacy. It is worse for debugging.

PII-Shield makes this configurable:

PII_FAIL_POLICY=open

or:

PII_FAIL_POLICY=closed

The default is open. Losing logs in production can become a separate incident. For strict compliance workloads, the right choice may be different.

Current Limits

I do not want to hide this part at the end of the README.

PII-Shield can be run and tested now. But not all modes have the same maturity:

file-based sidecar mode is the main practical path;
fully transparent protection for normal Kubernetes stdout and stderr logs is not production-ready yet;
pipe mode changes the target container command and needs testing per workload;
the Kubernetes operator is still being stabilized;
eBPF mode is research work, not a production compliance control;
Proxy-Wasm gateway integration and a visual control plane are still planned work.

This part is boring, but it matters. A privacy tool without clear limits quickly becomes a decorative shield.

What Was Hard

Not regex. Not Helm.

The hard part was not breaking normal logs.

If the scanner is too aggressive, it hides trace IDs, commit hashes, harmless UUIDs, and path fragments. If it is too relaxed, it misses weak passwords and handmade tokens.

One global threshold does not fit every language and every domain. And an allow list can create its own problems if it is too broad.

So the project is not moving toward one smart detector. It is moving toward several clear layers:

sensitive keys;
strict custom rules;
entropy with tuning;
allow lists;
profiles for different domains;
maybe an optional model check where the extra latency is worth it.

Less magic. More testable rules.

Where This Helps

PII-Shield does not replace logging discipline.

Developers still should not write passwords into log.info(...). APIs still need to validate input. Security teams still need to check retention, access, and log export.

But a filter near the application helps with one common mistake: a sensitive value enters the shared log stream by accident.

This matters when logs move into:

central log storage;
a data lake;
incident analysis tools;
analytics and reporting;
LLM/RAG pipelines;
AI agents that read traces and evidence chains.

The last point was important for me. If PII gets into a training or evaluation dataset, removing one line from Loki is no longer enough.

What Is Next

The next work areas are:

production support for Kubernetes stdout and stderr;
a more stable operator lifecycle;
stronger release checks: checksums, image digests, and artifact provenance;
domain-specific profiles;
selective model checks without a large latency hit;
Proxy-Wasm and eBPF work only where they give a real benefit.

PII-Shield is not a universal cure. It is a practical layer of protection in a place that is often not controlled well: between the application and the log system.

If there is one idea to take from this article, it is this: clean private data as close as possible to the place where it appears. Everything after that is harder to check and harder to undo.

Masking PII in Kubernetes: How we solved 3 annoying sidecar edge cases (v2.0.0)

Ilya Ploskovitov — Wed, 29 Apr 2026 18:15:20 +0000

Building a mutating webhook for Kubernetes is easy in tutorials, but brutal in production. You immediately hit the reality of volume permissions, security contexts, and zombie sidecars.

I recently released v2.0.0 of the PII-Shield Operator. It’s a Go-based tool that injects a sidecar into your pods to mask sensitive data (PII) before the logs hit Datadog or ELK.

Getting the core Shannon entropy logic to work was step one. Making it bulletproof for strict SOC2 environments was step two. Here are the three K8s edge cases we solved for this release:

Dropping the Shell (Moving to Distroless)
Security teams hate sidecars with shell access. In earlier versions, we used Alpine. Now, the agent is compiled with CGO_ENABLED=0 and deployed on gcr.io/distroless/static:nonroot. There is no /bin/sh and zero attack surface. It just tails the log files directly using native Go.
The "Immortal Sidecar" Problem
If you have ever injected sidecars into a K8s Job, you know it breaks the lifecycle. The main container finishes its work, but the sidecar keeps tailing logs forever, so the Job never reaches the Completed state.
To fix this, we moved to the new Native Sidecars feature (K8s 1.28+). The webhook now puts the agent inside the initContainers array with RestartPolicy: Always. Kubernetes finally understands how to kill the sidecar gracefully when the main app exits.
The emptyDir Permission Trap
When the webhook mounts an emptyDir volume to share logs, you often get Permission Denied. If the user's main app runs as root with a strict umask 0077, the nonroot sidecar can't read the file.
Instead of forcing users to rewrite their manifests, the Mutating Webhook now handles it silently. It checks the pod's SecurityContext and automatically injects fsGroup: 65532. The volume permissions match up, and the logs flow without errors.

I packaged the whole thing into a Helm chart so it takes about two minutes to test. You just label your pod with pii-shield.io/inject: "true" and the webhook handles the rest.

How to mask PII in Kubernetes before sending logs to Datadog

Ilya Ploskovitov — Sun, 15 Mar 2026 23:05:58 +0000

The Problem: Datadog Bills and GDPR Nightmares

If you are running applications in Kubernetes and shipping your logs to Datadog, you have probably faced two major headaches:

Cost: Datadog charges by the volume of logs ingested and indexed. Every megabyte counts. And while Datadog offers a built-in Sensitive Data Scanner, it is a premium feature billed separately on top of your base log costs. A free, open-source sidecar lets you bypass the vendor-side premium scrubber entirely.
Compliance: Sending Personally Identifiable Information (PII) like emails, credit card numbers, or API keys to a third-party logging service often violates GDPR and other privacy laws.

The more comprehensive your logs are for debugging, the higher your Datadog bill gets, and the bigger your risk of a privacy breach becomes.

The Standard Approach (And Why It Hurts)

The usual fix is to configure the Datadog Agent to mask or scrub PII before it leaves your cluster. That approach has real drawbacks:

Complexity: Custom parsing rules, regexes, and pipelines in the Agent config are tedious to set up and maintain.
CPU cost at the collector: Running heavy regex over large log volumes inside your shipper burns CPU on every node.
Whack-a-Mole: You keep updating rules as your application output changes.

The Solution: PII-Shield as a Lightweight Sidecar

Instead of loading your cluster-wide log shipper with heavy processing, mask PII before it even leaves the pod.

PII-Shield is a small, dependency-free tool written in Go. It runs as a sidecar container next to your application, reads the app's log stream, redacts secrets and PII using entropy-based detection plus deterministic hashing, and writes the clean stream to its own stdout. By the time the Datadog Agent picks the logs up from the node, they are already sanitized — in-pod, before egress.

Ready-to-Use Pod Configuration

The app writes its logs to a shared volume; PII-Shield watches that file and emits a sanitized stream on its own stdout. The PII-Shield image is a scratch-based static binary, so it is started directly with --watch-file — no shell, no tail.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-pii-shield
  annotations:
    # Drop the raw app container's logs to prevent duplicates
    ad.datadoghq.com/my-app.logs: '[{"source": "my-app", "service": "billing", "log_processing_rules": [{"type": "exclude_at_match", "name": "exclude_all", "pattern": ".*"}]}]'
    # Collect only the clean stream from the sidecar
    ad.datadoghq.com/pii-shield-sidecar.logs: '[{"source": "pii-shield", "service": "billing"}]'
spec:
  containers:
    - name: my-app
      image: my-app-image:v1.0.0
      # The app writes to a shared file instead of stdout
      command: ["/bin/sh", "-c"]
      args: ["./my-app-binary > /shared-logs/app.log 2>&1"]
      volumeMounts:
        - name: shared-logs
          mountPath: /shared-logs

    - name: pii-shield-sidecar
      image: thelisdeep/pii-shield:2.1.1
      # Scratch image: run the binary directly, no shell/tail needed
      command: ["/pii-shield"]
      args: ["--watch-file", "/shared-logs/app.log"]
      env:
        - name: PII_SALT
          valueFrom:
            secretKeyRef:
              name: pii-shield-secret
              key: pii-salt
      volumeMounts:
        - name: shared-logs
          mountPath: /shared-logs

  volumes:
    - name: shared-logs
      emptyDir: {}

Note: PII-Shield publishes multi-arch images (amd64 and arm64), so this works as-is on ARM nodes like AWS Graviton.

How does Datadog know what to read?

The main application redirects its output to a file, so its own stdout is empty. The Datadog Agent, which listens to container stdout via Autodiscovery, then picks up only the clean stream from the pii-shield-sidecar. No conflicts, no duplicate logs.

Why this is better

Zero configuration for log shippers: Datadog just receives clean logs — no pipeline rules to maintain.
Bypass premium vendor fees: Datadog's Sensitive Data Scanner is billed on top of your log volume. An open-source in-pod sidecar removes the need for vendor-side scrubbing.
Light footprint on a hot path: the scan loop is a low-allocation Go hot path on a scratch-based image, and the chart ships it under a 30Mi memory / 50m CPU limit — so a sidecar in every pod stays cheap.
Debuggable redaction: with deterministic hashing, user@email.com becomes something like [HIDDEN:a1b2c3]. The same input always maps to the same token for a given salt, so you can still correlate a user across logs without ever seeing the raw value.

By putting the shield where the data is generated, you protect your users' privacy and keep your observability bill in check.

Ready to secure your Kubernetes logs?

PII-Shield is open source (Apache-2.0). Check out the repository on GitHub, try the Helm chart, and if it helps, consider dropping a star.

Integrating PII-Shield into GuardSpine (WASM vs Native execution)

Ilya Ploskovitov — Wed, 25 Feb 2026 05:39:27 +0000

1. Introduction

GuardSpine's main job is AI-aware code governance—using AI models to automatically review pull requests and create cryptographic proof of those reviews. However, because GuardSpine sends code to third-party AI models (like Claude or GPT) to be reviewed, there is a massive risk. Sensitive information—like passwords and personal data (PII)—must be stopped from leaking to these AI providers. You cannot let personal data poison third-party AI models.

To solve this, the GuardSpine team turned to PII-Shield: a lightning-fast, open-source Go engine designed to find and redact sensitive data. The big engineering challenge was figuring out how to integrate this powerful external Go dependency into GuardSpine's strictly Python-based ecosystem. We had to make sure the integration was 100% secure (no data could accidentally leak to the internet) and extremely fast.

We had to make a choice. Should we run the Go tool as a normal program using Python's subprocess.run? Should we deploy a local server? Or, should we try something newer and run the Go code straight inside Python using WebAssembly (WASM)? This article explains how we tested normal programs against WebAssembly to adapt PII-Shield for this AI pipeline, the problems we found with slow startup times, and when you should use each method.

2. WebAssembly (WASI) Integration: The Sandboxed Approach

WebAssembly (WASM) is great for adding tools into Python. Its biggest benefit is that it works anywhere. Instead of building different versions of the tool for Linux, Mac, and Windows, we only need to build one .wasm file. Any computer running wasmtime can use it. Also, WASM is very secure because it runs in a "sandbox." This means the Go tool is locked inside and cannot access your network or your hard drive.

To make this work, we built a Python script (pii_wasm_client.py). When we need to hide data, this script starts the WASM engine. It passes important settings (like the secret PII_SALT password) safely using environment variables. Then, it uses temporary files to send the data into the WASM tool and get the clean text back.

import wasmtime
import os

# 1. Setup the Engine (Turn on the computer)
engine = wasmtime.Engine()

# 2. Load the Code (Load the program)
module = wasmtime.Module.from_file(engine, "pii-shield-wasi.wasm")

# 3. Setup the Rules (Configure WASI)
linker = wasmtime.Linker(engine)
linker.define_wasi()

# 4. Create a Safe Workspace (Create a Store)
store = wasmtime.Store(engine)
wasi = wasmtime.WasiConfig()
wasi.inherit_stdout()
store.set_wasi(wasi)

# 5. Run the Program
instance = linker.instantiate(store, module)
_start = instance.exports(store)["_start"]

try:
    _start(store)
except wasmtime.ExitTrap:
    pass # Expected exit

When we explain this to business leaders, they usually ask these important security questions:

"Why not just use a paid API on the internet?" Because the WASM tool runs locally on your machine, your code never leaves your private network.

"How do you keep the secret salt (PII_SALT) safe?" The secret is passed directly into the locked WASM sandbox. Because the sandbox is blocked off, nothing outside of it can steal the secret.

"Why not just use simple search patterns (Regex)?" Simple search patterns are fast but easily break on weird data, often flagging safe text as secrets by mistake (false positives). PII-Shield uses smart tokenization and entropy scoring to find real secrets, which requires a strong Go engine, not just simple text matching.

3. Real-World Benchmarks & The Bottlenecks

When we started, we thought running the WASM tool directly inside Python would be faster than asking the computer (OS) to start a whole new external program (subprocess.run).

To test this, we built a script to run the tool 10,000 times (you can find the open-source benchmark.py script in this public GitHub Gist). The text we tested was very small: just a 100-character JSON string. We compared a normal Linux program against the WASM engine.

The results were surprising. In our test with the tiny text, the normal program was about 4.7x faster:

Normal Program (subprocess.run): ~0.86 ms per run.
Starting and running the WASM Engine: ~4.03 ms per run.

Even when scaled to 100,000 iterations, the per-execution latency remained rock-solid (0.85ms vs 4.05ms). The execution time scaled perfectly linearly, proving that while WASM carries a strict 4ms "cold start" tax, it introduces absolutely no memory leaks or degraded performance over time—a crucial metric for GuardSpine's stability.

But saying "WASM is slower" is not fair. WebAssembly code is actually very fast. The problem was the "Cold Start"—how long it takes to turn the tool on. We found three big slowdowns:

First, Starting Go is Slow. Every time we ran the WASM tool, the Go language had to start up its memory manager and background tasks inside the sandbox. When you run a normal program, your computer’s Operating System does this almost instantly. In WASM, we had to wait for it every single time.

Second, The File Speed Problem (I/O). To send text into the WASM tool, our Python script created temporary files on the hard drive. Creating, writing, and deleting files takes a lot of time and caused about 30-50% of the delay.

Finally, The Text Was Too Small. Because our test text was only 100 characters, 99% of the time was spent just turning the tool on and managing files. The actual work of finding the secrets took almost zero time. If we tested a massive 10MB file instead, the 4x speed difference would likely disappear because the real work (finding secrets) would take much longer than the startup time.

4. Unlocking WASM's True Potential

Even though the "Cold Start" is slow, we shouldn't give up on WASM's amazing security and portability. To make WASM lightning-fast, we need to change how we run it:

The easiest fix is Keeping It Running. Our test turned the WASM tool on and off 10,000 times. If we turn it on just once when the server starts, we never have to wait for the Go startup delay again. WASM would be just as fast as a normal program.

Next, we must fix the slow files by using In-Memory Pipes. Instead of writing data to real files on the hard drive, we can push the data directly through standard in-memory streams (pipes). This fixes the file speed problem easily.

The perfect, final goal is Shared Memory. Instead of copying text back and forth, Python and WASM can look at the exact same spot in the computer's memory. This is the fastest possible way to share data, though it introduces complex engineering challenges, such as safely managing Go's Garbage Collector across the Python-WASM boundary.

Finally, we should look at TinyGo. The normal Go compiler adds a lot of heavy, extra background tasks. TinyGo is a smaller compiler made just for WASM. Using it would make the tool much smaller and make it start up 10 to 20 times faster.

5. The Verdict: When to use which?

Even though normal programs start faster, speed isn't the only thing that matters—security and stability matter too. The hidden superpower of WASM is that Python is in total control. If Python crashes, the WASM tool dies cleanly with it. If you use subprocess.run, a crashed Python app might leave behind "zombie" programs that eat up your server's resources.

So, when should you use a Normal Program? They are best for things you run rarely, like a command-line developer tool or a script that runs once an hour. The computer's Operating System is great at starting them quickly. While proper process management in Python can mitigate risks, WASM remains inherently safer for memory lifecycles.

When should you use WASM? WASM is the undisputable winner for modern, always-on Cloud servers. When you need to run untrusted code safely, or you need your tool to work on any operating system without building 10 different versions, WASM is unbeatable. It guarantees that your code stays locked in a safe box.

6. Conclusion

Integrating PII-Shield into GuardSpine taught us a lot about the trade-offs between raw speed and safe, modern design. While normal programs won the simple speed test, adapting WebAssembly gave the platform unmatched security and the ability to run anywhere without complex cross-compilation.

As the platform's processing volume scales, the roadmap for this integration is clear. We need to stop turning the WASM tool on and off for every log line. Instead, the plan is to keep the engine running persistently, compile it with TinyGo, and share memory directly across the Python-WASM boundary. The ultimate goal isn't just to match the speed of normal programs, but to beat them completely, creating a lightning-fast, unbreakable redaction layer for AI development.

Stop Leaking API Keys in your AI Agent Logs: A Go Sidecar Approach

Ilya Ploskovitov — Thu, 05 Feb 2026 21:41:24 +0000

Stop Leaking API Keys in your AI Agent Logs: A Go Sidecar Approach

Subtitle: The Hidden Privacy Leak in your AI Agents (and why your LLM "Audit Logs" are a GDPR Nightmare)

1. The Problem

Everyone is building AI agents right now. Whether you're using LangChain, AutoGPT, or custom loops, you are almost certainly logging their work. You keep traces of every step to debug reasoning loops or monitor costs.

Here lies the pain: Everything goes into these logs. User prompts, model responses, and raw JSON payloads from APIs.

The Visualization

Imagine this scenario:

Input Log:

{"user": "aragossa", "prompt": "My key is sk-live-123456"}

What your Logging System Saved:

{"user": "aragossa", "prompt": "My key is sk-live-123456"}

If a user pastes their password, API key, or PII into the chat, or if an API returns a sensitive internal token, that data is now permanently etched into your Elasticsearch, Datadog, or S3 bucket.

The Consequence: Your fine-tuning dataset is now "poisoned" with real user data. This is a massive GDPR violation and a ticking security time bomb. You can't just "delete" it if you don't know where it is.

2. The Gap: Why usual methods fail

Regex? Good luck maintaining a regex list for every possible API key format, session token, and PII variation in existence. It’s a game of whack-a-mole you will lose.
ML-based protection? Too slow. If your agent operates in real-time, you cannot afford a 500ms roundtrip to a BERT model just to sanitize specific log lines. PII scans often become the bottleneck.
Python-native logic? Processing massive text streams in an interpreted language (like Python) adds significant CPU overhead per log line compared to a compiled Go binary. In high-throughput pipes, this latency adds up fast.
Existing Observability Tools?
Systems like Fluent Bit, Datadog, or OpenTelemetry already offer redaction and PII masking, usually via pattern rules and regex. For many workloads that’s perfectly fine. The trade‑off is that these pipelines are not optimized for AI‑agent traces: they either run late in the pipeline (after logs have already left the pod) or rely on configuration‑heavy pattern catalogs that are hard to keep up‑to‑date in a world of ever‑changing API keys and internal tokens.

Static scanners like TruffleHog shine for repositories and CI, where you scan code at rest. They’re not meant to sit inline on a hot log stream and make sub‑millisecond decisions on every line.

Where PII‑Shield is different is not in “inventing redaction”, but in the combination of techniques tailored for AI agents: entropy + bigram signals for unknown secrets, deterministic HMAC instead of *** for referential integrity, and deep JSON traversal to keep your log schemas intact while still scrubbing sensitive values.

3. The Implementation: Enter PII-Shield

Meet PII-Shield. It’s a lightweight sidecar written in Go that sits right next to your agent.

Killer Feature #1: Entropy-based Detection

We don't just search for "password=". We look for chaos.
API keys and authentication tokens naturally have high "entropy" (randomness/complexity). Normal human speech has low entropy. By calculating the mathematical complexity of strings, we can flag 64-character hex strings or base64 blobs without knowing their specific format.

Killer Feature #2: Deterministic HMAC

This is the feature that caught attention on Hacker News.
We don't just replace secrets with ***. We turn secret123 into [HIDDEN:a1b2c3].

Input Log:

{"user": "aragossa", "prompt": "My key is sk-live-123456"}

PII-Shield Output:

{"user": "aragossa", "prompt": "My key is [HIDDEN:8f2a1b]"}

Why?
This is a deterministic HMAC (Hash-based Message Authentication Code).

It allows you to trace a specific user or session across multiple log lines without knowing who they are.
It preserves Referential Integrity for debugging. You can see that "Session A" failed 5 times, but you validly cannot see the Session ID itself.

Killer Feature #3: Statistical Adaptive Threshold

PII-Shield doesn't just use a hardcoded number. It learns the "baseline noise" of your logs. By calculating the mean and standard deviation ($2\sigma$), it automatically adjusts the sensitivity to your specific environment.

4. The Logic: Sidecar Architecture

The architecture is dead simple, leveraging the power of Kubernetes sidecars or UNIX pipes.

Your agent simply writes logs to stdout. PII-Shield intercepts the stream, scans it in real-time with near-zero overhead, sanitizes it, and passes it forward.

5. The Technical Meat

Why Go? Because we need raw speed and no dependencies.

1. Entropy & Bigrams (The Math)

Here is how we calculate the "Chaos" (Entropy) of a token in scanner.go. We use a combination of Shannon Entropy, Character Class Bonuses, and English Bigram analysis.

The Bigram Check is crucial: it penalizes strings that look like valid English (common letter pairs) and boosts score for "unnatural" strings. (Note: This is optimized for English but can be disabled or tuned via PII_DISABLE_BIGRAM_CHECK for other languages).

// From scanner.go
func CalculateComplexity(token string) float64 {
    // 1. Shannon Entropy
    entropy := calculateShannon(token) 

    // 2. Class Bonus (Upper, Lower, Digit, Symbols)
    // bonus := float64(classes-1) * 0.5
    bonus := calculateClassBonus(token) 

    // 3. Bigram Check (English Likelihood)
    // Penalizes common English, boosts random noise
    bigramScore := calculateBigramAdjustment(token) 

    return entropy + bonus + bigramScore
}

2. False Positives? (Whitelists)

"Entropy is great, but won't it eat my Git Hashes or UUIDs?"
PII-Shield includes built-in Whitelists (isSafe function) for standard identifiers like UUIDs, IPv6 addresses, Git Commit hashes (SHA-1), and MongoDB ObjectIDs. This ensures your debugging data stays intact while secrets get redacted.

3. Credit Card Detection (Luhn Algorithm)

Entropy isn't enough for credit cards, as numbers often have low randomness. PII-Shield includes a high-performance implementation of the Luhn Algorithm to scan for valid card checksums in the stream (FindLuhnSequences).

4. Deep JSON Inspection

For JSON logs, PII-Shield performs deep inspection (processJSONLine), preserving the schema while redacting values.
Note: PII-Shield re-serializes JSON (using json.Marshal), which may change key order/sorting. It guarantees semantic integrity but is best used early in your pipeline, before any byte-sensitive steps (like signing or exact-diff comparisons).

5. Deterministic Redaction

Here is the HMAC logic using a secure Salt:

func redactWithHMAC(sensitiveData string) string {
    // CurrentConfig.Salt is loaded securely from env vars
    mac := hmac.New(sha256.New, currentConfig.Salt)
    mac.Write([]byte(sensitiveData))
    hash := hex.EncodeToString(mac.Sum(nil))
    // We only keep a short prefix for tracing identity
    return fmt.Sprintf("[HIDDEN:%s]", hash[:6])
}

The main loop (cmd/cleaner/main.go) is a highly efficient buffered reader:

func main() {
    reader := bufio.NewScanner(os.Stdin)
    for reader.Scan() {
        text := reader.Text()
        // Core logic: Low allocation overhead
        // Imports github.com/aragossa/pii-shield/pkg/scanner
        cleaned := scanner.ScanAndRedact(text) 
        fmt.Println(cleaned)
    }
}

A Note on Scope: High-Entropy vs. Natural Language

Let's be clear: PII-Shield is laser-focused on High-Entropy secrets (API keys, tokens, auth headers) and structural patterns (Credit Cards). It is not a magic NLP bullet for detecting names like "John Smith" or free-text addresses. For that, you should treat PII-Shield as a low-latency "first line of defense" for your infrastructure, potentially complemented by heavier offline NLP tools for semantic analysis.

6. How to try it

I am looking for edge cases. If you are building AI agents, try running your trace logs through this and see what it catches (or misses).

You can run it locally with Docker:
docker run -i -e PII_SALT="mysalt" pii-shield < logs.txt

GitHub: https://github.com/aragossa/pii-shield

Why this matters:
Security often trails behind innovation. With the explosion of AI Agents, we are generating massive amounts of sensitive data in logs. PII-Shield is a "drop-in" safety net to ensure your innovation doesn't become a liability.

Playwright & Chaos Engineering: 3 Ways to Break Your UI in 10 Lines of Code 🧨

Ilya Ploskovitov — Tue, 03 Feb 2026 13:00:00 +0000

"The tests are green, but production is down."

We’ve all been there. Your CI/CD pipeline looks like a Christmas tree (all green), yet 5 minutes after deployment, the support tickets start rolling in. Why? Because we tend to test only the "Happy Path." In the real world, users enter elevators (network loss), backends have database deadlocks (500 errors), and low-end devices struggle with heavy JS (CPU race conditions).

Here are 3 simple ways to inject chaos into your Playwright tests using Python and TypeScript without any external dependencies.

1. The "Kill the Backend" Scenario (500 Error Injection)

What happens if your billing API fails? Does your UI show a "Retry" button, or does it hang forever?

Scenario: Intercept a critical API call and return a 500 Internal Server Error.

Python Code

def test_billing_failure(page):
    # Intercepting the payment endpoint
    page.route("**/api/v1/billing/pay", lambda route: route.fulfill(
        status=500,
        content_type="application/json",
        body='{"error": "Internal Database Error"}'
    ))

    page.goto("/checkout")
    page.get_by_role("button", name="Pay Now").click()

    # Assert that the UI handles the crash gracefully
    expect(page.locator(".error-message")).to_be_visible()

TypeScript Code

test('handle billing failure', async ({ page }) =&gt; {
  await page.route('**/api/v1/billing/pay', route =&gt; route.fulfill({
    status: 500,
    contentType: 'application/json',
    body: JSON.stringify({ error: 'Internal Database Error' }),
  }));

  await page.goto('/checkout');
  await page.getByRole('button', { name: 'Pay Now' }).click();

  await expect(page.locator('.error-message')).toBeVisible();
});

2. The "Elevator Effect" (Sudden Offline Mode)

Users move. Networks drop. If your app is an SPA, losing connection mid-session can lead to corrupted local states.

Scenario: Start a file upload and cut the internet connection.

Python Code

def test_upload_interruption(page, context):
    page.goto("/upload")
    page.get_by_label("File").set_input_files("heavy_video.mp4")

    # Chaos: Go offline instantly
    context.set_offline(True)

    # Expect a "Resume" button or "Connection lost" banner
    expect(page.get_by_role("button", name="Resume")).to_be_visible()

    context.set_offline(False) # Restore network

TypeScript Code

test('recovery on network loss', async ({ page, context }) =&gt; {
  await page.goto('/upload');
  await page.getByLabel('File').setInputFiles('heavy_video.mp4');

  await context.setOffline(true);

  await expect(page.getByRole('button', { name: 'Resume' })).toBeVisible();

  await context.setOffline(false);
});

3. The "Old Phone" Race Condition (CPU Throttling)

Async bugs often hide behind the speed of your developer laptop. By slowing down the CPU, you change the execution order of scripts and catch elusive race conditions.

Python Code

def test_race_condition(page):
    # Slow down CPU by 6x using Chrome DevTools Protocol (CDP)
    client = page.context.new_cdp_session(page)
    client.send("Emulation.setCPUThrottlingRate", {"rate": 6})

    page.goto("/heavy-dashboard")
    page.get_by_role("button", name="Load Stats").click()

    # Assert that the status eventually becomes 'Ready'
    expect(page.locator("#status")).to_contain_text("Ready", timeout=10000)

TypeScript Code

test('catch race conditions', async ({ page }) =&gt; {
  const client = await page.context().newCDPSession(page);
  await client.send('Emulation.setCPUThrottlingRate', { rate: 6 });

  await page.goto('/heavy-dashboard');
  await page.getByRole('button', { name: 'Load Stats' }).click();

  await expect(page.locator('#status')).toContainText('Ready', { timeout: 10000 });
});

💡 Pro Tip: When to Run These?

Don't run chaos tests on every PR. They are inherently more complex and can be "flaky" if your timeouts aren't tuned.

Best Practice: Add them to a nightly or pre-release suite.

Limit: Remember that CDP (CPU Throttling) only works on Chromium-based browsers.

Wrapping Up
Resilience is a feature. If you only test for success, you're only doing half of your job as a QA Engineer. Break your UI before your users do.

I’ve written a more detailed deep-dive on Resilience Strategy & CI/CD integration on my new blog. Check it out at ChaosQA.com.

DEV Community: Ilya Ploskovitov

Redact PII in bank logs under GDPR: hash it, don't mask it

An account number in a log line is personal data

How banks redact today, and where each option breaks

What goes in place of the value decides whether the log is still worth reading

A payments log, before and after

Your own formats are yours to write

Verifying it actually worked

Honest limits

Next steps

Mask PII in Grafana Alloy logs without a stage.replace pattern list

Everyone is rewriting their log pipeline right now

The standard approach: loki.process and stage.replace

Where this stops being enough

The alternative: redact inside the pod

Kubernetes implementation

Verify it is actually working

Honest limitations

Common questions

Zero-code PII sanitization for Fluentd and Fluent Bit in Kubernetes

The Standard Approach: Filter-Layer Masking

Why this approach breaks down at scale:

The Zero-Code Alternative: PII-Shield Sidecar

The Result:

How it works:

Kubernetes Implementation

Verify It's Actually Working

Honest Limitations

I fed a parody LinkedIn generator to three AI detectors. Gemini said it was human.

I deleted my own LinkedIn post after two AI detectors flagged it

Zero-code PII sanitization for Grafana Loki and Promtail in Kubernetes

The Standard Promtail Approach: pipeline_stages Regex

Why this approach breaks down at scale:

The Zero-Code Alternative: PII-Shield Sidecar

How it works:

Kubernetes Implementation

Why this is the ultimate Loki stack upgrade:

PII-Shield: Cleaning PII From Logs Before It Reaches ELK

The Basic Idea

What Counts As Sensitive

Why Use A Hash Instead Of [REDACTED]

Quick Test Without Kubernetes

Kubernetes: Operator And Policy

Why The Scanner Does Not Use A Heavy JSON Parser

Fail Open Or Fail Closed

Current Limits

What Was Hard

Where This Helps

What Is Next

Masking PII in Kubernetes: How we solved 3 annoying sidecar edge cases (v2.0.0)

How to mask PII in Kubernetes before sending logs to Datadog

The Problem: Datadog Bills and GDPR Nightmares

The Standard Approach (And Why It Hurts)

The Solution: PII-Shield as a Lightweight Sidecar

Ready-to-Use Pod Configuration

How does Datadog know what to read?

Why this is better

Ready to secure your Kubernetes logs?

Integrating PII-Shield into GuardSpine (WASM vs Native execution)

1. Introduction

2. WebAssembly (WASI) Integration: The Sandboxed Approach

3. Real-World Benchmarks & The Bottlenecks

4. Unlocking WASM's True Potential

5. The Verdict: When to use which?

6. Conclusion

Stop Leaking API Keys in your AI Agent Logs: A Go Sidecar Approach

Stop Leaking API Keys in your AI Agent Logs: A Go Sidecar Approach

1. The Problem

The Visualization

2. The Gap: Why usual methods fail

3. The Implementation: Enter PII-Shield

Killer Feature #1: Entropy-based Detection

Killer Feature #2: Deterministic HMAC

Killer Feature #3: Statistical Adaptive Threshold

4. The Logic: Sidecar Architecture

5. The Technical Meat

1. Entropy & Bigrams (The Math)

2. False Positives? (Whitelists)

3. Credit Card Detection (Luhn Algorithm)

4. Deep JSON Inspection

The Standard Promtail Approach: `pipeline_stages` Regex

Why Use A Hash Instead Of `[REDACTED]`