Enforce corporate AI policy on unmanaged BYOD laptops without device enrollment, endpoint agents, or trust-based policy. Here’s the architecture that works.
Key takeaways
- The BYOD AI problem isn’t about the device — it’s about what carries the corporate policy when the device, the network, and the browser all belong to the employee.
- Conditional Access, endpoint DLP, and network filtering each solve real problems, but none of them enforces cleanly inside an authenticated AI session on an unmanaged laptop.
- A working middle ground exists: enforce on the corporate session itself, delivered to the personal device through a shortcut, with nothing installed on the machine.
By Yaniv Levi, Solution Architect, Red Access
The AI tool is approved. The policy is written. And now someone has opened the corporate ChatGPT account from a laptop the company has never seen. Enroll the personal device? The employee says no. Trust the policy alone? Then it isn’t a control. Block at the corporate network edge? That works only while they’re on the corporate wire — and BYOD, by definition, isn’t.
The problem is worth stating precisely, because the usual framing hides it. The corporate AI policy is defined at the organization, but enforcement today depends on something running on the device, something running on the network, or a specific browser the user must open. None of the three exists when the employee is at home, on their own machine, on their own Wi-Fi, in the browser they already use. AI sharpens the stakes: corporate ChatGPT, Copilot, and Gemini accounts sit next to personal ones on the same device, prompt-level data leaves the perimeter in seconds, and the identity boundary between “work AI” and “personal AI” is a single tab away. The right question isn’t “what do we install and where.” It’s what carries the policy.
Why the usual three answers each solve a different problem
Conditional Access, endpoint DLP, and network filtering each solve something real. What they don’t solve — cleanly, on an unmanaged device — is enforcement inside the session after the user is authenticated.
Conditional Access primarily governs the conditions under which access is granted. Microsoft can extend that into in-session enforcement through Defender for Cloud Apps, and further with Purview DLP in Edge for Business, which can now govern paste, download, and label handling on unmanaged devices — provided the user works inside an Edge for Business work profile with the right Conditional Access App Control policies bound to it. That’s a genuine middle path, and worth taking seriously. It’s also a specific architectural bet: policy is attached to a Microsoft-controlled browser context, and access to protected corporate apps has to happen inside it.
Endpoint DLP — Purview’s classic path — still requires the device to be onboarded through Intune, JAMF, GPO, or a local script. That’s a non-starter on a laptop the company doesn’t own. Network filtering, whether at the gateway or via DNS, applies only where the enforcement path reaches. On a BYOD laptop at home, if you’re unwilling to install or configure anything on the device, you can’t assume your network enforcement follows the user.
None of this is a failure of those tools. Each was built to solve a different problem. The BYOD AI case sits between them.
Enforce on the session, not the device
Shift the unit of enforcement. A corporate session — the work session that opens a sanctioned SaaS or AI tool — can carry policy with it, independent of whose machine it opens on. The question becomes how to deliver that session to an unmanaged device without touching anything else on it.
The framing isn’t unique. Cyberhaven’s standalone browser extension, released for contractor and BYOD use, tries to solve the same problem by shipping a browser-deployed agent that runs without an endpoint sensor. Nightfall and Harmonic use browser extensions for browser-based AI coverage, with endpoint agents extending protection off the browser. All three reduce what has to live on the device. Something still has to be installed there.
The alternative is to install nothing on the personal device at all — the corporate session itself is routed through a session inspection layer, delivered via a shortcut the user opens in Chrome or Edge. Sessions initiated through the shortcut are inspected at the session layer. Everything else on the laptop — personal browsing, personal accounts, other browser instances — stays outside scope.
What this looks like on an unmanaged laptop
The user receives a shortcut and opens it in Chrome or Edge. The corporate ChatGPT session, the M365 tenant, the Salesforce instance — all opened through it — run under the AI and DLP policies the security team defined centrally. Prompts are inspected before they leave. Sensitive fields can be masked. Extension behavior inside the corporate session can be governed.
Nothing runs on the personal device. Nothing observes the user’s personal browsing. The security team sees the sessions opened through the corporate shortcut and nothing else — which is exactly what makes the model acceptable to the employee and defensible to counsel. Red Access delivers this model through Share-Link.
The honest limits
If the user opens ChatGPT in a browser instance outside the shortcut, that session isn’t inspected. If they open it in a browser the shortcut doesn’t support, same. The scope is deliberate — it’s what preserves personal privacy — but it’s a real gap on paper.
The gap can be closed at the SaaS layer. Bind access to the corporate application to the session’s egress IP range through Conditional Access, and the corporate account becomes reachable only through the shortcut. The user can still open ChatGPT in Firefox on their personal Google account. They cannot open the corporate ChatGPT account there.
For more on where enterprise browsers fall short on the BYOD and contractor case, see What Enterprise Browsers Can’t See.
Five questions to bring to your architecture
Ask them of what you already run. If you can answer yes to all five, the BYOD AI case is covered. If you can’t, it isn’t — and adding another endpoint tool won’t fix it.
Does your AI policy apply when the user is on a network you don’t control? Does it apply when the user is in a browser you didn’t push? Does it apply without installing anything on the personal device? Does the corporate SaaS account refuse to open outside the enforcement path? Can the employee still use their personal life on the same machine, unwatched?
The BYOD question was never “manage the device or accept the risk.” It was, and is, what carries the policy.
