Cloud-First vs. Desktop-First: The Security Choice in AI Assistants

This article first appeared on Todd Wilkinson's LinkedIn. 

I've been spending a lot of time with both Perplexity and Claude lately, and there's a fascinating implementation divergence happening I think deserves more attention. Following on the work that Aaron Pritz has been doing in his drive for more AI innovation we have been exploring more around which tools and how to secure our own work and environments.

This particular topic is less about AI and more about basic deployment approaches especially for those of us who have to think about enterprise security implications. I also want to say up front: this is not an ad for or against Perplexity or Claude; rather my open-air thoughts on these diverging approaches between to AI Approaches. To be clear, I use them both and find good value in them.

Two Different Philosophies, Two Different Attack Surfaces

Here’s what’s interesting: Perplexity is building security and cloud containment into their core model, similar to an Island browser approach. With Perplexity Computer, access and integrations to cloud services are centrally managed in their infrastructure. Everything runs in an isolated sandbox. The blast radius of any failure is strictly contained to their environment, not your endpoint.

Claude and several other AI assistants, on the other hand, are taking the desktop-first route. All those powerful integrations? They are running directly on your local machine with many times full system privileges. For each user, you are essentially creating backdoors into your network that bypass many traditional enterprise controls. Yes the enterprise licensing levels do add options for further containment but generally speaking your desktop is now the attack service in Claude vs Perplexity where the model is outside your core infrastructure.

Neither Approach is Wrong—But the Implications are Very Different

Let me be clear: Claude and Perplexity are both fantastic products moving at lightning speed. This isn't about one being better than the other—it's about understanding what you're signing up for.

For small offices, dev teams, power users or organizations where everyone understands these implications, Claude’s “desktop approach” can offer incredible flexibility and power.

If, and this is a big if, you're comfortable with local agent execution, and can layer in the appropriate endpoint security controls (e.g. no sensitive APIs on the file system, data management, logging, and controlled access both internally and remotely)... you can be in good shape, security wise.

Problem is, even large enterprises (to say nothing of small teams) struggle to do all of these items at all or well, because it implies you have a robust endpoint management system in place, which isn’t cheap and takes effort to customize for these locally hosted type of solutions.

Here’s the thing keeping me up at night: if we’re being realistic with Claude's architecture and how employees are using it, you’re likely going to have users moving sensitive credentials in cleartext to the desktop. You can bet money they’ll turn on remote access/control. And did that API key really have super narrow access?

(This might cause me to be up late, clutching my laptop, worrying about an ever-expanding list of concerning behaviors...)

Long story short, as the Claude-led ecosystem grows, you're going to need to beef up your endpoint security stack. EDR (endpoint detection and response) becomes more critical. DLP (data loss prevention) becomes more critical. Zero trust becomes even more critical. Yes, Claude has some security capabilities, like sandboxing and keychain usage for more secure key storage, but it’s not really the path many will take in practice.

This isn’t theoretical. Recent vulnerabilities like the zero-click RCE discovered in Claude Desktop Extensions (where a malicious calendar event could trigger arbitrary code execution) aren't surprising one offs, they are the predictable result of unsandboxed local execution with full system privileges and trust.

I am running both Claude Enterprise and Perplexity Enterprise in a dual experiments (note: I am not going to include my Nema/OpenClaw work in this thought train. That is a broader discussion for later). They are both fantastic tools, I would put Perplexity at an edge for security controls, sharing a bit more consistent experience. Claude has many other controls that enterprise teams need to think through, and that will drive up management costs. From credential vault to endpoint firewalls and other monitoring tools that are needed it comes with other costs. That said in my own experience I had a perplexity Computer break out and put data in a public Pastebin link without asking. It was nonconsequential, but that example happened quickly and somewhat unpredictable given the ask I had made in my prompt workflow. Perplexity has been faster to spin up, share work and integrate into my corporate workflows faster, where Claude requires more oversight.

The Endpoint-as-Throwaway Philosophy

My general approach for the majority of enterprise users is simple: make the endpoint disposable and easily replaceable.

If your architecture assumes the endpoint is compromised, you can build very different security boundaries. Make the endpoints disposable, and you can take measures to keep sensitive information off it and ensure they aren’t critical to your operations.

TL;DR: With cloud-first AI tools like Perplexity, it will likely be easier (at least by default) to maintain your security guardrails and keep focus with a cloud first approach. With desktop-first tools, you need to invest heavily in endpoint hardening, monitoring, and rapid recovery capabilities.[BH1]

What This Means for Enterprise Adoption

If you're evaluating these platforms for enterprise deployment, here are the key considerations:

Perplexity/Cloud-First:

• Lower endpoint risk
• More secure by default (well we assume for the purposes of this discussion)
• Easier compliance story (a few places vs many distinct locations to manage)
• Potentially slower feature velocity
• Managed integrations (perhaps slower to deploy up front, but more controlled)

Claude/Desktop-First:

• Maximum flexibility
• Rapid innovation
• Local integrations (perhaps faster to deploy up front)
• Requires mature endpoint security program
• Increased need for endpoint DLP controls
• Need for improved and clear user training on data handling

Depending on your background, you might be sensing another current here. So, let’s be honest: security professionals typically talk about API keys, vaulting, and sensitive data handling with developers and IT staff. Now, this conversation is going to have to include executives and other non-dev-savvy leaders who are starting to use tools like this. The language we use and the audience we speak to is going to have to change even more.

The Bottom Line

Both approaches have merit. The question isn't a clear-cut "which is better,” it’s “what model matches your organization's security maturity, risk appetite and ability to execute?"

• For regulated industries, high-value targets, or organizations with sensitive IP, the cloud-first isolation model might be the better compliant path forward.
• For engineering teams, startups, and technically sophisticated organizations with robust endpoint security, desktop-first might offer the speed and flexibility you need.

Just make sure you're making an informed choice about which model you're adopting, because the security implications are profound and the controls you need to layer on are very different.

My fear is that we have large deployments of new tools containing sensitive data and access keys stored in the clear, on endpoints that are granting remote access from locations and devices that you no longer control.

Did I mention this keeps me up at night?

Key Takeaways for Security Leaders

1. Understand the architectural paradigm before deployment. Cloud sandbox vs. local execution may fundamentally change how you have to focus your resources and how you secure against threats.
2. Desktop-first AI requires significant endpoint security investment (enhanced EDR, robust DLP, comprehensive monitoring and probably some more user friendly vaulting tools).
3. Cloud-first AI introduces data governance questions about what's processed in vendor infrastructure.
4. The models can coexist. Use cloud-first for general users, desktop-first for specialized technical teams with appropriate controls. Or, consider putting these devices in dedicated VMs (virtual machines) or containers, and segment them off from your more critical networks/resources. Let's be blunt that degrades the experience for both solutions but might be an option for some.
5. The "endpoint-as-throwaway" philosophy is challenged if the desktop AI deployments integrations are all on the desktop. You now have a larger base that you treat as developers.

What's your organization's approach? Have you run into these tradeoffs as you scale AI adoption or like many I presume are we ahead of our ski’s on this one as well learn while running?