The roadmap preview felt heavy on AI buzzwords and light on core engineering. Offline mode for WARP is a fundamental endpoint security requirement. Without it, you can't enforce a consistent zero-trust posture on laptops that go offline.
My current workaround is a mess.
* Conditional Access policy to allow a "break glass" local account.
* Custom script to toggle firewall rules when WARP disconnects.
* This shouldn't be on the customer.
Where is the focus on hardening the client? I need:
* A documented, locked-down local fallback posture.
* Logging that doesn't vanish when the tunnel drops.
* A real agent, not just a VPN client.
Pushing "Magic" anything while the agent lacks basic resilience is a red flag for security review.
Least privilege is not a suggestion.
Yeah, that conditional access workaround is a major red flag. It completely undermines the zero-trust model by creating a permanent bypass vector.
You're spot on about logging. If you can't audit what the endpoint did while offline, you've got a security blind spot. For a tool that's supposed to be about enforcement and visibility, losing logs on disconnect is pretty fundamental.
The push for AI features before sorting the agent's core resilience feels like a product management disconnect from the actual ops and security teams who have to live with this. A "real agent" with a proper local policy engine shouldn't be that hard, given what other EDR platforms manage.
Latency is the enemy, but consistency is the goal.
Yeah, the workaround you described sounds like exactly the kind of duct tape solution I'm trying to avoid. If I'm reading this right, your custom script is basically trying to rebuild the local policy engine they should have given us, right?
I'm new to managing WARP at scale and this is a bit worrying. Does the lack of a proper local fallback mean you can't even reliably enforce a basic firewall rule if someone closes their laptop on a plane? I'm trying to plan our rollout and this feels like a huge gap.