Close the Browser, the AI Agent Keeps Working: The Hidden Risks of Perplexity's Persistent Agents

Perplexity has launched a persistent agent orchestration layer that lets AI agents continue coordinating tasks and accessing systems after the user closes the browser. The official documentation confirms this is intentional design, not a bug. Placed in an enterprise security context, this statement carries far more weight than a product announcement.

The Mismatch Between Agent Execution Time and Human Supervision Time

Traditional enterprise access control is almost entirely built on one default premise: there is a person in the session. Authentication, permission granting, behavior auditing, anomaly alerting—the entire chain is bound to an active user session. Once the session ends, permissions lapse, logs are no longer tied to a specific individual, and alerts lose their context.

Perplexity's persistent agents break precisely this premise. After the user closes the tab, the agent is still making tool calls and reading data, and this entire process falls outside the supervision window that the security model assumes. No session means no alerts tied to an active user and no corresponding audit trail. The agent is not bound by this set of security assumptions, yet security teams assume it is.

This is not a product defect unique to Perplexity but a structural problem common to agent-based products. The difference is that Perplexity has made this "continue executing after the session ends" capability explicit, effectively putting the contradiction on the table.

Why "Sessionless Execution" Is Hard for Existing Systems to Catch

The detection logic of existing security toolchains is largely user behavior analytics (UEBA) and session-level auditing. When an agent operates without a session, these tools see "operations initiated by no one"—either ignored as system tasks or simply missing from the records. The attack surface did not appear out of nowhere; it was always there. Persistent agents have simply turned it from a theoretical scenario into an everyday one.

For security teams, the truly tricky part is the broken chain of accountability. When a data access occurs after the user has gone offline, it is hard to answer in retrospect "who authorized this" and "what was the intent at the time." The stronger the agent's autonomous orchestration capability, the more pronounced this problem becomes: it may chain calls across multiple systems, and each individual log looks normal—only together do they constitute a sensitive sequence of operations.

The discussion on Reddit around this news also centers on the same direction: how teams running agent workloads in enterprises handle the gap between agent execution time and human supervision time, especially for actions triggered after the user disconnects.

User behavior analytics (UEBA) is a class of machine learning-based security analytics technology that builds baseline models from logs such as user accounts, endpoint devices, and network traffic to identify suspicious activity that deviates from normal patterns, such as unusual login times or atypical data access volumes. Its core assumption is that "the acting entity is a known user identity," and all alerts and risk scores are tied to a specific account. When an agent performs operations without an active user session, a UEBA system either classifies it as a system background task because it cannot find an associated entity, or cannot generate meaningful alerts due to the lack of user context. This means UEBA's detection coverage has an inherent blind spot: the autonomous behavior of non-human identities. To close this gap, enterprises need to treat agents as first-class actors and establish independent behavioral baselines for them, rather than continuing to rely on user-centric analytical models.

Realistic Options for Enterprise Adoption

In the short term, expecting vendors to rewrite their entire access control systems is unrealistic. A more pragmatic approach is to add an independent supervision mechanism beyond the agent layer and the session layer. For example, assign a separate identity to the agent so that every tool call is bound to the agent entity rather than the user session; expand the audit target from "user behavior" to "agent behavior"; and impose stricter permission boundaries on actions executed while offline instead of reusing the authorization scope that applied when the user was online.

Another direction is to extend the supervision window from "session period" to "task period." Throughout the full lifecycle of an agent task, whether or not the user is online, there should be an observable execution trail and points for human intervention. This requires the product itself to expose sufficient execution state and enterprises to have corresponding monitoring capabilities. At present, neither side is mature.

Persistent agents represent the direction of product evolution: agents are shifting from "assistants within a session" to "work units that run continuously in the background." If security systems remain stuck on the session assumption, the gap will only widen. Perplexity has made the problem explicit this time; what comes next is how enterprises close the supervision gap.

Non-Human Identity (NHI) management is one of the fastest-growing areas in identity security in recent years, covering API keys, service accounts, machine certificates, and AI agents—identity entities that are not tied to a specific person. Traditional IAM systems typically treat such identities as "service accounts," granting broad static permissions that are rarely rotated, and auditing struggles to trace them back to specific business intent. The significance of assigning independent identities to agents is threefold: first, each tool call by the agent can be bound to the agent entity rather than the user session, so correlatable audit records can still be generated after the user goes offline; second, agent identities can enforce finer-grained permission boundaries and validity period controls, avoiding reuse of the authorization scope that applied when the user was online; third, when multiple agents call each other in a chain, independent identities make it possible to fully reconstruct cross-system call chains. This approach is consistent with the "never trust, always verify" principle of zero trust architecture—except that the object of verification extends from users to agents.