Prove your DLP blocks real leak paths

You send synthetic data over common egress paths and read the result. If the request reaches our server, the policy did not stop that send. If the connection drops, open your DLP console and find the matching event. On most web tests, you also see what we received on the page.

In monitor/detect mode, DLP records events (when the channel is covered). In block mode — if policies are set correctly — the transfer is cut off. Run the same payload under both settings and you immediately see whether detection works and whether enforcement works.

HTTPS (text form and file uploads via different methods), FTP, S3 PUT, email, and clipboard.

Use your own files or ready packs under Test data: the sample library, document images, and the sensitive-data generator.

No. Packs are built for testing only. Do not use them in applications or production systems — see the terms.

Yes. The site is vendor-neutral. Watch how your policy reacts to the path you choose — during setup, a pilot, or a bake-off.

The policy may be alert-only, the destination may be excluded, or the rule may target the wrong data type. Sometimes a proxy, CASB, or gateway drops the request — not DLP. Align timestamps with the console. If there is no server response and no DLP event, the detector likely never fired.

After a rule change, an agent or gateway update, and whenever users get a new way to move files. On a quiet estate, a short quarterly pass is usually enough: SSN, IBAN, cards, and the main egress paths.

Confirm from sensor counters that the right segment actually reaches the appliance. For a passive mirror, FTP is convenient: cleartext protocol, synthetic file content is easy to read on the sensor. A SPAN monitor usually detects only; it cannot prove block — for enforcement you need an inline path (proxy, agent, or gateway).

There is no cleartext HTTP web form on the site — the UI moved to HTTPS POST. If the sensor needs plain HTTP, send programmatically to http://no-ssl.dlpbench.com/api/http-post/ (service terms).

How much traffic a datacenter mirror actually sees keeps shrinking: TLS, remote work, cloud apps. That is an architecture limit, not a single misconfigured rule.

That is data at rest — discovery and classification — not egress intercept. Place known test files (library, sample documents) in every location in scope. Wait for a crawl or trigger one. Expectation: file found, class/label correct, response matches policy.

Common silence: path excluded; incremental index has not reached the file yet; cloud scanner lacks rights on the container. This site only supplies the files — the scanner is yours.

Pastes into ChatGPT, Copilot, Gemini, and similar apps are a common exfil path (GenAI / shadow AI). Lock the URL and app list in policy. From a test workstation, paste synthetic content from test data or via the clipboard page; if the service accepts files, upload one from the library. Verify both monitor and block — the user-facing message should explain the deny.

Outbound HTTPS calls from AI agents are a separate channel. The bench includes an MCP server for that: DLP sees ordinary HTTPS with synthetic fields in the request/response — not “MCP magic.” Not every product labels this as AI; some only catch it as web. Re-test after client or service-domain changes.

Many vendors cover fewer channels on Mac than on Windows. Before you trust block: confirm the agent has the required permissions (often via MDM); which browsers users actually run; and how AirDrop, iMessage, iCloud Drive, and removable drives behave.

Web, FTP, email, and clipboard on Mac can use the same bench pages: HTTPS POST, FTP, email, clipboard. Do not carry a Windows result to Mac without a separate run. Record gaps in your coverage map.