Perplexity and UK-based sovereign infrastructure company Valarian announced a partnership on October 20, 2026 to bring Perplexity Computer into institutional infrastructure, including servers controlled by an organization and air-gapped networks isolated from the public internet. The announcement is aimed at organizations that want AI agents to research, analyze records, and complete multi-step work while keeping control over infrastructure, data access, credentials, and network permissions. Read the official Perplexity announcement before making procurement or architecture decisions.

This is not a consumer-facing “turn on private mode” setting, nor does the announcement provide a self-service installation guide. Perplexity says deployments are available by contacting its team. This guide therefore focuses on how to evaluate the offering, what to ask a vendor, and which technical controls to verify before considering a deployment—not on inventing installation commands or assuming every organization is eligible.

What changed on October 20, 2026?

Perplexity says its partnership with Valarian extends Computer to institutional infrastructure, including customer-controlled cloud environments and servers that organizations physically own. Valarian’s ACRA platform provides infrastructure controls and organizes workloads into controlled environments called “enclaves,” with defined access to data, tools, users, credentials, and network connections.

Perplexity Computer coordinates models, tools, memory, and multi-step workflows. In the announced setup, organizations can assign different permissions to different workloads. For example, a research agent might be allowed to access approved public sources, while a legal-work agent might be restricted to a local model and a specific set of case files, with external network connections blocked.

The company also describes air-gapped deployments. These operate with the models, tools, and information available inside the isolated network and do not make live connections to external model APIs or the public web. That distinction is important: air-gapped operation is a specific network and deployment boundary, not just a promise that data is private.

The announcement identifies finance, government, defense, legal, and healthcare as examples of environments where organizations may need more control over sensitive information. It does not mean every workload in those sectors requires an air gap, or that the product automatically satisfies every regulatory or contractual requirement.

What is Perplexity Computer in an enterprise environment?

Perplexity Computer is an AI agent system designed to plan tasks, coordinate models and tools, and execute multi-step workflows. The enterprise announcement extends deployment options beyond ordinary hosted use by placing Computer within infrastructure controlled by an institution.

This matters because enterprise AI risk is not only about the model’s answer. An agent may read internal documents, call tools, process files, or interact with business systems. Security depends on which information the agent can reach, which actions it is authorized to perform, whether network access is permitted, and whether administrators can reconstruct what happened.

The Valarian partnership is presented as a way to apply consistent controls to workloads with different permissions. Perplexity says the environment can run open-weight models such as Nemotron, GLM, Kimi, DeepSeek-R1, and Qwen on an organization’s own infrastructure. Actual model availability, hardware requirements, support, and configuration should be confirmed with the provider for the specific deployment.

For background on a related developer technology, see our practical guide to setting up Perplexity SPACE and running a first sandbox. SPACE is the open-source sandbox platform behind Computer, while this announcement concerns enterprise deployment and governance through Valarian. They are related, but they are not interchangeable products or deployment instructions.

Understand the deployment options before choosing one

“Private AI,” “on-premises AI,” “sovereign AI,” and “air-gapped AI” are often used loosely. They describe different properties, and an organization should ask vendors to define exactly which properties a proposed architecture provides.

1. Customer-controlled cloud

A customer-controlled cloud environment can give an organization control over selected infrastructure, identity, network rules, and deployment configuration. It may still use cloud services, external model APIs, or managed components, depending on the architecture.

Ask which components run inside the customer’s environment, which services remain operated by the provider, what outbound connections are possible, and what telemetry or operational data leaves the environment.

2. Servers physically controlled by the institution

Running workloads on servers owned or physically controlled by an institution may support internal infrastructure and data-handling policies. It also makes the organization responsible for understanding capacity, maintenance, monitoring, physical security, resilience, and operational support boundaries.

Do not assume that a server located in an organization’s data center makes every part of an AI workflow local. Model calls, identity services, updates, logging, support channels, and external tools may have separate network paths. Ask for a complete component and data-flow diagram.

3. Air-gapped network

An air-gapped environment is isolated from live external networks. In the deployment described by Perplexity, the system uses models, tools, and information available within that isolated environment rather than making live connections to external model APIs or the public web.

That can reduce some external data-transfer paths, but it also changes how the environment receives updates, model files, approved datasets, and security patches. Teams should define an approved process for importing artifacts, validating their integrity, and keeping software current without creating an uncontrolled network bridge.

A useful procurement question is: “Which connections are technically impossible, which are blocked by policy, and which are merely discouraged?” Those are different security claims and should be documented separately.

A practical enterprise AI deployment evaluation checklist

Use this checklist as a discovery and procurement aid. It is not a substitute for the official product documentation, a security assessment, legal review, or the organization’s own compliance obligations.

Step 1: Map the data the agent will handle

List the documents, databases, repositories, and business systems the proposed workflow needs. Classify the information by sensitivity and record where it currently resides. Identify whether the task requires personal information, confidential business data, regulated records, source code, or privileged legal material.

For each data source, ask:

  • Who owns the data, and who is allowed to authorize access?
  • Does the agent need read access, write access, or both?
  • Can access be restricted to a particular case, project, customer, or business unit?
  • Are files copied into a separate execution environment, and how long are those copies retained?
  • Can the organization verify that the agent did not access unrelated records?

Avoid starting with a broad request such as “give the agent access to the whole drive.” Define the smallest useful data scope first, then expand only if testing shows that more access is necessary.

Step 2: Define tool permissions and action boundaries

Create an explicit list of tools the workflow may use: document search, file processing, internal APIs, code execution, ticketing systems, or approved web research. For each tool, document which actions are allowed and which require approval.

A market research workflow might need approved access to public sources but no ability to read legal case files. A legal workflow may need case documents but should not have unrestricted internet access or permission to send files to an external service. Different workloads should not inherit the same permissions simply because they share an agent platform.

Ask whether permissions are enforced by the infrastructure, how they are changed, and whether the controls apply to every tool invocation. A natural-language instruction such as “do not open unrelated files” is useful, but it is not a substitute for access control enforced outside the model.

Step 3: Draw the network boundary

Request a diagram showing the components and connections used in the proposed deployment. The diagram should distinguish:

  • Model inference and model hosting
  • Agent orchestration and tool execution
  • Internal file stores and business applications
  • Authentication, authorization, and secrets management
  • Logging, monitoring, and audit storage
  • Software updates and approved artifact imports
  • External model APIs and public web access, if any

For an air-gapped deployment, verify which connections are absent by design and how that claim is tested. For a hybrid environment, identify which tasks can use external models and which must remain local. Do not rely on a product label alone to infer the data path.

Step 4: Verify auditability and incident response

Ask what records administrators can access: tool calls, permission decisions, file access, network events, model selection, task outcomes, and errors. Establish who can inspect those records, how long they are retained, and whether they can be exported into the organization’s monitoring system.

Also agree on an incident process. Security teams should know how to stop a running task, revoke credentials, restrict a workload, preserve relevant evidence, and determine whether data was accessed or transmitted unexpectedly. Verify these controls in a test environment instead of relying only on a vendor presentation.

Audit records should be useful without unnecessarily collecting sensitive prompt content. Define which information is essential for investigation and which should be redacted or excluded from logs.

Step 5: Test isolation and failure behavior

Before production, test with synthetic or approved low-risk data. Include ordinary workflows as well as failure cases:

  • Attempt to access a file outside the agent’s assigned scope.
  • Ask the agent to use an unapproved tool.
  • Include misleading instructions inside a test document.
  • Simulate a denied network connection.
  • Test what happens when a tool fails or returns malformed data.
  • Confirm that a cancelled task stops and that temporary artifacts are handled according to policy.
  • Verify that one workload cannot access another workload’s files, credentials, or output.

Record expected behavior, observed behavior, evidence, and the owner responsible for remediation. A successful demonstration proves that one path worked; it does not establish that every boundary is effective.

Step 6: Confirm operational ownership and support

Clarify who patches the underlying infrastructure, updates models, manages vulnerabilities, handles incidents, and approves configuration changes. For an air-gapped environment, ask how updates and security advisories are delivered and validated.

Also establish requirements for backup, recovery, capacity planning, service availability, and change control. An isolated environment can reduce external connectivity but may introduce operational constraints, including slower updates and a more complex process for integrating approved new tools or models.

Questions to ask Perplexity and Valarian before procurement

The October 20 announcement describes the broad capabilities, but organizations should obtain deployment-specific answers in writing. Use questions such as these in a technical discovery meeting:

  1. Deployment scope: Which components run on customer-controlled infrastructure, and which remain operated by Perplexity or Valarian?
  2. Data flow: What task data, metadata, telemetry, or diagnostic information can leave the environment?
  3. Model options: Which local or open-weight models are supported for the intended workload, and how are model files obtained and updated?
  4. Air-gap definition: Is the proposed environment fully isolated from external networks, and how are updates, support, and artifact imports handled?
  5. Permissions: Can access be restricted by workload, user, dataset, tool, credential, and network destination?
  6. Audit logs: Which events are recorded, how long are they retained, and can records be exported to existing security tools?
  7. Isolation testing: What evidence is available for workload separation, sandbox containment, and enforcement of network restrictions?
  8. Availability and support: What service commitments, incident response procedures, and maintenance responsibilities apply to this deployment?
  9. Compliance evidence: Which independent assessments or documentation can the vendor provide, and what remains the customer’s responsibility?
  10. Commercial terms: What are the licensing, infrastructure, support, and operational costs for the proposed architecture?

These are evaluation questions, not claims that every capability is already included. Ask for written answers tied to the specific product configuration, contract, and deployment model.

Which organizations may benefit most?

Government and defense

A controlled deployment may be relevant when teams need to analyze internal policy, budget, or operational documents without permitting unrestricted access to external networks. The actual environment must match the agency’s security requirements, classification rules, and procurement obligations; the partnership announcement alone does not establish that a deployment is approved for every government workload.

Financial services

Teams may want separate environments for internal transaction or deal documents and public-market research. The architecture should make the boundary explicit: which tasks can access external sources, which remain local, and whether any information can move between the environments.

Law firms and legal departments may evaluate an environment that restricts a matter-specific agent to approved case files and precedents. Access control, retention, confidentiality, auditability, and attorney review remain essential. A private deployment does not automatically establish legal privilege or satisfy every client requirement.

Healthcare

Healthcare organizations may assess whether an agent can summarize authorized records in a controlled environment. Any real deployment must be evaluated against applicable privacy, security, clinical governance, and vendor requirements. The announcement is not a certification that the offering meets every healthcare rule.

Limitations and trade-offs of air-gapped AI

Air-gapped deployment is not automatically the best architecture for every organization. Isolation can reduce live external connections, but it can also limit access to current web information and externally hosted frontier models. Teams may need to maintain local models, import approved updates, and manage dependencies within the isolated environment.

Local models may differ in capability, latency, resource requirements, licensing, and support. Before selecting a model, test it on representative tasks using the organization’s actual quality and safety criteria. Do not assume that an open-weight model will match the performance of a hosted model on every task.

There is also a governance trade-off. An organization may gain greater control over data and network access while taking on more responsibility for infrastructure, patching, observability, and recovery. A sound comparison should include the full operational burden, not just the location of the server.

Finally, air-gapping does not eliminate every risk. Malicious or misleading documents, overly broad internal permissions, vulnerable software, compromised imported artifacts, and unsafe agent actions can still cause problems inside an isolated network. Security needs multiple layers: narrow permissions, isolation, trusted update processes, audit records, human approval, and ongoing testing.

How this differs from Perplexity SPACE

Perplexity open-sourced SPACE, the sandbox platform behind Computer, on October 15, 2026. SPACE gives developers infrastructure for isolated agent execution and a documented local development path. Our Perplexity SPACE setup guide explains how to approach the developer installation and first sandbox.

The October 20 announcement is different in focus. It describes a partnership to deploy Computer on institutional infrastructure using Valarian’s ACRA platform, with controls for sensitive and regulated workloads. Developers evaluating SPACE and enterprises evaluating Computer with Valarian should not assume they share identical deployment procedures, support models, or operational responsibilities.

For a broader view of the risks involved in deploying AI systems, see our guide to the biggest AI challenges in 2026. For agent security in a Microsoft environment, read Microsoft’s new AI agent security controls. These guides address related security and governance issues from different technical angles.

Frequently asked questions

Is Perplexity Computer now available for air-gapped enterprise deployment?

Perplexity’s October 20 announcement says deployments are available starting that day and directs interested organizations to contact its team. It does not provide a public self-service installation process. Organizations should contact Perplexity to confirm eligibility, configuration, requirements, and support.

Does air-gapped mean the AI never connects to the internet?

In the air-gapped deployment described by Perplexity, the workload uses the models, tools, and information available inside the isolated network and does not make live connections to external model APIs or the public web. Confirm the exact network boundary, update process, and any approved import paths for the specific deployment.

Can Perplexity Computer run local models?

The announcement says institutions can run open-weight models such as Nemotron, GLM, Kimi, DeepSeek-R1, and Qwen on their own infrastructure. Confirm which models are supported for the proposed deployment and evaluate their performance, resource needs, licensing, and update process.

Does an on-premises AI deployment automatically meet compliance requirements?

No. Infrastructure control can help organizations implement their security policies, but compliance depends on the full architecture, data flows, access controls, contractual terms, operational practices, and applicable rules. Obtain deployment-specific documentation and perform an independent review.

Is this the same as installing Perplexity SPACE locally?

No. SPACE is an open-source sandbox platform with developer documentation for local deployment. The Valarian announcement concerns bringing Perplexity Computer into institutional infrastructure with enterprise controls. Related technology does not mean the installation paths or service responsibilities are identical.

What should a company do first?

Start by defining the use case, classifying the data, mapping tools and network paths, and documenting required permissions. Then ask Perplexity and Valarian for a deployment-specific architecture and evidence for the controls your security team needs to verify.

Conclusion

Perplexity’s partnership with Valarian points to a more controlled enterprise deployment model for AI agents: Computer can operate inside institutional infrastructure, with workload-specific access rules and air-gapped options for environments that cannot use live external model APIs or the public web.

For organizations considering it, the next step is not to assume the product is automatically compliant or to copy an unverified installation procedure. Instead, define the data boundary, verify the network architecture, test workload isolation, inspect audit capabilities, and confirm operational responsibilities and support in writing.

The central procurement question is simple: can the proposed deployment demonstrate, in the exact environment where it will run, that each AI workload can access only the data, tools, credentials, and network connections it has been authorized to use?

Sources and further reading