Skip to main content

Anonymization rules

Host ID remapping

A deterministic mapping is built at export time: hosts are sorted by first appearance and assigned sequential IDs. The mapping is stored in a separate host_map.json that stays on the deployment’s S3 bucket (never exported to Hilt) so they can correlate back if needed.

Temporal jitter

The entire dataset is shifted by a uniform random offset between 0 and 48 hours. This prevents Hilt from correlating export timestamps with known customer events (outages, incidents, press releases). The offset is recorded in the export manifest for the customer’s records.

UID remapping

Unix UIDs are remapped to sequential integers per host. UID 0 (root) is preserved as 0 since it carries security semantics relevant to the model.

Column pruning

The export query selects only allowlisted columns. No SELECT *. Specifically:
  • token_evidence_json is never selected from dag_epoch_tokens
  • evidence, reason, drivers, owner, identity are never selected from dag_anomaly_scores
  • host_id is selected but remapped before writing to Parquet

Dead epoch filtering

Rows where exec_count + file_open_count + net_flow_count == 0 are dropped.

Minimum host threshold

Exports with fewer than 5 distinct hosts are rejected. This prevents exports from highly specialized single-host environments where the feature distribution alone could identify the workload.

Running an export

The export pipeline is provisioned as part of every deployment and runs on a daily schedule. You can also trigger a one-shot Kubernetes Job on the existing EKS cluster, using the same ClickHouse credentials as the enrichment service.
1

Trigger the export job

2

Monitor progress

3

Review the manifest and sample

Written to the S3 bucket.
4

Approve the export

Only required if data_export_require_approval=true. The job polls for this ConfigMap and proceeds once found.
5

Verify the final archive

Export manifest (manifest.json)

zero_filled_columns lists feature slots that have no backing column on this deployment and were exported as zeros (entries look like numeric_features[<i>]:<feature_name>) — it is distinct from excluded_columns_note, which names identity columns deliberately withheld. zscore_names gives the canonical order of the packed zscores vector.

Customer controls

Review before transfer

When data_export_require_approval = true (default), the export produces a manifest and a 20-row sample Parquet file. The full archive is encrypted and staged but not transferred until the customer creates the approval ConfigMap. The user can:
  • Inspect the manifest to see exactly which columns are included.
  • Load the sample Parquet to verify anonymization.
  • Reject by deleting the staged files from their S3 bucket.

Date range control

The user controls how much history to export via data_export_date_range_days. They can also run exports for specific windows by overriding the Job’s DATE_START and DATE_END environment variables.

Deletion

The user can delete exported data from their S3 bucket at any time.

Audit trail

Every export creates a Kubernetes Event and (if a webhook is configured) a notification with the export ID, row count, date range, and approval status. The host_map.json stays exclusively in the customer’s bucket.

What Hilt sees

No filenames, IP addresses, hostnames, usernames, cloud resource IDs, detection rule names or match descriptions. Just behavioral feature vectors and abstracted security token sequences.
Last modified on October 8, 2026