Introducing Phield: Monitoring How PII Actually Moves Through Your Systems

Your redaction pipeline is working. Names are masked, SSNs are stripped, credit card numbers never make it to the logs. The policy is correct and the tests pass. Now answer this: how would you know if 15x the usual volume of credit card numbers started flowing through that pipeline last Tuesday?

Most teams have no answer. Redaction tells you whether sensitive data was handled correctly on each request. It says nothing about how much PII flowed, or when that changed. If the volume of SSNs through one service triples overnight, nothing pages anyone. The redactor did its job on every document, so by its own measure everything is fine, even though something upstream clearly is not.

That blind spot is what Phield is for.

The gap between redacting and noticing

A redactor is a per-request function: text in, redacted text out. It is the wrong place to ask aggregate questions. It does not keep a running tally of how many credit card numbers it has seen this hour versus last week, and it should not. That is a separate job.

The questions that matter for privacy posture are aggregate and temporal:

• Did a new code path start dumping payment data into a service that never used to see it?
• Did a partner integration begin sending you far more health identifiers than your contract anticipated?
• Did a misconfigured export quietly start moving names out of a system at ten times the normal rate?

None of these are redaction failures. They are changes in how PII moves, and you only catch them if something is watching the counts over time and knows what normal looks like.

What Phield does

Phield receives PII type counts, builds a baseline from the history, and alerts when a new sample deviates significantly from the established trend.

The unit of input is a count, not a document. You tell Phield “this source, in this context, saw 25 credit card numbers, 110 email addresses, and 4 SSNs in this interval.” Phield does not see the underlying text. It never needs to. It tracks the shape of your PII flow, per source, per context, per entity type, and watches for the shape to change.

Counts are tracked independently along three dimensions: source_id, organization, and context. A spike in credit-card counts in your billing context is never averaged together with counts from a logging context, even if they come from the same source. Each combination gets its own baseline, so a drift in one pipeline does not get diluted by the steady behavior of another.

Drift detection, not static thresholds

The naive version of this is a static threshold: page someone whenever credit card counts exceed 200 in an hour. It sounds reasonable and it fails immediately in practice.

Static thresholds do not know your traffic. Set the number low and you drown the on-call team in alerts every time a normal busy afternoon nudges the count up. Set it high and you sleep through the spike that actually mattered, because the threshold was tuned for peak traffic and the breach happened on a quiet Sunday. Either way the threshold is a guess that is wrong most of the day, and it has to be re-guessed by hand every time traffic patterns shift.

Phield learns the baseline instead. It offers two detection methods:

• Percentage delta. Phield keeps a moving average of recent counts for each source and entity type, and fires when a new count exceeds that average by a configurable percentage. Good for stable, predictable flows.
• Adaptive z-score. Phield tracks the moving mean and the moving standard deviation using Welford’s algorithm, then alerts only when a new count is enough standard deviations above the mean to be statistically significant. This method learns how volatile each flow normally is, so a noisy source needs a genuinely large jump to alert while a steady source trips on a smaller one.

Because the baseline is learned per flow, the same deployment can be sensitive where it should be and forgiving where it should be, without a human hand-tuning a number for every entity type. Phield also applies an alert cooldown so a sustained breach does not turn into a notification storm, and it resets automatically with a “back to normal” signal once the flow settles.

If you want to fine-tune before trusting it in production, the /replay endpoint re-runs detection over your historical data with a different threshold or sensitivity, so you can see how many alerts a setting would have produced before you commit to it. No live notifications are sent during a replay.

Flexible ingestion

Send counts over the HTTP API or publish them to a Kafka topic. The payload shape is identical either way: a timestamped map of entity types to counts, tagged with a source, an organization, and a context.

Here is a count going in over HTTP:

curl -X POST http://localhost:8080/ingest \
  -H "Content-Type: application/json" \
  -d '{
        "timestamp":    "2026-09-08T18:00:00Z",
        "source_id":    "patient-records-api",
        "organization": "acme-health",
        "context":      "production",
        "pii_types": {
          "credit-card": 25,
          "email":       110,
          "ssn":         4,
          "name":        60
        }
      }'

Only source_id and pii_types are required. timestamp defaults to the current time, and organization and context default to default. Publish that same JSON object to the configured Kafka topic and Phield ingests it the same way, which makes it easy to drop a producer next to an existing stream rather than adding a synchronous HTTP call to a hot path.

A natural place to emit these counts is right alongside redaction. Philter processes text and returns the detected and redacted entities, so the number of each entity type per batch is already in hand. You can report counts before redaction, after redaction, or both, and let the same Phield instance compare the two vantage points of one pipeline.

What an alert looks like

When a new count breaches the trend, Phield emits a structured alert. Every breach is written to standard output as a structured log line, suitable for shipping into whatever log system you already run, and the same event is delivered to your notification channels.

Here is a pii_trend_deviation for a roughly 15x spike in credit card numbers, with the fields an on-call engineer needs to triage it:

{
  "alert":        "pii_trend_deviation",
  "source_id":    "patient-records-api",
  "organization": "acme-health",
  "context":      "production",
  "entity_type":  "credit-card",
  "count":        487,
  "baseline":     32,
  "deviation":    "15.2x",
  "timestamp":    "2026-09-09T18:14:22Z"
}

The signal is the whole point: this is not “you crossed 200,” it is “this source normally sees about 32 credit card counts in this context and just reported 487, which is 15 times its own baseline.” That is actionable on its own, before anyone opens a dashboard.

The corresponding structured log line is compact and greppable:

2026/09/09 18:14:22 [TREND BREACH] Source: patient-records-api, Organization: acme-health, Context: production, PII Type: credit-card, Current: 487, Avg: 32.00, Increase: 1421.88%

Alerting through PagerDuty and Slack

Two notification channels are built in:

• PagerDuty. Set a routing key and a severity, and Phield sends breaches through the Events API v2 so they land in your existing on-call rotation and escalation policy.
• Slack. Point Phield at an incoming webhook URL and breaches post to the channel you choose.

You can enable either, both, or neither. With neither configured, the structured logs are still written, so the signal is never lost even in a minimal deployment. There is also a /mute endpoint to silence a noisy context for a fixed number of minutes while you investigate, scoped to a specific organization and context so muting one pipeline does not blind you to the rest.

Self-hosted, with no hard dependencies

Phield runs entirely inside your perimeter. There is no SaaS dashboard and no external data shipping. The counts you feed it are telemetry about your PII, and that telemetry stays where you put it.

For durable, queryable history it stores samples in a MongoDB time-series collection. When MongoDB is not available it falls back to ephemeral in-memory storage, so you can start a single binary and begin sending counts with no external services to stand up first. It also ships with a built-in web dashboard for visualizing flows, baselines, and the alert timeline, so you can see what is happening without wiring up Grafana or Splunk.

Get started

Phield is open source under the Apache 2.0 license and part of the same toolkit as Philter (redaction) and Phinder (discovery).

• Repository: github.com/philterd/phield
• Documentation: philterd.github.io/phield

The fastest way to see it work is the included simulate_data.sh script. Start the phield binary in one terminal, run the simulator in another, and watch it establish a baseline and then trip a trend breach when the simulated counts spike. The canonical ingest contract, the full configuration reference, and the notification setup all live in the docs.

Redaction handles each document. Phield watches the river. If you already run a redaction pipeline and could not currently answer how you would notice a 15x change in what flows through it, that is the gap to close.