Independent analysis by NHI Mgmt GroupSource article: Lumia Security, “Hide & Seek: ChatGPT, Where Are My Files?” (March 22, 2026)

TL;DR: Hidden routing between Safari, Apple Intelligence and ChatGPT can move file uploads out of view of network monitoring tools, creating a blind spot for SASE, SWG and DLP controls that assume traffic follows predictable paths, according to Lumia Security. Visibility is now a governance problem, not just a tooling problem, because trusted ecosystem behaviour can defeat inspection before security teams know it exists.


At a glance

What this is: NHI Mgmt Group's analysis, drawing on Lumia Security's research: Apple Intelligence and Safari can route ChatGPT file uploads through hidden intermediary infrastructure, leaving some enterprise inspection tools unable to see the activity.

Why it matters: It matters because IAM and security teams increasingly need to govern AI usage through observable paths, and traditional visibility controls fail when platform behaviour changes the route without user or admin awareness.


Context

Enterprise visibility controls still assume that a user, a browser and a cloud service form a traceable path. That assumption weakens when a platform inserts its own privacy or relay layer between the endpoint and the destination, especially for browser-based AI use cases.

In this case, the security problem is not that ChatGPT uploads exist. It is that the upload path can become opaque to the controls that organisations rely on for monitoring, classification and policy enforcement. That creates a blind spot across browser, device and network governance.


Key questions

Q: What breaks when browser-based AI traffic is routed through a hidden relay?

A: Inspection tools lose the direct path they rely on for classification, logging and policy enforcement. The result is not always total loss of connectivity, but a partial blind spot where security teams can see that AI traffic exists without being able to verify its destination, content context or control outcome reliably.

Q: When should organisations prioritise visibility validation over blocking AI features?

A: They should prioritise validation first when a platform may rewrite traffic paths underneath the user. Blocking before understanding the relay behaviour can turn a visibility problem into an availability problem, while validation shows whether the current control stack can still govern the session without breaking approved work.

Q: What are the signs that production AI monitoring is failing?

A: The main signs are delayed discovery, noisy alerts with no root cause, and a reliance on downstream business metrics to spot upstream model problems. If teams only notice issues after revenue, quality, or fairness outcomes move, monitoring is too weak to support governance.

Q: How should security teams govern AI usage when the transport path is not fully visible?

A: They should move from application-only policy to path-aware governance. That means validating intermediary routing, defining which platforms are allowed to alter inspection paths, and deciding whether to apply compensating controls, exception handling or usage restrictions when visibility cannot be preserved.


Technical breakdown

Why relay-based routing defeats inspection

Relay-based routing changes the observable network path, so the security stack sees an intermediary rather than the final service relationship. Secure web gateways, CASBs and network proxies depend on destination fidelity, request context and session continuity to classify traffic. When a browser or OS feature inserts a privacy relay, the traffic may still be legitimate, but the inspection point no longer sees the same metadata or endpoint relationship it expected. That is why the issue shows up as a visibility failure rather than a simple access-control problem.

Practical implication: Treat relay behaviour as a visibility control boundary and test whether your monitoring stack can still classify the session end to end.

Why Safari and Apple Intelligence create a broader governance gap

The important detail is not one app or one browser, but shared ecosystem logic. Apple Intelligence and Safari appear to reuse the same relay model, which means a control gap discovered in one workflow can generalise across adjacent workflows without obvious change in the user experience. That is a classic governance problem in platform ecosystems: the organisation believes it is governing a known application path, while the operating system quietly rewrites the transport layer underneath it.

Practical implication: Map AI usage paths by platform behaviour, not just by application name, and reassess any policy that assumes browser traffic is directly inspectable.

Why blocking the relay is not a clean fix

A hard network block can restore visibility in theory, but it may also break the application workflow entirely. That creates a control trade-off between surveillance and usability, and it pushes the decision into architecture rather than simple policy. The real technical lesson is that some AI features inherit privacy routing natively, so a perimeter rule can become an availability control by accident. Security teams need to understand where the relay is embedded, where it is optional, and where it is effectively part of the platform contract.

Practical implication: Validate break-glass and exception paths before enforcing network blocks on relay-mediated AI traffic.


NHI Mgmt Group analysis

Visibility gaps are now a platform governance issue, not a logging issue. The article shows how an ecosystem can preserve user privacy while quietly removing enterprise observability. That matters because many security programmes still equate “traffic exists” with “traffic can be monitored.” In practice, AI usage routed through browser or OS relay logic can escape the assumptions embedded in SWG, CASB and DLP tooling. Practitioners should treat this as a governance failure mode, not a point product gap.

The named concept here is AI relay opacity. That is the condition where AI traffic is technically present but operationally indistinguishable to the tools meant to govern it. The blind spot emerges because the control plane and the transport plane no longer share the same assumptions about path, destination and inspectability. This weakens policy enforcement across browser-based AI usage and makes discovery harder than most teams expect.

Browser-mediated AI access is becoming a control-plane exception path. When a browser, an operating system and a third-party AI service collaborate through hidden routing, identity and access policy no longer tells the full story. The relevant question becomes whether the organisation can prove where the request went, not merely whether the request was allowed. That shifts the burden onto visibility architecture and makes endpoint behaviour a first-class governance concern.

This pattern should force security leaders to separate user intent from transport truth. A user may believe they are opening a direct session to a cloud AI service, while the platform silently inserts a relay that changes what is visible downstream. That undermines policy design based on application lists alone and increases the value of path validation, telemetry correlation and platform-aware control testing. Practitioners should govern the route, not just the app name.

Identity governance must now account for AI usage paths that are hidden by design. Even when the session is not an NHI problem in the narrow sense, the same governance discipline applies: know what is connecting, through which intermediary, and under which policy boundary. When path opacity exists, assurance moves from access approval to observability assurance. Teams should treat concealed routing as a control exception that demands explicit review.

From our research library:

What this signals

AI relay opacity: when browser or OS features insert intermediary routing, the security stack can lose the very metadata it needs to govern AI use. That makes visibility assurance a design requirement, not an operational afterthought, and it pushes teams toward platform-aware monitoring rather than app-list enforcement.

Security programmes that rely on direct destination inspection need to reassess whether their control assumptions still hold in browser-mediated AI flows. The more AI features inherit privacy infrastructure from the platform layer, the more likely it is that policy enforcement will depend on path validation instead of simple traffic classification.


For practitioners

  • Validate AI traffic paths on Apple devices Test Safari and Apple Intelligence workflows separately from other browsers and operating systems, then confirm whether file uploads remain inspectable through your current SWG, CASB and DLP stack.
  • Document relay-mediated exceptions in policy Record which browser and OS features introduce intermediary routing, what telemetry is lost, and which security controls fail open or fail closed when the relay is active.
  • Reassess inspection assumptions for browser-based AI Review whether your monitoring design depends on direct destination visibility, then decide where platform-managed routing requires compensating controls or different enforcement points.
  • Define break-glass handling before blocking relays If you block relay infrastructure at the network layer, predefine how users can continue approved ChatGPT workflows without creating unmonitored shadow paths.

Key takeaways

  • Hidden relay behaviour can make ChatGPT file uploads invisible to the controls that normally inspect browser traffic.
  • The failure is not merely technical. It exposes a mismatch between platform privacy design and enterprise visibility assumptions.
  • Teams need path-aware governance, tested exception handling and validation of AI traffic routes before they rely on network inspection alone.

Related NHI Mgmt Group resources: Ultimate Guide to NHIs: Key Challenges and Risks · Threat Intelligence Platform Buyer's Guide · AI Security Platform Buyer's Guide


Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity eventsThe article is fundamentally about monitoring blind spots in network-visible AI traffic.
PR.DS-10 — Data-in-transit is protectedRelay-mediated uploads change how data in transit is handled and inspected.
PR.AA-05 — Access Permissions, Entitlements and AuthorizationsAI access control depends on knowing which platform path the request actually takes.
Recommendation — Validate that AI browser flows remain observable under DE.CM-01 and close any telemetry gaps introduced by relay routing. Review transit protections and inspection boundaries for AI uploads routed through platform-managed relays. Align authorisation decisions with the real request path, not just the visible application session.
CIS Controls v8CIS-8 — Audit Log ManagementLog visibility is central to detecting the hidden routing failure described in the article.
Recommendation — Ensure audit logs capture relay-mediated sessions and alert on mismatches between endpoint and network telemetry.
MITRE ATT&CKTA0005 — StealthThe issue creates a stealth-like blind spot where activity occurs outside expected visibility paths.
Recommendation — Map hidden routing blind spots to TA0005 and hunt for sessions that evade normal inspection.

Key terms

  • Relay-Mediated Traffic: Traffic that is routed through an intermediary service before reaching its final destination. In security terms, the relay can preserve privacy or functionality while reducing the fidelity of network inspection, logging and policy enforcement when controls expect a direct endpoint relationship.
  • Visibility gap: A visibility gap is the point where a security team can no longer reliably see who has access to what, or why that access exists. In identity and data governance, it is a control failure because remediation depends on accurate ownership and current entitlement state.
  • Platform-Aware Governance: A governance approach that accounts for behaviour introduced by browsers, operating systems and embedded platform services rather than assuming application traffic will remain directly inspectable. It requires testing how privacy, relay and abstraction layers change the control points available to the enterprise.
  • AI Relay Opacity: A control failure mode where AI-related traffic is technically generated and allowed, but the intermediary routing layer hides enough detail that enterprise controls cannot see the full request path. This weakens monitoring, auditability and policy enforcement without necessarily breaking the user workflow.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
NHIMG Editorial Note
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org