> For the complete documentation index, see [llms.txt](https://help.nightfall.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.nightfall.ai/data-exfiltration-prevention/exfiltration_endpoint/policies/recommended-human-exfil-policies.md). # Recommended Human Exfil Policies Start here. These twelve policies cover every channel a person can use to move data off a managed laptop, and they scope by **where the data goes**. Once they are in place, add the data-specific policies on [Recommended Policy Configurations](/data-exfiltration-prevention/exfiltration_endpoint/policies/recommended-policy-configurations.md) and the agent policies on AI agent and Inference Hooks policies. Most organizations do not turn on all twelve at once. Treat the set as a checklist. It shows what is covered and what is not, so a gap is a decision rather than a surprise. ### The twelve policies #### Destination-scoped: policies 1 to 7 These seven scope by destination, so each one needs a domain collection. | # | Policy | Trigger and destination | Target action | | - | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | | 1 | Browser upload to unsanctioned apps and AI | Browser uploads to **GenAI**, **Agent builders**, and **Data connectors**, excluding your **Sanctioned Apps** collection | Block | | 2 | Browser upload to personal accounts | Browser uploads to **Nightfall supported session check domains**, with **Personal accounts only** on | Block | | 3 | Browser upload to high-risk destinations | Browser uploads to **Anonymous file upload**, **VPN and proxy services**, **Peer-to-peer file sharing**, **Personal email**, **File sharing services**, **Social media**, **Messaging apps**, **Forums and online communities**, and **Personal blogs and sites** | Block | | 4 | Paste to unsanctioned apps and AI | Paste to the same destinations as policy 1 | Block | | 5 | Paste to personal accounts | Paste to the same destinations as policy 2 | Block | | 6 | Paste to high-risk destinations | Paste to the same destinations as policy 3 | Block | | 7 | Git push to unapproved repositories | Git push to destinations not in your **Approved Git Destinations** collection | Alert. Push completes | The starter collections and the policies they back: | Collection | Domains | Backs policies | | --------------------------------------------- | ------- | -------------- | | **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 | | **Nightfall supported session check domains** | 36 | 2, 5 | | **Personal blogs and sites** | 32 | 3, 6 | | **Peer-to-peer file sharing** | 31 | 3, 6 | | **Anonymous file upload** | 26 | 3, 6 | | **GenAI** | 23 | 1, 4 | | **Agent builders** | 22 | 1, 4 | | **Data connectors** | 16 | 1, 4 | Three collections you build yourself, because only you know what your business sanctions: **Sanctioned Apps** (your own systems, SaaS tools, and partner domains), **Approved Git Destinations** (for example `github.com/your-org/*`), and **Corporate Domains** (your email domains, used by session detection). All starter collections are described on Starter Domain Collections. #### Not destination-scoped: policies 8 to 12 These five scope by account type, application, or device. They do not need a domain collection. | # | Policy | What it catches | Target action | | -- | ------------------ | --------------------------------------------------------------- | -------------------------------------------- | | 8 | Cloud sync | Files syncing to a personal Dropbox, OneDrive, iCloud, or Drive | Block | | 9 | Desktop app upload | Files uploaded by a desktop application | Block, with exceptions for approved apps | | 10 | Desktop app paste | Text pasted into a desktop application | Block, with exceptions for approved apps | | 11 | Removable media | Files copied to USB and external drives | Block, with exceptions for company drives | | 12 | Print | Documents sent to a printer | Block, with exceptions for approved printers | **Cloud sync does not use the Cloud storage collection.** Policy 8 keys off the sync client and the account signed into it, not the domain. The **Cloud storage** starter collection is for browser uploads to those services. **Coverage figures apply to policies 1 to 7 only.** A tenant at 40% collection coverage is 40% covered on seven of twelve channels, not 40% covered overall. ### Detection rules Use one standard set of detection rules on every policy except 7, so the twelve behave the same way: * **PII:** names with SSNs, driver's license numbers, dates of birth * **PCI:** credit card numbers, bank routing numbers, IBAN * **PHI:** patient records and health information * **Credentials and API keys:** secrets, tokens, passwords, private keys * **File classifiers:** financial, HR, legal, and M\&A documents Policy 7 has no detection rules. Git push monitoring checks where code goes, not what it contains. {% hint style="warning" %} A policy with content scanning off is not a disabled policy. It applies to every event in scope: **Block** stops every upload or paste to those destinations, and **Monitor** records every one. Turn content scanning on and add the detection rules above unless you intend that. {% endhint %} ### "Personal accounts" means a personal session Policies 2 and 5 are the most often misread. They do not mean personal email domains. They mean someone signed into an account they own rather than a corporate one, on a site the company also uses. A file going to the corporate Google Drive is routine. The same file going to that person's own Drive, from the same browser, is not. Only a session check can tell them apart, because the destination domain is identical. Two collections make this work: * **Corporate Domains.** Session detection decides whether an account is corporate by comparing its email domain to this collection. If the collection is missing, session detection is off. If it is empty, every account is treated as personal, and policies 2 and 5 fire on corporate accounts too. * **Nightfall supported session check domains.** Session detection only works on a fixed list of 36 domains across Google Workspace, Microsoft 365, Dropbox, Box, iCloud, and the major AI assistants. Scope policies 2 and 5 to this collection. A session check on an unsupported domain will save, will look correct, and will never fire. See [Session Detection](/data-exfiltration-prevention/exfiltration_endpoint/policies/trigger/session-detection-corporate-and-personal-account-filtering.md) for the full list of supported domains. ### Prerequisites A policy only protects what the agent can see: * **Browser extension coverage** governs policies 1 to 6. Below about 95% of reporting devices, those policies describe a fraction of your people. Check installed and connected separately. A device with the extension installed but not connected 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 event is attributed to a machine, and a prompt has nobody to prompt. * **Collections** govern policies 1 to 7: the starter collections above, plus your Sanctioned Apps, Approved Git Destinations, and Corporate Domains collections. Until Sanctioned Apps is complete, 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 and leave it there long enough to see what it catches. 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 they are the 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. In one evaluation, 2,125 of 2,231 desktop app events were a single application reading its own plugin manifests. Fix this with a path exclusion, not by switching the channel off. #### 2. Then notify the user Turn on end-user notifications so the person sees what happened at the moment they do it. Write the message in plain language: what was stopped, why, and who to contact. This corrects behavior instead of only recording it, and it needs device identity to be in place. #### 3. Then block Move a policy to Block once its scope is settled and its alert volume is readable. **Order matters.** Policies 3 and 6 are usually the first safe candidates, because anonymous file upload, VPN services, and paste sites rarely have a business reason. Policies 1 and 4 come last, because they depend on a complete Sanctioned Apps collection. Where a legitimate business need can exist, turn on override with justification. The person explains the transfer, and your team can approve an exception for that device. ### What "with exceptions" means Desktop app upload, desktop app paste, removable media, and print are legitimate by default and risky by context. The exception list is the sanctioned case, such as approved applications or company-issued drives, and the block applies to everything else. A policy that blocks with an empty exception list blocks normal work. Build the exception list first. **Git push works by exception too, but it alerts rather than blocks.** Engineers push code all day. What matters is pushing it to a repository the company does not own. Put your GitHub organizations and Git servers in Approved Git Destinations, and policy 7 records an event for every push outside them. Nightfall cannot stop a push, so pair policy 7 with [Recommendation 2](/data-exfiltration-prevention/exfiltration_endpoint/policies/recommended-policy-configurations.md), which blocks source code uploads through the browser and cloud sync. ### What these policies do not cover * **AI coding agents.** Prompts, MCP tool calls and responses, terminal commands, and file writes inside Claude Code, Cursor, and VS Code Copilot. See AI agent and Inference Hooks policies. * **Claude Enterprise on unmanaged devices.** Inference Hooks cover claude.ai, the desktop and mobile apps, and Cowork without the agent. See the same page. * **Code already in GitHub.** See [Recommended Policies for GitHub](https://help.nightfall.ai/sensitive-data-protection/github/policies/recommended-policies-for-github). ### Reading your own coverage Four questions to ask of any deployment: * **How many of the twelve are configured?** Count channels, not policies. A tenant with twenty-seven browser upload policies and nothing on paste is covered on one channel. * **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. Check its detection rules and excluded destinations first. * **Does any policy have content scanning off?** A destination-only policy fires on every movement to that destination regardless of content. Sometimes that is intended. Often it is why one policy accounts for most of the queue. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.nightfall.ai/data-exfiltration-prevention/exfiltration_endpoint/policies/recommended-human-exfil-policies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.