Can Client-Side Redaction Stop AI Prompts From Reaching Crash Reports?
Yes, but only when redaction runs before telemetry is queued or transmitted and covers every path that can copy prompt text—not just error events.
Yes—but only if client-side redaction happens before crash data is queued or transmitted and covers every telemetry path that can carry prompt text. One beforeSend callback is not a complete safeguard. Errors, breadcrumbs, spans, logs, metrics, replay, attachments, and offline queues can have separate collection and export paths.
Last updated: July 31, 2026
Who This Is For
This guide is for developers, privacy reviewers, and AI-tool buyers who need to answer a narrow but important question: can an application remove an AI prompt before a crash-reporting provider receives it?
It builds on two related questions:
- Can a crash-reporting SDK capture an AI prompt before it is sent?
- Can AI error logs accidentally capture prompt content?
The answer is not determined by whether a chat message was submitted to a model. It is determined by where the text was copied, when the redaction ran, and which component crossed the network boundary first.
The Short Answer: Redaction Works Only Before The Boundary
Client-side redaction can stop prompt text from reaching a crash-reporting service when all four conditions are true:
- The application knows every place prompt text can enter telemetry.
- The app either avoids collecting that text or replaces it before export.
- The same rule covers every relevant signal, including queued reports sent after restart.
- Tests inspect the actual outbound payload and downstream views—not just the source code.
If raw text reaches the vendor and is scrubbed there, that may reduce storage and operator exposure, but it did not stop the prompt from reaching the crash-reporting provider. That distinction matters for threat models, contracts, privacy notices, and user expectations.
Use A Four-Gate Model Instead Of One Redaction Hook
Think of prompt-bearing telemetry as passing through four gates:
| Gate | Question | Strongest control |
|---|---|---|
| Collection | Did the app copy the prompt into a log, breadcrumb, attribute, attachment, or error? | Do not collect raw prompt text |
| Assembly | Did an SDK add sensitive context while building the event? | Signal-specific client hooks and an allowlist |
| Queue | Can a raw report persist locally and upload after restart or consent? | Inspect and sanitize before local persistence |
| Export | Does any network request or relay still contain the canary text? | Payload tests at every destination |
The first gate is best. Telemetry that never contains the prompt does not depend on a regex, SDK version, transport callback, or vendor-side configuration to remove it later.
Instead of logging the words a user typed, record bounded diagnostic facts such as:
composer_has_text=trueprompt_length_bucket=500_to_999attachment_count=2submit_phase=validationmodel_request_started=falseredaction_policy_version=3
That can preserve operational value without turning a private question into debugging context.
Why Sentry's beforeSend Is Not A Universal Prompt Filter
Sentry's JavaScript documentation describes beforeSend as the last opportunity to modify or discard an error or message event before it is sent. The same page documents separate callbacks for breadcrumbs, spans, logs, metrics, and transactions. (Sentry: filtering and sampling events)
That separation creates a common failure mode: a team scrubs event.message in beforeSend, sees a passing error-event test, and assumes prompt text cannot leave the client. The prompt may still exist in:
- a breadcrumb retained before the error
- a span or transaction attribute
- a structured log record
- a metric attribute or tag
- an attachment, replay, minidump, or envelope item
- another analytics or support SDK using a different transport
Sentry provides beforeBreadcrumb for breadcrumbs and separate hooks such as beforeSendSpan, beforeSendLog, and beforeSendMetric for other signals. Its documentation also notes that some stream-mode spans can be sent immediately, before a later transaction callback could change them. The practical lesson is simple: map redaction controls to signal types, not to a vendor name.
Current Sentry Data-Collection Settings Need Explicit Review
Sentry's current JavaScript options document a dataCollection configuration, available since SDK version 10.57.0. The documentation warns that when an application opts into that configuration object, omitted fields use permissive defaults. Documented categories include user information, generative-AI inputs and outputs, request or response bodies and headers, cookies, URL query parameters, and stack-frame variables. (Sentry JavaScript SDK options)
For an AI interface, review and explicitly set every applicable category. In particular:
- disable generative-AI input and output capture unless there is a justified, disclosed need
- do not collect request bodies merely because they simplify debugging
- remove prompt-like values from breadcrumbs and structured attributes
- treat URL query parameters, user context, and stack locals as possible alternate paths
- retest after SDK upgrades and configuration changes
An opt-out is still only one layer. Application code can explicitly add values to an event, and another SDK may collect the same data independently.
Server-Side Scrubbing Is Useful, But It Is A Different Boundary
Sentry distinguishes SDK-side filtering from server-side scrubbing. Its sensitive-data documentation says SDK-side scrubbing prevents data from being sent to Sentry, while server-side scrubbing prevents the service from storing the data after it arrives. (Sentry: manage sensitive data)
Sentry's server-side documentation also explains that default rules target selected values and common key names, while custom rules can still create false positives or false negatives because the service does not know an application's full context. (Sentry: server-side scrubbing, Sentry: advanced data scrubbing)
So these statements are not equivalent:
- “The provider does not store the prompt after scrubbing.”
- “The prompt never left the device.”
- “The prompt never reached any third party.”
Only a verified pre-export control supports the second statement. Supporting the third requires testing every third-party destination, not just the crash reporter.
Regex Alone Is A Weak Prompt-Redaction Strategy
Passwords, card numbers, and tokens sometimes have recognizable formats. AI prompts do not. A prompt can be a diagnosis, source code, a business plan, a legal question, a person's name, or an ordinary sentence whose sensitivity depends entirely on context.
A denylist such as password|ssn|secret will miss most sensitive prompts. A broad pattern that deletes all free-form text may also erase useful error messages and still miss encoded, nested, truncated, or duplicated values.
Prefer this order of controls:
- Do not collect content. Instrument states and categories instead of user text.
- Allowlist fields. Export only properties that are deliberately approved.
- Use structural transforms. Remove known prompt, message, request-body, and attachment fields regardless of their value.
- Use pattern matching as backup. Detect known secret formats, but do not treat regex as proof that arbitrary prose is safe.
- Fail closed. If an event does not match the expected schema, drop it or quarantine it locally for review rather than exporting it raw.
OWASP's Logging Cheat Sheet recommends removing, masking, sanitizing, hashing, or encrypting sensitive data and calls for due diligence before logs are sent to another organization. It specifically flags personal data, health data, secrets, and commercially sensitive information as categories that should usually be excluded or handled carefully. (OWASP Logging Cheat Sheet)
Attachments And Native Crash Data Need Separate Tests
An event callback may not control every attachment. Sentry documents limited server-side attachment scrubbing, including special rules for minidumps and limitations for some non-minidump files. It warns that some plain-text Crashpad attachments cannot be scrubbed with the documented server-side rules. (Sentry: attachment scrubbing)
This matters when an AI app attaches console exports, state snapshots, diagnostic bundles, screenshots, database fragments, or native crash artifacts. Removing prompt from an error JSON object does not prove the same text is absent from a sibling file.
Inventory attachments by filename, MIME type, producer, lifecycle, and transport. If the application does not need an attachment for a defined support case, disable it. If it is necessary, build a dedicated sanitizer and test the serialized bytes.
Offline And Opt-In Queues Can Reintroduce Old Raw Data
Some crash tools can retain reports locally and send them later. Firebase Crashlytics documents controls for disabling automatic collection and says unsent reports can be cached on the device for later sending or deletion. It also documents custom keys and logs that are associated with crash data. (Firebase Crashlytics: customize crash reports, Firebase Crashlytics API reference)
That means a new redaction rule may protect newly assembled events while an older raw report remains in a queue. A proper rollout must answer:
- Are events sanitized before they are written locally or only before upload?
- What happens to reports queued under an older policy version?
- Does enabling collection later send historical reports?
- Can users delete unsent reports?
- Does the queue contain attachments outside the main event object?
Version the redaction policy and include the version as non-sensitive telemetry. On upgrade, either migrate older queued events through the current sanitizer or delete them.
A Canary Test That Produces Evidence
Use a synthetic phrase that cannot be confused with real user data, such as:
OV-CRASH-REDACTION-7F3K
Do not use an actual medical question, password, customer name, or production secret. Insert the canary into each location that could plausibly receive prompt content, then trigger the complete delivery lifecycle.
Test Matrix
| Dimension | Cases to test |
|---|---|
| Signal | Error, message, breadcrumb, span, transaction, log, metric, replay, attachment, minidump |
| Trigger | Typing, autosave, validation failure, submit failure, network timeout, fatal crash, non-fatal error |
| Timing | Immediate send, background send, app restart, offline recovery, later consent or opt-in |
| Destination | Browser network payload, first-party relay, crash vendor, data warehouse, alerts, email, exports |
| Transformation | Plain text, nested JSON, URL parameter, attribute, encoded value, truncated value, filename |
For each test, search for the canary in:
- the serialized event before the client hook
- the event after every client hook
- browser or device network captures
- local queued files or databases
- relay ingress and egress, if used
- the provider's issue, event, search, attachment, and export views
- downstream notifications and integrations
OpenTelemetry's security guidance makes the same broader point: a collector cannot automatically determine which data is sensitive in an application's context. It recommends data minimization and documents attribute, filter, redaction, and transform processors as layers rather than automatic guarantees. (OpenTelemetry: handling sensitive data)
Pass Criteria
The test passes only when:
- no outbound payload to an external provider contains the canary
- no locally queued raw event can upload later
- no attachment or secondary signal contains the canary
- provider search and export return no canary matches
- the expected non-sensitive diagnostic fields still arrive
Checking only the provider's issue screen is insufficient. A value may have arrived and been scrubbed, be hidden in an attachment, or have propagated to an integration that is not visible on that screen.
Control Comparison
| Control | Can stop the crash provider receiving prompt text? | Main limitation |
|---|---|---|
| Do not collect raw prompt text | Yes | Requires disciplined instrumentation |
| Client-side allowlist and signal-specific hooks | Yes, when complete and tested | New signals or fields can bypass old rules |
| First-party local relay | Not by itself | Text already left the browser or device and must still be scrubbed before vendor export |
| Vendor-side scrubbing | No | Provider receives the payload before storage filtering |
| Access controls and retention limits | No | Reduce later exposure, not initial collection |
| Hashing the whole prompt | Removes readable text, but is usually inappropriate | Creates a persistent correlator and can still leak low-entropy values |
What This Means For OpenVeil Users
OpenVeil is designed so chat-history persistence is browser-local rather than stored as a server-side chat-history record. That narrows one important retention path, but it does not justify broad claims such as “fully offline,” “anonymous,” “zero logs,” or “no provider processing.” Active requests still require hosted processing, and unrelated telemetry risks must be evaluated separately.
The useful comparison question is not “Does this product say private?” Ask:
- Where is readable chat history stored?
- What happens during an active request?
- Can client telemetry copy text before or outside that request?
- Which redaction controls run before third-party transmission?
- Has the vendor tested errors, breadcrumbs, spans, logs, replay, and attachments?
For the storage distinction, see what browser-local chat history means in an AI app and why no chat history does not mean no logs.
If you want a hosted AI chat whose readable history remains in your browser instead of becoming a server-side chat-history record, try OpenVeil. Use the same care you would with any hosted AI service: review the privacy terms and do not assume local history means the active request never leaves your device.
Frequently Asked Questions
Can beforeSend remove an AI prompt from a Sentry error?
Yes, it can modify or drop error and message events before transmission. But Sentry documents separate hooks for breadcrumbs, spans, logs, metrics, and transactions. You must also test replay, attachments, minidumps, queued reports, and any other SDK.
Is server-side data scrubbing the same as client-side redaction?
No. Server-side scrubbing can reduce what the provider stores, but the raw value reaches the provider first. Client-side redaction aims to remove the value before that network boundary.
Can a regex reliably identify every sensitive AI prompt?
No. Prompt sensitivity is contextual and free-form. Use data minimization, approved-field allowlists, and structural removal of prompt-bearing fields. Treat patterns as a backup for recognizable secrets.
Does disabling automatic crash collection delete queued reports?
Not necessarily. Some SDKs cache unsent reports locally and may send them later when collection is enabled. Test queue creation, restart, later opt-in, migration, and deletion behavior for the exact SDK version.
Should an app hash prompts for debugging?
Usually not. Hashing removes readable text but creates a stable correlator, can expose low-entropy values through guessing, and rarely provides the diagnostics a crash report needs. Prefer coarse length buckets and non-content state fields.
Can teams test redaction without using real secrets?
Yes. Use a unique synthetic canary, place it in every plausible telemetry path, trigger the full event lifecycle, and search payloads, queues, provider views, attachments, exports, and alerts.
Bottom Line
Client-side redaction can stop AI prompts from reaching crash reports, but only as a verified system—not as a single callback. Do not collect raw prompt text when operational metadata will do. Allowlist exported fields, cover each telemetry signal and attachment path, sanitize before local persistence and transmission, and prove the result with a canary across restarts and downstream destinations.