How it works

What happens to one attachment, from upload to verified swap.

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

Support teams ask the people who file requests for HAR captures, logs and config dumps. These files often hold session cookies, API keys, passwords and personal data. Once attached to a request, every agent can see them, and so can search.

One attachment, step by step

1. A platform event starts a small function: an issue update or a comment. A new attachment triggers an issue update about 2 seconds later. The function lists the issue's attachments and puts new files on a Forge queue. confirmed on a test site
2. A queue worker downloads the file into function memory through the REST API, inside Atlassian's runtime. confirmed on a test site
3. The text is scanned and each secret is replaced by a token in memory. The file is never written anywhere else. HAR files are read by structure (headers, cookies, query strings, bodies), JSON by key names, and text by patterns, including high-entropy strings next to words like token or secret.
4. The app uploads the sanitized copy, sanitized_<original name>, and repoints the links in comments and the description to it. confirmed on a test site
5. The app checks that nothing still points at the original, writes the audit row, then deletes the original. confirmed on a test site

Dry-run is on by default. With dry-run on, the app does steps 1 to 3, writes an audit row, and changes nothing.

File content and matched values are never written to storage or logs. Only counts, rule ids and ids are.

Redaction labels

A label looks like [REDACTED_BY_SECRET_SCRUBBER_3f9a]. The four hex characters are the first 16 bits of an HMAC of the matched value, keyed with a random secret that is unique to your install. Two equal values get the same label, so an engineer can see that two labels match. A label is not an identifier: unrelated values can occasionally share one.

What the swap covers

• A customer's upload through the portal is stored as a comment. The app edits that comment, so agents see "(edited)". The portal view shows no label. confirmed on a test site
• An internal comment was swapped and stayed internal. confirmed on a test site
• A file attached directly to an issue (uploaded through the REST API) and a file inline in the description were swapped. confirmed on a test site
• An inline image (a PNG) is left alone: no copy, no audit row. confirmed on a test site
• If the app cannot match an inline reference to the new file, it replaces the preview with a text note that points to the sanitized_ file.

If something fails

Any failure before the delete leaves the original untouched. The job retries with backoff. A failure that cannot be recovered is audited and shown in the issue panel. See Security and data handling for the design.

Where it runs

Everything runs inside Atlassian Forge, on your site. The vendor runs no server that receives your files.