Limits
What the scanner finds, what it misses, and what to expect.
Evidence. Unless tagged, statements on this page are covered by automated tests, not confirmed on a live site. Exceptions: confirmed on a test site in testing
Detection is pattern-based. It will miss some secrets and redact some harmless values. Review dry-run results before going live.
Supported files
| Item | Detail |
|---|---|
| Default types | .har, .json, .log, .txt, .env |
| Optional types | .csv, .yaml, .yml, .xml, .conf, .ini |
| Binary files | Skipped and logged. A .log file with a NUL byte was skipped and left untouched. confirmed on a test site |
| Size limit | Default 25 MB, adjustable from 1 to 100 MB. Larger files are logged as skipped and not scanned. Review them by hand. A 27 MB file was skipped as too large and left untouched. confirmed on a test site |
| HAR files | Parsed by structure: headers, cookies, query strings, bodies |
| JSON files | Handled by key names and name/value pairs |
| Text and logs | Handled by patterns |
| Seen live | .har (including a real Chrome HAR) and .log. The other types are covered by automated tests only. confirmed on a test site |
Detected and not detected
Detected
- Cookies and session values
- Bearer tokens and JWTs
- API and cloud keys
- Passwords in URLs and key-value pairs
- Private keys
- Card numbers, checked with the Luhn test
- US social security numbers and IBANs
- Email addresses (configurable)
- Phone numbers (optional)
- High-entropy strings next to words like token or secret
Not detected
- A secret with no recognizable shape and no key name nearby. A bare refresh token or cloud secret key in prose is not redacted. The same value is caught when a key name stands in front of it.
- Secrets inside images, PDFs, archives or other binary files.
- Free text inside HTML response bodies. In a real Chrome HAR from a login page, the login form's password field and the session cookies were redacted. A demo password written in the page's HTML help text, inside a response body, was not. Review such files by hand. confirmed on a test site
- Multipart form bodies inside HAR files get only the generic text scrubber.
False positives and false negatives
Some harmless values will be redacted, and some secrets will be missed. A small set of synthetic test fixtures and benign files produced no redactions on the benign files. That set is small and does not predict other files. No accuracy figure is published, because none has been measured on real customer files.
To reduce false positives, turn off entropy detection or add allowlist entries.
Known limitations
| Limitation | What happens |
|---|---|
| Exposure window confirmed on a test site | The original is visible until the swap finishes: typically seconds, longer for large files or a slow site. Small files took 5.6 to 6.7 seconds on a development site. No maximum is promised. Large files and the time until search can find the original were not measured. See Security. |
| Permanent deletion confirmed on a test site | The original is deleted after a verified swap. There is no undo. |
| Edited comments confirmed on a test site | A customer's portal upload is a public comment. The app edits it, so agents see "(edited)". |
| Unmatched references | If the app cannot match an inline reference to the new file, it replaces the preview with a text note. |
| JSON rewrite | A JSON file with findings is rewritten. Integer-like object keys can change order, and numbers above 2^53 lose precision. Files with no findings are returned unchanged. |
| Duplicate copies | A retried failed swap can leave a second sanitized_ copy. |
| Label collisions | Unrelated values can occasionally get the same label. |
| Closed issues | Files in closed issues are not processed. The Leak audit is read-only. |
| Existing attachments | They are not processed automatically when dry-run is switched off. The admin action "Sanitize flagged files now" processes the ones that dry-run flagged. See Settings. confirmed on a test site |
| Inactive license confirmed on a test site | With an inactive license nothing is processed. Files uploaded meanwhile are left untouched. |
| File names | Audit file names are stored as-is unless hashing is switched on. |
| Tested paths | Confirmed on a test site: portal upload, internal comment, a file attached through the REST API, a file inline in the description, an inline PNG left alone. Covered by automated tests only: several references to one file, and the attach button in the agent view was not used. See Verified status. |