Security Design Behind Perplexity Computer

Perplexity Computer is an autonomous agent that writes and executes code, browses the web, and connects to external services. It runs on top of existing Perplexity infrastructure and inherits the already-completed 2026 SOC 2 Type II attestation, along with SAML SSO, audit logs, and granular admin controls.

Sandbox isolation is built with Firecracker microVMs. Each session has a dedicated Linux kernel, a minimized device model, an isolated filesystem, and an independent network namespace, and is automatically paused and then deleted when idle. Only necessary credentials are injected, and sub-agents use short-lived proxy tokens instead of raw API keys.

The execution environment and storage are separated into different cloud VPCs, and communication occurs only over HTTPS. Connectors can be turned on or off at the organization level; Google and Microsoft integrations use provider authentication flows, while custom remote connectors use OAuth 2.0 or enterprise-managed API key authentication. Remote custom connectors require HTTPS, and file connector data is encrypted both in transit and at rest. Task inputs, outputs, connector data, and sandbox contents are not used for model training, and enterprise file attachments are deleted after 7 days.

Prompt injection defense inherits and extends Comet's four-layer defense architecture and BrowseSafe, a defense system that has also been audited by Trail of Bits. External content is first screened by an ML classifier, and a safe stop is triggered when suspicious signals are detected. The classifier is continuously updated based on bug bounties, red team exercises, and real detection events. Each tool's system prompt treats external content as untrusted, and tool selection and execution are always grounded in the original user query.

Enterprise controls are divided into audit logs, access controls, and billing controls.

• Admins can log user queries, agentic actions, file access, and connector usage, and integrate with Splunk, Azure Sentinel, and Datadog.
• Computer itself can be turned off or opened only to specific members, and third-party connectors such as Gmail, Outlook, Slack, GitHub, Notion, Snowflake, Databricks, and Salesforce can also be controlled at the organization level.
• Allowed models, per-seat credit caps, override allocations, auto-reload thresholds, and monthly limits can all be managed with fine granularity.