Most insider threat thinking assumes one bad actor. One person, one set of credentials, one set of accesses to review. Pull their permissions, check what they touched, and you have a story you can tell.
Collusion breaks that assumption. Two people, each acting cleanly inside the access you granted them, can combine into a breach that no single-identity review would ever flag. Neither one looks wrong. The breach lives in the seam between them.
Why each role passes its own audit
Access controls are designed around one identity at a time. A reviewer asks: does this person need this access to do their job? If the answer is yes, the access is correct, and the question is closed.
Picture two people. A data engineer has read access to a production datastore because pipelines break and someone has to debug them. A business analyst has the right to pull aggregate reports and export them to a shared drive because that is the entire point of the role. Both accesses are defensible. Both would survive a quarterly entitlement review without a comment.
Now run them in sequence. The engineer stages raw records into a working location that the analyst can reach. The analyst exports from that location to an external share, framed as a routine report. The high-value data has left the building, and it did so across two clean accounts, neither of which did anything its role does not permit.
Single-identity review cannot see this, because the dangerous unit is not a person. It is the path the data took across two people.
The pattern is the breach
This is the same blind spot that every permitted move shares, sharpened. Each tool you own evaluates whether an action was allowed, and each action here was allowed, so each tool waves it through. A role review checks entitlements one identity at a time, and each entitlement is justified. A data loss tool checks whether a given transfer matches a rule, and these transfers match approved patterns.
Every move is permitted. The pattern across the moves is the breach.
Collusion is what happens when an attacker, or two motivated employees, deliberately splits a breach into legitimate-looking halves so that no single review surface ever holds the whole thing. The defense cannot be a better one-identity audit. The defense has to be a vantage point that sees the move itself, across whatever identities touched it.
Where the pattern actually shows up
The only place to see the full path is at runtime, while the data moves, not in an entitlement spreadsheet before and not in a disclosure letter after.
Hilt watches data movement at the kernel, metadata only by default, off the path. It does not read your data to do this, and it does not need to. Each move is resolved to a probabilistic, source-dependent identity: which user, which job, which destination, and whether this move fits what that identity normally does.
That resolution is what makes collusion legible. The engineer's stage-out is scored against how the engineer's data normally moves, and a bulk read of high-value paths into a location that role rarely writes to is unusual for that identity, even though it is permitted. The analyst's export is scored against how the analyst's data normally moves, and an export sourced from data that role does not usually originate is unusual for that identity, even though it is permitted. Two anomalies, each modest on its own.
Then the moves connect. The data that the analyst exported is the same data the engineer staged, moved through a shared location in a short window. The system is not reasoning about two job descriptions. It is following one body of data as it crosses from one identity to another and out. That crossing is the signal a single-identity review structurally cannot produce, because it never looks at more than one identity at once.
Any one of these signals, alone, is noise. Together they are a pattern, and a pattern is a case, not an alert.
A case written across both identities
When the path forms, Hilt writes the case. The narrative names both identities, the data that moved between them, the timing that ties the two moves into one transfer, and why the combined movement deviates from how that data normally travels. It reads as one story about one breach, not two unrelated low-priority flags in two different queues that no analyst would ever think to join.
That difference matters operationally. The reason collusion works is that it scatters its evidence. The engineer's anomaly lands in one place, the analyst's in another, and the team is left correlating by hand if they correlate at all. Resolving the move to identity and following the data across identities does the joining at the layer where the data actually moved, so the correlation is in the case, not in an analyst's spare time.
If the pattern warrants it, the response is host-level network isolation (quarantine) from the control plane. The collector never sits inline and never blocks, drops, or alters traffic. It observes the move and, when a case crosses the line, isolates the host at the network so the transfer cannot complete from there. Events never leave your account; the whole path from kernel event to written case runs single-tenant inside your own cloud.
This is not a replacement for access governance
Identity and access management still does the work it was built for. Least-privilege provisioning, entitlement reviews, and access certification are how you keep the granted surface small in the first place, and a smaller surface is a real defense. Hilt does not replace any of it, and a clean access program makes the anomalies sharper, because the smaller and more deliberate the granted access, the more a collusive path stands out against it.
The point is narrower. Access governance answers whether each person should have each access. It does not, and structurally cannot, answer whether the data is moving in a pattern that only makes sense as a breach once you look across two people. That second question is a runtime question about movement, and it is the one collusion is built to dodge.
The bottom line
Collusion is not an exotic threat. It is the ordinary insider problem with the evidence deliberately split so that no single review surface holds it. Two permitted roles, two clean audits, one breach in the seam.
The seam is only visible at runtime, on the data movement itself, resolved to the identities behind each move and followed across them. If your current stack can tell you that each of two people did only what their role permits, but cannot tell you that the same high-value data passed from one to the other and out the door inside a single window, that seam is your gap.
If you want to see how the kernel-to-case path follows data across identities in your own environment, the next step is a 30-minute call, engineer to engineer, walking through exactly where the collector sits and what it would surface.