Perplexity's Computer agent now runs its model, its planning and its file processing entirely on an Apple-silicon Mac, with no inference request leaving the machine and no credit charged for a local task. That is a real answer to data residency and almost no answer at all to exfiltration, because the agent still reads Mail and Messages with permission, still sits on a disk full of your files, and still holds an approved route to the cloud in the same application. Moving inference inside the boundary removed the provider's request log. It did not remove any of the three conditions an attacker needs.
At a glance
Announced on 20 October 2026. Everything in the table is from Perplexity's own statements or contemporaneous reporting of them; no independent testing existed at the time of writing.
| Capability | Runs on the Mac | Needs the cloud | What gates it |
|---|---|---|---|
| Model inference and planning | Yes | No | Nothing — it is the default in this mode |
| File processing | Yes | Only if you approve | A user approval, per Perplexity |
| Code and tool execution | Yes, in isolated sandboxes | No | Controlled access to files and connected apps |
| Native Mac apps | Notes, Messages, Mail, Numbers | No | Per-app permission from the user |
| Current information, browser, connectors | No | Yes | A user authorisation in the same app |
The mode is for Pro, Max and Enterprise subscribers. Perplexity recommends 36 GB or more of unified memory, which is a recommendation rather than a documented hard floor — the older help-centre page for Personal Computer, the May 2026 feature that first gave Computer access to local files and native Mac apps, lists a different bar of 24 GB or more. Local tasks are stated not to consume Computer credits, and Hybrid Compute remains available in the same application. The local model is described as PPLX Pro, a Perplexity post-trained version of Qwen; coverage does not agree on the base version, with Qwen 3.6 and Qwen 3.8 both named, so treat that detail as unresolved.
What this genuinely buys, and it is not small
Three things improve, concretely, and they are the reasons to want this.
The provider's request log stops existing. Every prompt an agent sends to a hosted model is a disclosure to a third party that may retain the payload for abuse monitoring, and no amount of post-hoc redaction undoes it — the data left when the request left. This is the structural problem confidential inference exists to address and the one that blocks agent deployments in regulated settings. Running the model on the device does not mitigate that disclosure; it eliminates the act. For data residency and sovereignty questions, "the bytes never left the laptop" is the strongest answer available, and it is much stronger than a contractual zero-retention commitment.
The meter stops. Local tasks are stated not to draw down Computer credits, which changes the economics of the long, exploratory, low-value task — the one you do not run on a metered agent because the expected value does not clear the cost. A free marginal task is a different product from a cheap one, and small and local models has the quality side of that trade: the on-device model is weaker, and for a large class of file-wrangling work that is simply irrelevant.
It works with no network. An agent that functions offline is an agent that functions on a plane, in a facility with no outbound access, and during an incident where you have cut the network precisely because you do not trust what is on the machine. Air-gapped agent deployments covers the serious version of this.
Those are real and they should not be minimised. The rest of this piece is about what did not change, because the marketing frame — local means private — invites exactly one wrong conclusion.
The three conditions are all still on the laptop
Exfiltration by a prompt-injected agent needs three things at once: exposure to content an attacker controls, access to data worth stealing, and a way to send it somewhere. That combination is the lethal trifecta, and the useful property of the framing is that removing any single leg is sufficient. Check the three against this configuration.
Untrusted input. With permission, the agent reads Mail and Messages. Those are the two channels on a personal device where the content is authored by whoever decided to contact you, which makes them the canonical source of injected instructions — prompt injection does not care that the model inferring over the text is local. If anything the local case is worse on this axis, because the whole point of granting Mail access is that the agent acts on mail you have not read yet.
Private data. The agent's reason for existing in this mode is to work with local files. The data and the untrusted content are now inside the same context window on the same machine, which is the condition context taint tracking is about and which no amount of local compute changes.
Egress. This is the leg people assume local mode removes, and it does not. The same application retains an authorised cloud path for tasks needing current information, browser use or connectors, and browser use in particular is a general-purpose outbound channel: a URL with data in its query string is an exfiltration primitive, which is why egress control for agents treats the browser as the hardest tool to contain. The gate on that path is a user approval, and a user approving "yes, look this up online" is not evaluating whether the lookup encodes the contents of a file.
So the honest summary is narrower than the headline: local inference removes the provider from the threat model and leaves the attacker exactly where they were. Those are different parties, and conflating them is the mistake this release makes easy.
The instruments moved with the model
This is the part that gets discovered late, usually during an incident. Almost every operational control an organisation has over an agent is implemented at the service: the request log that tells you what it was asked, the API key you revoke to stop it, the network policy that decides what it can reach, the per-call trace you reconstruct a timeline from. Move inference onto the endpoint and all four of those stop being available in the place your tooling looks. Agent artifacts on the endpoint is the full inventory of what is suddenly on the laptop instead, and detecting agent compromise is the capability that gets quietly harder.
Two controls get more important in exchange, and they are both endpoint controls. Device management is now your main lever — whether the app is installed, which version, what it may reach on the network — and per-app consent becomes the single most consequential security decision in the product, made by a user in a dialog, once, probably while trying to get something else done. Permission grants and revocation is the design problem that creates; ambient authority is the name for what you have granted when the answer is "yes, all of Mail, indefinitely".
The sandboxing claim deserves credit here and also a boundary. Perplexity states that code and tool execution happen in isolated sandboxes with controlled access to files and connected apps, which is the right architecture and is more than many desktop agents do — sandboxing and code execution covers why. But a sandbox around the code execution step is not a sandbox around the agent: the agent's granted access to Mail, Messages and your files is the thing it is supposed to use, so the dangerous path does not run through the sandbox at all. The sandbox contains the tool, not the authority.
What to actually do about it
For an individual running this on their own machine, the leverage is almost entirely in the first column of the trifecta diagram, because it is the only one you can cut without giving up the product:
- Do not grant Mail and Messages unless the task needs them. This is the single highest-value decision available, and it is the one the permission dialog makes feel routine. An agent with your files and the internet but no inbox is a far less interesting target than one with all three.
- Treat the cloud approval as the egress decision it is. When the agent asks to go online mid-task, the question is not "do I mind a web search" but "what is it about to send". If the task began by reading something you did not write, the answer should usually be no.
- Separate the profiles. Use local mode for the work that justified local mode — files you would not send to a provider — and do that work in sessions that have no mail access and no cloud grant. Mixing a private-file session with an inbox session is how the three legs end up in one context.
For an IT or security team, the change is that your policy surface is now the fleet rather than the gateway:
- Decide the app's network reach at the device. If the local mode's selling point is that nothing leaves, enforce that instead of trusting it: the outbound path is now a host firewall and MDM question, not a proxy rule.
- Inventory the grants, not the installs. Knowing the app is present tells you little; knowing which users granted Mail tells you where your exposure is. Agent inventory and registry and access reviews for agent credentials both need to extend to endpoint grants.
- Assume you will have no trace. Plan the incident response for the case where the only evidence is on a laptop you may not get back for a week. That constraint should influence which data you are willing to have on devices running an agent at all, which is the blast radius question in its endpoint form.
- Keep the memory bar in the rollout plan. A 36 GB recommendation means a large part of a typical fleet cannot run this mode, so in practice you are governing two configurations — local and hybrid — rather than replacing one with the other. On-device agent architecture covers the hybrid split properly.
And one framing worth keeping: this is a good release. An agent whose inference never leaves the device solves a problem that has blocked real deployments, and nobody should talk themselves out of it on the strength of the argument above. The argument is only that it solves the problem it solves. If your reason for wanting local was that the provider should not see your data, you got exactly what you wanted. If your reason was that the agent should not be able to leak your data, you did not buy that, and the thing that would buy it is a per-task grant boundary — no mail and files and network in the same session — which is still yours to build. Agents on developer workstations is the same problem one profession over.
FAQ
Does running the model locally make the agent safe from prompt injection?
No. Where inference happens has no bearing on whether the text being read contains instructions. An agent granted Mail and Messages is reading content authored by whoever contacted you, and local inference leaves that unchanged.
If nothing leaves the Mac, how could data be exfiltrated?
Because something still can leave, on approval. The same app keeps an authorised cloud route for current information, browser use and connectors. A browser fetch is a general-purpose outbound channel, and a user approving a lookup is not inspecting what the lookup encodes.
What hardware does the local mode need?
Perplexity recommends 36 GB or more of unified memory on an Apple-silicon Mac for this mode. It is stated as a recommendation; the older Personal Computer help page lists 24 GB or more for local models, so the two figures are not a single documented minimum.
Which model runs on the device?
Perplexity describes it as PPLX Pro, its own post-trained version of Qwen. Reporting disagrees on the base version — both Qwen 3.6 and Qwen 3.8 appear — so the exact lineage is unresolved as of 21 October 2026.
Do local tasks cost anything?
Local tasks are stated not to consume Computer credits, which is the main economic change: the marginal cost of an exploratory on-device task goes to roughly zero. Cloud-assisted tasks in the same app still run under the normal metering.
What does a security team lose when inference moves to the endpoint?
The provider request log, a central kill switch, gateway-level egress control, and a centrally collected per-call audit trail. Device management and per-app consent become the controls that remain, and both live on the endpoint rather than in the service.
Further reading
On this wiki:
- The lethal trifecta — the three conditions, and why cutting one is enough.
- Confidential inference — the problem local execution actually solves.
- Egress control for agents — why the browser is the hardest channel to close.
- Agent artifacts on the endpoint — what is on the laptop once the agent is.
- On-device agent architecture — the hybrid split, done deliberately.
- Small and local models — the quality side of the trade.
- Ambient authority — what a standing per-app grant really is.