Zero-Trust Perimeter Privacy: Enterprise Data Scrubbing Before Model Ingress

An efficiency layer that observes a customer's GPU fleet has to answer one question before any telemetry leaves the perimeter: what identifying data is collected, and where does it go. ACE's answer is that raw identifiers never leave the customer VPC. The external Core Brain makes every tiering, guarding and chargeback decision on pseudonymized tokens computed at the perimeter, under a salt the cloud side never holds.

Prior art

Privacy-preserving telemetry is a mature research area, and the distinctions it draws are precise.

• Differential privacy (Dwork & Roth, The Algorithmic Foundations of Differential Privacy, 2014 [1]) provides a provable bound on what an aggregate release leaks about any one contributor, by injecting calibrated noise. It applies when the output is a population statistic.
• DP has been applied to telemetry directly. Google's RAPPOR (Erlingsson, Pihur & Korolova, CCS 2014 [2]) collects client statistics under local differential privacy via randomized response, and Prochlo (Bittau et al., SOSP 2017 [3]) generalized this into the Encode–Shuffle–Analyze architecture: encode to minimize, shuffle to break linkability, analyze on the anonymized batch.
• GDPR Article 5(1)(c) [4] requires data to be "adequate, relevant and limited to what is necessary" — the data-minimization principle. Related work addresses operationalizing purpose limitation and minimization in data-driven systems [5].

One distinction governs the rest of this post: a salted one-way hash is not anonymization. The joint EDPS/AEPD guidance on hashing as a pseudonymization technique [6] states that if anyone retains the salt or a lookup table, the output is pseudonymized data — still personal data, still in scope. Anonymization is a higher and frequently unachievable bar.

Where ACE sits

ACE does not release private aggregates, so DP's noise-injection model does not apply: it forwards per-node mathematical fault and utilization signals (XID codes, ECC counts, temperature, power, SM/memory utilization), not user-level counts to be summed. Its levers are minimization and perimeter-local pseudonymization. Every policy input the external brain needs — which tier an owner is in, whether it is SLA-protected, what a node's fault history implies — is computed against a salted-masked token generated inside the customer VPC, with the salt and the reverse map held locally. The cloud never receives the real name or the key to recover it, and the loop can still tier, guard, charge back, and un-mask locally to actuate.

Two things leave the perimeter

Every telemetry sample passes a boundary filter. Sensitive fields are dropped; the node identifier is masked rather than dropped, so cross-sample correlation survives; the remainder is non-sensitive mathematical signal that passes through untouched.

The drop list covers hostnames, IP and MAC addresses, model and job names, namespace and pod identifiers, user/owner/team/project/tenant labels, and cloud billing metadata. What remains is fault physics: fault codes, ECC counts, temperature, power draw, utilization fields. A GPU throwing a fault code at elevated temperature is a fact about silicon, not about a customer's product roadmap.

Free text is the leakiest surface, so every raw error string passes through a filter that redacts absolute paths, IP addresses, MAC addresses, and interconnect hardware identifiers wholesale. The filter is biased toward over-redaction, on the basis that a redacted mount point costs less than leaked topology in a stack trace.

The salt stays local

Node correlation is the one identifier that cannot be dropped: the brain has to know that the node throwing errors on Monday is the node that flapped on Sunday. The node identifier is replaced with a stable one-way token — a deterministic hash salted with a value generated and held only inside the customer perimeter. The external brain receives tokens it can group and correlate but cannot invert, because it never receives the salt.

A local reverse map, kept inside the perimeter, translates an inbound verdict — which references only the masked token — back to the real node for actuation. That reverse map is why this is pseudonymization and not anonymization: re-identification is a designed capability, and it lives entirely inside the perimeter. The guarantee is narrow: to anyone outside the boundary the tokens are unlinkable to topology, because both the salt and the map that could reverse them never leave.

Deciding tiers without learning identities

Reclaim and reliability logic need to be tier-aware — an SLA-protected tenant's capacity must not be proposed for reclaim, and a premium owner's faults may warrant faster isolation. That does not require the owner's identity.

A specific owner or project identity collapses to a generic tier through a mapping resolved at the perimeter, before egress. Every downstream policy decision runs on the tier label alone. The same applies to the utilization stream: identifying fields are hashed and categorized to a tier at the perimeter, while the utilization numbers pass through unmasked.

The system's privacy properties depend entirely on the perimeter's handling of three things: the salt, the reverse map, and the tier mapping. Kept local, the external brain works blind on identity while retaining the physics and the policy tier.

Blast radius

Minimization at the perimeter bounds what a compromise of the Core Brain would expose: a stream of salted tokens and GPU thermals, not a map of a customer's model portfolio.

The primitives are ordinary — SHA-256, a locally held salt, a drop list. The privacy-telemetry literature above suggests the difficulty was never the primitive but the decision, made up front, not to collect identity.

---

References

1. C. Dwork, A. Roth. The Algorithmic Foundations of Differential Privacy. Foundations and Trends in Theoretical Computer Science, 9(3–4):211–407, 2014. doi:10.1561/0400000042
2. Ú. Erlingsson, V. Pihur, A. Korolova. RAPPOR: Randomized Aggregatable Privacy-Preserving Ordinal Response. ACM CCS 2014. research.google
3. A. Bittau, Ú. Erlingsson, P. Maniatis, et al. Prochlo: Strong Privacy for Analytics in the Crowd. ACM SOSP 2017. arXiv:1710.00901
4. Regulation (EU) 2016/679 (GDPR), Article 5(1)(c) — Principles relating to processing of personal data (data minimisation). gdpr-info.eu
5. Reviving Purpose Limitation and Data Minimisation in Data-Driven Systems. 2021. arXiv:2101.06203
6. EDPS & AEPD. Introduction to the Hash Function as a Personal Data Pseudonymisation Technique. 2019. edps.europa.eu (PDF)

---

Sign up to ACE now