Testing FileWarden

Each file is removed within seconds, with its own comment naming the rule it broke. Note that .sql is not blocked by default - it is your pattern, not the extension list, that catches this one. The size ceiling applies in both block and allow mode.

Set the two rules in separate saves, as above, because the size check runs first and wins: a file that is both over the ceiling and matched by a pattern gets the size comment, never the pattern one. If you set both at once and test with one large, badly-named file, the quote above is the only one you will see.

The size field takes whole megabytes only - a fractional value is rounded down, and anything below 1 rounds to 0, which means no limit. So 1 MB is the smallest ceiling you can set, and no sample in the zip can reach it. Use any file over 1 MB you already have; it does not matter what is in it.

After the sweep runs, the file is removed and a comment names the kind of secret found - never the value itself. The audit log records that a match was found, also without the value.

This one switch covers both halves of the scan, and each half has its own size cap. Text files are scanned when their extension is on the scannable list (txt, log, env, ini, json, yaml, csv, md, sh, py, js, sql, pem, key and similar) and they are 256 KB or smaller. PDF, Word, Excel and PowerPoint files go to a separate text extractor with a larger ceiling of 10 MB. A file over its cap is skipped by design, to keep the cost bounded. Every sample in the zip is plain text, so if you want to exercise the document half you need a document of your own.

Two limits worth knowing before you judge a negative result. A scanned or image-only PDF has no extractable text, so FileWarden treats it as unscannable and leaves it alone - no comment, no audit row. That is deliberate: this is a lite DLP layer, and we would rather miss a picture of a secret than delete a clean file. And the renamed-file signature check is not part of this switch - Detect renamed files (signature check) is its own Pro toggle in the same Content security section, off by default, and enabling the content scan does not enable it. If you want to test it, turn it on yourself, rename an executable to .pdf, upload it and wait for the same hourly sweep.

While monitor mode is on, FileWarden does not delete and does not comment - it only logs, so an admin can watch what a policy would have done before arming it. With a grace period set, the file is not removed on upload: it is flagged with a warning comment naming the deadline, and a later sweep removes it once the window has elapsed - unless the policy changed in the meantime, in which case the file is spared. The grace period applies in enforcement mode only; monitor mode already deletes nothing.

A monitor-mode flag defers a file, it does not settle it. FileWarden keeps the flagged file on its list rather than writing it off, so enforcement can finish the job later. So once you turn monitor mode back off in step 5, that same .exe from step 2 is back in scope - but what happens to it is not an instant delete. Because step 5 also sets a 1-hour grace period, the next time FileWarden reprocesses that file it posts the grace warning comment and schedules removal for a later sweep, exactly as it does for the step-6 file - grace is checked before any deletion. And it is reprocessed whenever its issue is next touched: attach the step-6 .exe to the same issue and the step-2 file gets its grace comment within seconds too; leave the issue untouched and, once it drops out of the sweep's look-back window, it may not be reached at all. The one thing you must not do is treat the flagged file as safe evidence that monitor mode leaves files alone - enforcement will act on it. If you want to keep it, delete it yourself in step 4 or move it to a fresh issue.

Because removal is done by a sweep, a 1-hour grace period means the file disappears at the first sweep after the hour is up, not on the exact minute. Set the grace period back to 0 before continuing.

The attachment is removed from the page and a footer comment explains why. The .exe was caught because exe is on the default executable blocklist that seeds every install - not because of anything you set in Jira.

Confluence is a separate Forge installation with its own storage, and it has no admin page anywhere - not in Confluence, not in Jira. It was seeded on install with the default policy (block exe, bat, cmd, com, msi, scr, vbs, js, jar, dll, ps1) and it stays on that default, because there is no surface to change it. Nothing you configure in Jira reaches it: the custom filename pattern from Test 2, any MIME, size or extension rule you add, the content scan, the PDF/Office scan, the renamed-file signature check, the grace period, quarantine and per-group exemptions - none of them apply on Confluence. Enforcement and monitor mode are Jira settings too and do not carry over; the Confluence install enforces its seeded default and cannot be put in monitor mode.

So two things you must not expect here. Do not upload 03-leaked-aws-key.env to a page and wait for the content scan - the Confluence install has no content scan and nothing will ever happen to it. And do not upload 02-customer-db-dump.sql expecting your Test 2 pattern to catch it - that pattern lives only in the Jira install, so the file stays on the page. The only files the Confluence install removes are the ones on its default executable blocklist. A Confluence-native admin page is a planned fast-follow, not something you are testing today.

The deleted file is in the space's Trash, restorable by a space admin. Confluence's delete API trashes rather than destroys, which is the safer of the two behaviours and the reason this test is worth running on its own.