Can a Crash-Report Attachment Bypass Client-Side Prompt Redaction?

August 9, 2026

Redacting a crash event does not automatically scrub its logs, screenshots, or minidumps. Learn how to test the full telemetry envelope.

A crash-report attachment can bypass a client-side prompt-redaction rule when that rule cleans only the structured error event. Sentry lets JavaScript developers inspect hint.attachments in beforeSend, but the attachment must be handled explicitly. Logs, screenshots, view hierarchies, and stored minidumps are separate payloads. If they can contain AI prompts, each needs its own allowlist, sanitizer, test, retention rule, and access policy.

Watch The 30-Second Summary

Watch this video on YouTube

That is not a Sentry vulnerability. It is a telemetry-boundary mistake: proving that one object was redacted does not prove that every file traveling beside it was redacted.

What Is Confirmed

Sentry's current JavaScript attachment documentation says attachments live on the SDK scope and are sent with events. It also says developers can add, remove, or modify them through beforeSend or a global event processor by working with hint.attachments.

The same documentation draws an unusually important privacy boundary: Sentry does not apply data scrubbing to attachments. Its examples include log files and screenshots. Its native-crash documentation says minidumps may contain environment variables, local paths, or in-memory input values, including passwords.

Sentry's documented defaults reduce one risk but do not erase the boundary:

Sentry's Native SDK data inventory separately confirms that Crashpad and Breakpad collect each thread's stack in a minidump snapshot. That is a different artifact from the processed error event an engineer sees first.

What Is Still Unclear

No documentation can determine whether a particular application's attachment contains a prompt. That depends on the app, SDK, integrations, crash timing, enabled options, and custom code.

You still need to determine:

The absence of a prompt in the visible event JSON is not evidence that its sibling attachments are clean. The only strong evidence is an inventory plus a controlled capture test.

Why Event Redaction And Attachment Redaction Are Different

Think of a crash submission as an envelope, not a single JSON object.

The envelope may contain a structured event with an exception, stack trace, tags, breadcrumbs, and request context. It may also contain raw or semi-structured files. Sentry's SDK specification lists standard attachments, screenshots, view hierarchies, minidumps, Apple crash reports, and Unreal logs among the possible attachment types.

A redactor written like this has a narrow proof:

beforeSend(event) {
  event.extra = redactPromptFields(event.extra);
  event.breadcrumbs = redactBreadcrumbs(event.breadcrumbs);
  return event;
}

It may clean the event. It says nothing about debug.log, screenshot.png, or a minidump included in the same submission.

In JavaScript, an attachment-aware design must inspect the second hint argument too. This illustrative pattern denies unknown attachment types and sanitizes only text it knows how to parse:

beforeSend(event, hint) {
  event.extra = redactPromptFields(event.extra);
  event.breadcrumbs = redactBreadcrumbs(event.breadcrumbs);

  hint.attachments = (hint.attachments ?? []).flatMap((attachment) => {
    const isApprovedText =
      attachment.contentType === "text/plain" &&
      typeof attachment.data === "string";

    if (!isApprovedText) return [];

    return [{
      ...attachment,
      data: redactSensitiveText(attachment.data),
    }];
  });

  return event;
}

This is a pattern, not drop-in compliance code. A real implementation needs tests for encoding, truncation, binary files, SDK upgrades, alternate event paths, and failures inside the sanitizer. If an attachment is not necessary, the safest rule is often not to collect it.

The Attachment Risk Matrix

Treat each payload as a separate review card. The same three questions apply: where can prompt data appear, what does event-only redaction prove, and what is the safer control?

The crucial question is not merely, “Do we redact prompts?” It is, “Which serialization paths can carry prompt-derived data, and where is each path stopped?”

Use The SEAL Test Before Shipping

A practical review can fit into four steps: Source, Envelope, Access, Lifecycle.

1. Source

Inventory every place prompt-derived data can exist at crash time: UI state, application logs, network diagnostics, model request objects, temporary files, clipboard integrations, file names, local database fields, and process memory.

Then map which telemetry features can read each source. Do not rely on the name of an option. A “screenshot,” “view hierarchy,” “breadcrumb,” and “attachment” are different collection paths even when they appear on the same issue page.

2. Envelope

Capture a synthetic failure with a unique canary such as OV-ATTACHMENT-TEST-20260809-NOT-A-REAL-SECRET. Put it in every prompt-related surface one at a time, trigger the relevant error and native-crash paths, and inspect the complete outbound envelope before it crosses the trust boundary.

Check every item, not just the event JSON. Repeat with:

The test passes only when the canary is absent from all unapproved payloads. A filtered event alongside an unfiltered file is a failure.

3. Access

Ask who can retrieve an attachment after ingestion. Sentry documents organization-level attachment roles and project-level access. Apply least privilege, log administrative changes, and test with a real low-privilege account rather than trusting the configuration label.

The OWASP Logging Cheat Sheet reinforces the larger principle: logs should not directly record access tokens, passwords, sensitive personal data, or other material whose collection is prohibited or dangerous. An attachment used for debugging should not become a policy exception merely because it is a file rather than a log field.

4. Lifecycle

Document when each artifact is created, where it waits, when it uploads, how long it is retained, and how it is deleted. Include local crash queues and backups. A user deleting a chat does not necessarily delete a crash file already written to disk or an attachment already stored by a telemetry provider.

Sentry says attachments can be deleted, but it also says quota is counted as soon as the attachment is stored. That is a useful reminder that deletion is a later lifecycle action, not proof that collection never happened.

The Hard-Crash Problem

Normal application code has more opportunities to sanitize data. A hard crash does not.

The process may be corrupt, signal handling may be restricted, memory allocation may be unsafe, and UI access may be unavailable. Sentry's attachment specification describes screenshot capture during a crash as best effort and notes that some environments restrict UI access after a signal break.

This is why privacy controls that depend on a complex last-second sanitizer deserve skepticism. Prefer architectural controls that reduce sensitive state before the crash:

The better privacy boundary is often upstream of the crash handler.

Does Server-Side Scrubbing Fix It?

Not for arbitrary attachments under Sentry's documented model. Sentry distinguishes event data scrubbing from attachments and explicitly says it does not apply data scrubbing to attachments.

Server-side rules can still be valuable for supported structured event fields. A local Relay can also keep supported sensitive event data from reaching Sentry. Neither fact should be generalized into “every byte in every attachment is scrubbed.” Use the attachment documentation and a captured envelope to define the actual boundary.

That distinction also explains why a dashboard preview can be misleading. A beautifully filtered issue page may be rendering the processed event while a downloadable attachment preserves a different representation.

What This Means For AI Privacy Claims

An AI product can truthfully redact prompt fields before sending crash events and still have an attachment gap. The correct review is not to accuse the product of leaking prompts without evidence. It is to ask for scope:

If a vendor answers only with “we use beforeSend,” ask whether the implementation examines hint.attachments and how native crash files are handled. That one follow-up separates an event-field claim from an envelope-wide claim.

Where OpenVeil Fits — And Where It Does Not

OpenVeil is a hosted privacy-focused AI workspace for adults. In normal chat use, conversation history is kept in the browser rather than stored as a server-side chat-history record, prompts and uploads still undergo active processing by OpenVeil and necessary service providers, and OpenVeil says customer prompts, outputs, uploads, images, and videos are not used to train foundation models.

That product boundary can reduce one familiar source of persistent server-side chat history. It does not prove that an unrelated application, operating system, browser extension, crash reporter, or telemetry attachment cannot capture sensitive material. OpenVeil does not claim to make every surrounding device or third-party debugging system safe.

For a wider evaluation, use the AI privacy claim checklist. For the adjacent event-field problem, see how client-side redaction can still leave AI prompts in crash reports and whether an SDK can capture a prompt before it is sent.

A Practical Shipping Checklist

Before enabling crash attachments in an AI product:

The defensible claim is specific: “These tested fields and attachment types are removed before this transport.” The indefensible version is universal: “Crash reporting cannot capture prompts.”

Frequently Asked Questions

Can beforeSend remove a Sentry attachment?

In the JavaScript SDK, yes. Sentry documents that beforeSend and global event processors can add, remove, or modify attachments through hint.attachments. Code that accepts only the event argument, however, has not shown that it handles attachments.

Does Sentry scrub log-file and screenshot attachments?

Sentry's current attachment documentation says it does not apply data scrubbing to attachments. Sanitize an approved attachment before it is sent, or do not attach it.

Are Sentry minidumps stored by default?

Sentry says native crash files are used to create events and dropped by default. Administrators can enable storage of native crash reports or minidumps as attachments, which creates a different retention and access boundary.

Can a minidump contain an AI prompt?

Potentially. Sentry warns that minidumps may contain in-memory representations of input fields as well as environment variables and local paths. Whether a particular prompt appears requires a controlled test; it should not be assumed from documentation alone.

Does deleting a chat delete a queued crash attachment?

Not necessarily. Chat deletion and telemetry-file deletion are separate operations unless the product explicitly connects them. Test local crash queues, restart uploads, provider retention, and backups.

Is this a reason to avoid all crash reporting?

No. Crash reporting can be valuable. The lesson is to minimize collection, separate structured events from attachments, test the full envelope, restrict access, and state privacy claims at the boundary actually proven.

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.