Comment nous avons intégré la sécurité dans Computer

Perplexity Computer est un agent autonome qui écrit et exécute du code, navigue sur le Web et se connecte à des services externes pour accomplir des tâches en votre nom.

Il est construit directement sur l'infrastructure existante de Perplexity, qui a obtenu son attestation SOC 2 Type II pour 2026, et hérite des fonctionnalités de sécurité d'entreprise de Perplexity telles que le SSO SAML, les journaux d'audit et les contrôles administratifs granulaires.

L'exécution de code et l'interaction avec des services en direct entraînent de nouvelles exigences. Cet article décrit ce que nous avons développé au-dessus de la base initiale pour continuer à assurer la sécurité de nos utilisateurs : l'isolation par bac à sable, les connecteurs et le traitement des données, la défense contre l'injection de requêtes (prompt injection) et la gouvernance d'entreprise.

Isolation par bac à sable

L'exécution sécurisée de code nécessite une isolation au niveau matériel. Chaque tâche de Computer s'exécute dans un bac à sable microVM Firecracker, imposant un principe de moindre privilège allant au-delà de la sécurité par défaut du système d'exploitation. Chaque microVM démarre son propre noyau Linux dédié avec un modèle de périphérique minimal qui réduit la surface d'attaque.

Chaque bac à sable est isolé selon trois dimensions :

Noyau dédié : Chaque session dispose de sa propre instance de noyau Linux.

Système de fichiers isolé : Chaque VM utilise un système de fichiers isolé qui est réinitialisé à la fin de la session.

Espace de noms réseau privé : Les bacs à sable disposent de leur propre réseau isolé avec des règles de pare-feu dédiées.

Les bacs à sable se mettent automatiquement en pause en cas d'inactivité et sont détruits après une période prolongée. Chaque nouvelle session démarre « propre ». Seules les informations d'identification nécessaires à la tâche en cours sont injectées, et elles sont détruites avec le bac à sable. Les sous-agents utilisent des jetons proxy à durée de vie limitée acheminés via une passerelle authentifiée plutôt que des clés API brutes.

Nous séparons également le stockage des données de l'exécution du code entre les VPC cloud. Cette séparation aide à isoler les données utilisateur stockées de l'environnement d'exécution. Toute communication entre les deux s'effectue via HTTPS chiffré.

Connecteurs et traitement des données

Computer peut se connecter à des services externes tout en limitant la portée des accès et en contrôlant le traitement des données. Les administrateurs peuvent activer ou désactiver les connecteurs pour l'organisation, et les utilisateurs individuels authentifient ensuite les services qu'ils souhaitent utiliser au sein de Computer.

Le chemin de connexion dépend du connecteur. Les intégrations natives telles que Google et Microsoft utilisent des flux d'authentification de fournisseur, tandis que les connecteurs distants personnalisés prennent en charge OAuth 2.0 ou l'authentification par clé API gérée par l'entreprise. Tous les types de connecteurs sont conçus pour ne transmettre que les données minimales requises pour accomplir la tâche. Le traitement des données suit le même modèle de contrôle. Les connecteurs personnalisés distants doivent utiliser HTTPS, et les données des connecteurs de fichiers sont chiffrées en transit et au repos. Les données d'entreprise, telles que les entrées de tâche, les sorties, les données de connecteur et le contenu des bacs à sable, ne sont pas utilisées pour l'entraînement des modèles. Les pièces jointes d'entreprise sont supprimées après 7 jours.

Défense contre l'injection de requêtes (prompt injection)

Un agent qui navigue sur le Web et lit du contenu externe est exposé aux attaques par injection de requêtes. Computer hérite et étend les défenses que nous avions initialement conçues pour Comet, notamment notre architecture de défense à quatre couches et BrowseSafe, notre modèle de détection open source pour la sécurité des agents de navigation. Ces défenses ont été auditées par Trail of Bits.

Des classificateurs ML analysent le contenu récupéré auprès de sources externes avant que Computer n'agisse dessus. Le système de détection s'exécute en parallèle avec le pipeline de raisonnement de l'agent et déclenche un arrêt de sécurité lorsqu'un contenu suspect est détecté. Les classificateurs sont continuellement mis à jour en fonction des résultats de notre programme de bug bounty, des exercices d'équipes rouges (red team) et des événements de détection réels.

Au-delà de la classification, le prompt système de chaque outil inclut des garde-fous explicites. Le contenu externe est marqué comme non fiable, et le système fait continuellement référence à la requête utilisateur d'origine lors de la sélection et de l'exécution des outils.

Computer applique des mesures de protection supplémentaires lors du traitement de contenu non fiable, y compris une gestion plus stricte des prompts et des protections au niveau du modèle. Si vous souhaitez en savoir plus, nous avons lié les recherches et évaluations de sécurité pertinentes ci-dessus.

Contrôles d'entreprise

Pour les organisations utilisant Perplexity Enterprise, les administrateurs bénéficient d'une gouvernance supplémentaire sur le fonctionnement de Computer :

Journaux d'audit : Les administrateurs peuvent enregistrer des événements clés tels que les requêtes des utilisateurs, les actions des agents, l'accès aux fichiers et l'utilisation des connecteurs. Les journaux s'intègrent aux principaux SIEM, notamment Splunk, Azure Sentinel et Datadog, afin que les équipes de sécurité puissent surveiller l'activité de Computer parallèlement à la télémétrie de l'infrastructure existante.

Contrôles d'accès : Les administrateurs peuvent désactiver Computer entièrement ou l'activer uniquement pour des membres spécifiques. Les connecteurs tiers, notamment Gmail, Outlook, Slack, GitHub, Notion, Snowflake, Databricks et Salesforce, peuvent chacun être activés ou désactivés au niveau de l'organisation. Les administrateurs peuvent également restreindre les modèles que Computer est autorisé à utiliser.

Contrôles de facturation : Les administrateurs peuvent définir des plafonds de crédits par poste, remplacer les allocations pour les utilisateurs individuels, configurer des seuils de rechargement automatique et des limites mensuelles, ou choisir de ne pas ajouter de crédits au-delà de l'allocation par poste incluse.

Pour plus de détails, visitez notre Trust Center ou consultez la documentation Computer for Enterprise.