AI
Why Insider Threat Defies Traditional Detection
Google processes over 10 billion events per year to catch insider threats across Alphabet’s 180,000 employees. Three categories are in scope: intentional abuse (a rogue employee exfiltrating trade secrets), unwilling insiders (employees compromised by malware), and accidental insiders (data shared outside an NDA).
Detection is hard because there is no exploit signature and no forbidden pattern. An ad sales employee accessing TPU schematics is suspicious. A hardware designer doing the same is routine. Detection is entirely about whether this user has a business reason to touch that resource.
FACADE’s Contrastive Learning Core
FACADE produces a single anomaly score per user-resource access (0 is normal, 1 is suspicious), then ranks all events. Analysts review only the top fraction. In red team tests across tens of millions of events, attackers landed in the top 0.01% most suspicious.
The training trick: insider incidents are too rare for a balanced dataset, so FACADE uses none. It computes embeddings for normal pairs, then swaps them: a hardware-division user with a DeepMind document, a DeepMind user with TPU schematics. That swap creates an arbitrarily large anomaly dataset from purely normal activity.
Featurizing Users and Resources Without Content Inspection
FACADE represents every resource (documents, spreadsheets, RPC endpoints, SQL tables) as a bag of the user IDs who previously accessed it. No content is read. New resources onboard as their first accesses accumulate, so the model never needs retraining for new items. The reference implementation resource event schema (17:33) takes only four fields: timestamp, principal, resource type, and resource ID.
Users work the same way. Team assignments and project memberships each expand into the bag of co-members’ user IDs. The reference implementation user attribute schema (22:22) needs only attribute name, value, principal, and validity timestamp. FACADE handles the rest.
Aggregating Anomaly Scores Across a Full Day of Activity
Per-access scores alone are not enough. A day of activity spans dozens of accesses, and naive aggregation fails: averaging lets an attacker dilute suspicious accesses with many low-scoring ones; summing penalizes active users; taking the maximum ignores all but one event.
FACADE uses a two-step approach. First, it clusters the day’s accesses by embedding similarity. Second, it takes the maximum score within each cluster, then sums those cluster-maxima. Clustering removes redundant anomalies. The per-cluster maximum prevents dilution by repeated similar accesses. Summing across clusters rewards breadth of suspicious behavior, not volume.
Red Team Evaluation and Open-Source Release
Google ran a 15-person internal red team across three scenarios: accessing YouTube financial data and ranking algorithms, obtaining next-Pixel design documents and schematics, and exfiltrating unpublished AI papers and model weights. Participants were software engineers familiar with internal systems and chose their own approach within each playbook.
With a daily triage budget of 10 users out of 180,000 employees, FACADE caught 4 of 15 attackers. Precision is the design goal, not recall. The reference implementation is on GitHub, but Google is explicit: FACADE needs large-scale data and per-environment featurization work before it generalizes elsewhere.
Notable Quotes
the answer is we actually do not use at all Ellie Bernstein · ▶ 10:58
team as a 0.01% 1% most suspicious event Ellie Bernstein · ▶ 6:46
that’s the gist of how facad works Ellie Bernstein · ▶ 10:10
Key Takeaways
- FACADE trains entirely on normal activity by swapping embeddings to synthesize anomalous pairs, requiring zero labeled insider incidents.
- Every resource and user is featurized as a bag of user IDs, making the system drift-resistant without content inspection or per-type engineering.
- At a 10-user daily triage budget against 180,000 employees, FACADE caught 4 of 15 red-teamers with very low false-positive rate.