Recommended Human Exfil Policies
Nightfall's core Human Exfil policy set is twelve policies covering every channel a person can move data off an endpoint. This page describes what each one is for, what it should eventually enforce, and the order to build them in.
Most organizations do not start with all twelve. The set exists so you can see what is covered and what is not, rather than discovering a gap after something has moved through it.
The twelve policies
Collection-scoped — policies 1 to 7
These seven scope by where the data went. Each needs a domain collection to point at, which is why they are listed together.
1
Browser upload — unsanctioned apps and AI
Block
GenAI, Agent builders, Data connectors — plus your own sanctioned collection
2
Browser upload — personal domains
Block
Session check domains
3
Browser upload — high-risk domains
Block
Anonymous file upload, VPN and proxy, Peer-to-peer, Personal email, File sharing, Social media, Messaging apps, Forums, Personal blogs
4
Paste — unsanctioned apps and AI
Block
GenAI, Agent builders, Data connectors — plus your own sanctioned collection
5
Paste — personal domains
Block
Session check domains
6
Paste — high-risk domains
Block
Same nine as policy 3
7
Git push
Block + Exception
Code repositories — plus your own approved-repository collection
Four collections back more than one policy, so loading them is not nine separate decisions:
Personal email
95
3, 6
File sharing services
51
3, 6
Forums and online communities
49
3, 6
Social media
48
3, 6
Messaging apps
41
3, 6
VPN and proxy services
41
3, 6
Personal blogs and sites
32
3, 6
Peer-to-peer file sharing
31
3, 6
Code repositories
30
7
Anonymous file upload
26
3, 6
GenAI
23
1, 4
Session check domains
23
2, 5
Agent builders
22
1, 4
Data connectors
16
1, 4
Not collection-scoped — policies 8 to 12
These five scope by account type, application, or device. A domain collection does not apply to them.
None of these needs a starter collection. They scope by account type, application or device instead.
8
Cloud sync
Block
Files syncing to a personal Dropbox, OneDrive, iCloud or Drive
9
Desktop app upload
Block / Block + Exception
Files uploaded by a desktop application
10
Desktop app paste
Block / Block + Exception
Text pasted into a desktop application
11
USB
Block / Block + Exception
Files copied to removable media
12
Block / Block + Exception
Documents sent to a printer
Cloud storage is the exception worth noting. The Cloud storage collection exists and overlaps with policy 8's territory, but policy 8 keys off the sync client and the account it is signed into, not the domain. Load the collection for browser-based uploads to those services; it will not make policy 8 work.
The split matters when you read a coverage figure. Collection coverage governs policies 1 to 7 and none of 8 to 12. A tenant at 40% coverage is not 40% covered overall — they are 40% covered on seven of twelve channels.
"Personal domains" means a personal session
Policies 2 and 5 are the most commonly misread in the set. They do not mean personal-email domains. They mean someone signed into an account they own rather than a corporate one.
A file going to a corporate Google Drive is routine. The same file going to that person's own Drive, from the same browser, on the same device, is not. Only a session check can tell them apart — a destination collection cannot, because the destination is identical.
Session detection works on a fixed list of domains. Google Workspace, Microsoft 365, Dropbox, Box, iCloud and the major AI services. Load the Nightfall supported session check domains collection before building policies 2 or 5, and scope them to it. A session-check policy pointed at an unsupported domain will be created, will look correct in the console, and will never fire.
Prerequisites
A policy only protects what the agent can see, so three things gate the set:
Browser extension coverage governs policies 1 to 6. Below about 95% of reporting devices, those policies describe a fraction of your people. Check installed-versus-connected separately — a device with the extension installed but not connected to the agent reports nothing, and that is a support case rather than a redeployment.
Device identity governs end-user prompts and per-person reporting. Without an MDM mapping, every finding attributes to a machine, and a prompt has nobody to prompt.
Starter collections govern policies 1 to 7. Each one is listed against its policies above, and all of them are described in Starter domain collections.
Your own sanctioned collection governs policies 1 and 4 specifically. Those work by exception — a destination is unsanctioned because it is not in a sanctioned collection. Until your own systems, SaaS tools and partner domains are collected, routine work generates alerts and a block cannot tell your staging environment from an unknown host.
Building the set
1. Start in monitor
Create each policy in monitor mode and leave it there long enough to see what it catches. The point is not caution for its own sake — it is that you cannot scope a policy correctly until you have seen its traffic.
Two patterns show up almost every time:
Local destinations. Uploads to localhost, 127.0.0.1 and private network addresses never leave the device. At some organizations these are the single largest source of events. Exclude them from scope rather than tuning around them.
Application config reads. AI desktop applications read their own configuration files constantly. One evaluation found 2,125 of 2,231 desktop-app events were a single application reading its own plugin manifests. The fix is a path exclusion, never switching the channel off.
2. Then prompt the user
End-user remediation asks the person who moved something whether they meant to, at the moment they do it. It needs no analyst, it corrects behavior rather than recording it, and it is the gentlest introduction to enforcement.
It also needs a person to prompt, so it depends on device identity being in place.
3. Then block
Move to the target action once the policy's scope is settled and the alert volume is readable.
Order matters here. Policies 3 and 6 — high-risk domains — are usually the first safe candidates, because anonymous file upload, VPN services and paste sites rarely have a business justification. Policies 1 and 4 come last, because blocking on unsanctioned destinations requires your sanctioned collections to be genuinely complete.
What "Block + Exception" means
Four policies carry a target of Block + Exception rather than Block outright: git push, desktop app upload, desktop app paste, and the device channels.
These cover activity that is legitimate by default and risky by context. Engineers push code all day; what matters is pushing it to a repository the company does not own. The exception list is the sanctioned case — your own GitHub organization, your approved applications — and the block applies to everything else.
A Block + Exception policy with an empty exception list blocks normal work. Build the exception first.
Reading your own coverage
Four questions worth asking of any deployment:
How many of the twelve are configured? Not how many policies exist — a tenant with twenty-seven browser upload policies and nothing on paste is covered on one channel, not twenty-seven.
How many enforce? A policy in monitor records an event and nothing else. If every policy is in monitor, the deployment has visibility and no protection.
What is the alert volume per policy? A policy producing hundreds of events a day is usually scoped too broadly rather than detecting something extraordinary. Check its content criteria and its excluded destinations before anything else.
Does any policy have no content criteria? A destination-only policy fires on every movement to that destination regardless of what is in the file. Sometimes that is intended. Often it is the reason one policy accounts for most of the queue.
Last updated
Was this helpful?