Can An Accessibility Identifier Leak An AI Prompt Into Crash Telemetry?

September 3, 2026

Yes—if an app builds an accessibility identifier from prompt text. Learn the documented Sentry path and a synthetic-canary test that proves the fix.

Yes. An accessibility identifier can leak an AI prompt into crash telemetry if an app builds that identifier from the prompt, filename, chat title, email address, or other user content. The identifier is meant to be a stable programmatic name for a UI element, not a place to store what the user typed.

Watch The 30-Second Summary

Watch this video on YouTube

This is a conditional risk, not evidence that every crash SDK reads every prompt. Sentry says its Apple view-hierarchy attachment excludes ordinary UILabel and UITextView text. But the same documentation says the attachment can include each view's identifier and specifically tells developers to disable accessibility-identifier reporting when those identifiers contain personal information.

The safest design is simple: keep identifiers static and content-free, test the received telemetry with synthetic canaries, and treat crash data as a separate record from AI chat history.

Research cutoff: September 2, 2026 (America/Chicago).

What Is Confirmed

Apple defines accessibilityIdentifier as a string that identifies an interface element. Apple says the identifier is useful in UI automation and helps developers avoid inappropriately using the accessibility label for that purpose.

That intended use points toward values such as:

• prompt_composer
• send_button
• attachment_picker
• conversation_list

It does not require the user's prompt, a customer's name, or a document title.

Sentry's current Apple view-hierarchy documentation says view-hierarchy attachments are opt-in. When enabled, the SDK can attach a JSON representation of the interface to an error event. Sentry says the standard attachment does not collect visible user text such as UILabel or UITextView content. It lists structural fields including type, position, dimensions, alpha, visibility, and an identifier when applicable.

The same page gives this explicit privacy control:

import Sentry

SentrySDK.start { options in
    options.attachViewHierarchy = true
    options.reportAccessibilityIdentifier = false
}

Sentry's warning is narrow and important: if an app uses accessibilityIdentifier with personal information, disable its reporting. The current open-source SentryViewHierarchyProvider also shows the provider passing that option into the hierarchy exporter.

Apple's identifier and a visible accessibility label are different properties. Giving a text field the static identifier prompt_composer does not reveal the words typed into it. The leak occurs when application code turns dynamic content into diagnostic metadata.

What Is Still Unclear

Public SDK documentation cannot establish what one AI app actually transmits. That requires the app's production configuration and a controlled capture test.

Questions that remain implementation-specific include:

• Is view-hierarchy capture enabled in the production build?
• Which Sentry Cocoa version and framework integration are installed?
• Does the app set reportAccessibilityIdentifier to false?
• Are UIKit, SwiftUI, React Native, Flutter, WebView, or custom-rendered controls involved?
• Does a framework map a test ID or semantic property into the native accessibility identifier?
• Are identifiers constructed from prompt text, filenames, conversation titles, route parameters, or account data?
• Does a custom hierarchy exporter add fields beyond Sentry's standard schema?
• Can the same value appear in logs, breadcrumbs, error context, screenshots, replay, feedback, or custom attachments?
• Is a locally queued event uploaded after the app restarts?
• Who can view, download, export, or copy the resulting telemetry?

This article does not claim that Sentry exposed a particular OpenVeil, ChatGPT, Claude, Gemini, or other AI prompt. It explains a documented data path developers can create—and how to prove whether their own app created it.

How A Harmless Test ID Becomes Sensitive Data

Consider a static UIKit identifier:

promptTextView.accessibilityIdentifier = "prompt_composer"

If a view hierarchy includes that value, it reveals that a prompt composer existed in the interface. It does not reveal the prompt.

Now consider an unsafe dynamic identifier:

promptTextView.accessibilityIdentifier = "prompt_\(draftText)"

If the draft contains a medical question, legal strategy, source-code secret, or personal conflict, the identifier now contains the same sensitive content. A crash report can copy it even if:

• the user never pressed Send;
• the model request was blocked;
• the visible prompt was removed from a screenshot;
• the AI conversation was later deleted; or
• normal chat history is stored only in the browser or app.

The data changed categories because of the app's code. It began as draft content and became an identifier. A telemetry SDK does not have to scrape the text field to collect it; it only has to serialize the identifier it was given.

The same mistake can happen through a filename or title:

attachmentRow.accessibilityIdentifier = "file_\(uploadedFileName)"
conversationCell.accessibilityIdentifier = "chat_\(conversationTitle)"

Names such as oncology-results.pdf, Acquisition Targets, or Tax Audit Response can disclose more than developers expect. Stable values such as attachment_row and conversation_cell preserve the automation hook without copying the subject matter.

Why Screenshot Masking Does Not Fix The Identifier

A screenshot and a view hierarchy are separate representations.

A screenshot contains pixels. Masking the prompt composer can hide visible text in that image. A view hierarchy contains structured properties about interface nodes. If the identifier contains the prompt, changing the screenshot does not rewrite the JSON.

The reverse is also true. Disabling identifier reporting does not prove a screenshot, replay, log, breadcrumb, exception, or custom attachment is clean. Each artifact needs its own control and test.

For example, a safe screenshot and unsafe hierarchy could coexist:

{
  "type": "UITextView",
  "identifier": "prompt_Project Cedar walk-away price",
  "visible": true,
  "width": 340,
  "height": 160
}

The problem is not the UITextView type or geometry. The problem is the developer-supplied identifier.

For the broader distinction between these artifacts, see Can A Crash-Report View Hierarchy Expose An AI Prompt Even When The Screenshot Is Masked?.

Does sendDefaultPii = false Prevent This Leak?

Do not treat a general PII setting as proof that identifiers are safe.

Sentry documents reportAccessibilityIdentifier as a separate control. That is a strong reason to configure and test the specific field rather than infer its behavior from a broader privacy toggle. Pattern-based scrubbing can also miss a prompt because sensitive AI text is not limited to standard email, phone, card, or IP-address formats.

A fictional merger codename or private diagnosis may look like ordinary prose. A scrubber cannot reliably know that the words are confidential.

Use this order of controls:

1. Never put user content in an identifier.
2. Disable accessibility-identifier reporting when the hierarchy is useful but identifiers are not.
3. Disable the entire view-hierarchy attachment when it is unnecessary for the diagnostic purpose.
4. Apply client-side event filtering before queueing and transmission.
5. Apply server-side scrubbing as an additional layer.
6. Restrict access, exports, alerts, tickets, and retention.

The first control is strongest because it prevents the sensitive value from entering this field at all.

Use The STATIC Test

The STATIC test gives developers a release gate for accessibility identifiers on sensitive AI screens.

S — Stable Names Only

Identifiers should describe the element's role, not its current content. Prefer prompt_composer, message_row, and file_remove_button.

Reject identifiers that interpolate:

• prompt or response text;
• a user's name or email;
• a conversation title;
• a filename or file path;
• a URL or search query;
• a model-generated summary;
• a customer, patient, matter, or project name; or
• any substring derived from those values.

T — Trigger A Controlled Event

Use a non-production account and a synthetic marker such as OV-A11Y-CANARY-83QZ. Do not use a real secret.

Place the marker in the unsent composer, then trigger a handled test error while the sensitive screen is visible. Sentry says view-hierarchy capture is best effort and may not be available for a fatal crash when the UI thread cannot be used. Its documentation also says beforeCaptureViewHierarchy can decide whether to capture for an event but does not work for crash events. A handled event is therefore a clearer first test.

A — Acquire The Actual Attachment

Verify that the event really has a view-hierarchy attachment. A missing attachment is not a clean result.

Use a positive control: give a harmless test element a known identifier such as ov_positive_control. Confirm that this value appears when reporting is enabled. If it does not, the capture path may never have run.

T — Traverse Every Node And Field

Download the received JSON and search values—not just property names—for the canary. Inspect every node, nested child, unknown field, and framework-specific extension.

Repeat the search in:

• the event payload;
• breadcrumbs and custom logs;
• screenshots and replay;
• error messages and contexts;
• feedback records;
• custom attachments; and
• downstream alerts, tickets, exports, and data warehouses.

I — Interrupt And Restart

Repeat the test with the device offline, close the app, clear the visible draft, reconnect, and restart. This can reveal telemetry queued locally for later upload.

Firebase's current Crashlytics documentation provides a useful cross-check on this general lifecycle: developers can attach custom keys and logs to crash reports, and some reports are stored on-device before later transmission. Firebase also says clearing a user identifier does not remove existing Crashlytics records. The exact Sentry and Crashlytics mechanisms differ, but both illustrate why visible app state and diagnostic-record lifecycle must be tested separately.

C — Confirm The Production Control

After the test, inspect the release build—not only a debug build—and record:

• SDK and framework versions;
• the exact hierarchy and identifier options;
• received-field inventory;
• canary results;
• access roles;
• retention and deletion behavior; and
• the date the evidence was collected.

Repeat the gate after SDK upgrades, UI migrations, test-automation changes, or new observability integrations.

SwiftUI, React Native, And Other Frameworks Need Separate Proof

The source-level property may not map to telemetry exactly as a developer expects.

Sentry says SwiftUI view-hierarchy support is highly limited because not every SwiftUI view has a backing UIKit view. A Text view, for example, may render directly rather than creating a corresponding UILabel. That means an absent node can reflect the rendering architecture, not a privacy control.

React Native, Flutter, WebViews, and custom renderers can introduce different bridges and exporters. A testing prop may become a native accessibility identifier on one platform while remaining a framework-only attribute on another. A custom exporter may add semantic fields the base SDK does not define.

Do not generalize from an iOS Simulator test to every platform. Test the actual release artifact on each supported renderer and operating system.

What Developers Should Change

Add A Static-Identifier Rule

Make content-free identifiers a coding standard. A lint rule or review check should reject string interpolation and user-derived variables assigned to accessibility or test identifiers.

Keep Accessibility Labels Useful

Do not remove labels that people using assistive technology need. Apple provides an identifier so automation can locate an element without overloading the human-facing accessibility label. Privacy work should preserve accessibility while separating programmatic names from user content.

Allowlist Telemetry Fields

Prefer an explicit list of fields allowed to leave the client. Denylists of secret-looking patterns will miss ordinary prose whose sensitivity depends on context.

Make Sensitive Screens A Named Boundary

Chat composers, document viewers, voice transcripts, health forms, payment screens, and authentication flows deserve stricter capture rules. If a hierarchy is not necessary there, disable it for those events or screens.

Verify Deletion Separately

Deleting a conversation should not be described as deleting its telemetry unless the product actually links those records and proves the downstream deletion. Crash events, local queues, exports, support tickets, and backups can each follow different lifecycles.

Where OpenVeil Fits — And Where It Does Not

OpenVeil is a hosted, privacy-focused AI workspace for adults. For normal private chat sessions, history is stored in the user's browser, and OpenVeil does not maintain a normal server-side chat-history record. OpenVeil also does not use prompts, uploaded files, images, audio, selected local-history context, or AI outputs to train foundation models.

Those boundaries reduce the ordinary long-lived server chat-history layer. They do not make OpenVeil fully offline, anonymous, zero-log, or immune to telemetry, extensions, screenshots, device software, or compromised endpoints. Active requests still require processing by OpenVeil and necessary AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers. Separate operational, account, billing, security, and abuse records can still exist.

OpenVeil is not a crash-report auditor and does not protect a prompt that another app deliberately copies into diagnostic metadata. Users should minimize sensitive details before sending them and protect the browser profile where local history is stored.

For adjacent checks, read Can A Crash-Reporting SDK Capture An AI Prompt Before It Is Sent? and Can A Crash-Report Attachment Bypass Client-Side Prompt Redaction?.

Frequently Asked Questions

Can Sentry collect an iOS accessibility identifier?

Yes, when view-hierarchy attachment capture is enabled and identifier reporting is allowed. Sentry documents a separate reportAccessibilityIdentifier option for disabling that field.

Does Sentry's standard Apple view hierarchy collect all visible prompt text?

Sentry says it does not collect ordinary UILabel and UITextView text in the standard attachment. A prompt can still leak if the app puts it in an identifier, custom field, log, breadcrumb, screenshot, replay, or another artifact.

Should an accessibility identifier contain the field's value?

No. It should be a stable programmatic name for the element. The current value belongs in application state, not in the identifier.

Is disabling accessibility-identifier reporting enough?

No. It closes one field. You still need to inspect screenshots, replay, logs, breadcrumbs, event context, feedback, attachments, exports, and delayed uploads.

Can an unsent AI prompt leak this way?

Yes. The app can assign the draft to an identifier before submission. The crash path and the model-request path are separate.

Does deleting the AI chat delete the crash record?

Not automatically. The conversation and diagnostic event are separate records unless the product explicitly connects and verifies their deletion workflows.

What is the best test value?

Use a unique synthetic canary that contains no real personal or confidential information. Include a harmless positive-control identifier so you know the hierarchy capture actually worked.

Bottom Line

An accessibility identifier can leak an AI prompt when developers turn dynamic user content into a field meant for stable UI automation. Sentry does not need to scrape the text control for that to happen; the application has already copied the prompt into exportable metadata.

Keep identifiers static, disable identifier reporting when it is unnecessary, inspect the actual received hierarchy with a synthetic canary, and test every sibling telemetry artifact separately.

If you want a hosted AI workspace with browser-local normal chat history and no normal server-side chat-history record, try OpenVeil after reviewing its documented boundaries and privacy policy.