Sécurité

Pi est un agent de codage local. Il s'exécute avec les autorisations du compte d'utilisateur qui le démarre et traite les fichiers accessibles en écriture par cet utilisateur comme à l'intérieur de la même limite de confiance locale.

La confiance du projet contrôle si pi charge les paramètres, ressources, packages et extensions locaux du projet. Ce n'est pas un sandbox et cela ne limite pas ce que le modèle peut demander aux outils de faire après avoir commencé à travailler dans un répertoire.

Pi considère qu'un projet dispose de ressources qui nécessitent de la confiance lorsqu'il en trouve dans le répertoire de travail actuel:

• .pi/settings.json
• .pi/extensions, .pi/skills, .pi/prompts ou .pi/themes
• .pi/SYSTEM.md ou .pi/APPEND_SYSTEM.md
• projet .agents/skills dans le répertoire courant ou un répertoire ancêtre

Un simple répertoire .pi ne compte pas comme une ressource de projet nécessitant une confiance.

Lorsqu'une session interactive démarre dans un projet avec des ressources qui nécessitent de la confiance et aucune décision enregistrée pour le répertoire actuel ou un répertoire parent, pi suit defaultProjectTrust des paramètres globaux. La valeur par défaut est "ask", qui demande s'il faut faire confiance au projet lorsque l'interface utilisateur est disponible. Les décisions enregistrées sont stockées par répertoire canonique dans ~/.pi/agent/trust.json, et la décision enregistrée la plus proche sur le chemin actuel ou parent s'applique avant la décision globale par défaut.

Faire confiance à un projet permet à pi de charger les ressources du projet qui nécessitent une confiance, notamment:

• .pi/settings.json
• .pi ressources telles que les extensions, les compétences, prompt templates, les thèmes et les fichiers d'invite système
• packages de projet manquants configurés via les paramètres du projet
• extensions locales du projet et extensions gérées par les packages de projet

Le déclin de la confiance ignore les ressources protégées. Les fichiers de contexte tels que AGENTS.override.md, AGENTS.md et CLAUDE.md sont chargés quelle que soit l'approbation du projet, sauf si le chargement du contexte est désactivé. Avant que la confiance ne soit résolue, pi ne charge que les extensions context files, utilisateur/globales et CLI -e. Les extensions utilisateur/global et CLI peuvent gérer l'événement project_trust; la première extension qui renvoie une décision oui/non est propriétaire de la décision.

Les modes non interactifs (-p, --mode json et --mode rpc) n'affichent pas d'invite de confiance. Sans décision de confiance enregistrée applicable, defaultProjectTrust: "ask" et "never" ignorent ces ressources, tandis que "always" leur fait confiance. Utilisez --approve/-a ou --no-approve/-na pour remplacer la confiance du projet pour une exécution.

Pi n'inclut pas de sandbox intégré. Les outils intégrés peuvent lire des fichiers, écrire des fichiers, modifier des fichiers et exécuter des commandes shell avec les autorisations du processus pi. Extensions sont des modules TypeScript qui s'exécutent avec les mêmes autorisations. Les installations de packages, les commandes shell, les serveurs de langage, les commandes de test et autres outils de développement se comportent comme des processus locaux ordinaires.

C'est intentionnel. Pi est conçu pour fonctionner sur des arborescences sources locales, invoquer des chaînes d'outils de projet et s'intégrer à l'environnement de développement existant de l'utilisateur. Un sandbox partiel en cours serait facile à comprendre comme une limite de sécurité tout en dépendant du shell hôte, du système de fichiers, des gestionnaires de packages, des informations d'identification et du code d'extension. La véritable isolation doit provenir du système d’exploitation ou d’une frontière virtualisation/conteneur.

La confiance dans le projet n'est qu'une protection contre le chargement des entrées. Cela empêche un référentiel de modifier silencieusement les paramètres ou les extensions de pi avant que vous ne l'approuviez. Il ne sécurise pas le code non fiable, les invites non fiables ou la sortie de modèle non fiable. L'injection rapide à partir des fichiers du référentiel, des commentaires, de la documentation, de context files ou de la sortie de build est un risque attendu pour l'agent local et ne peut pas être évitée de manière fiable par pi.

Pour les référentiels non fiables, le code généré que vous n'avez pas l'intention de surveiller de près ou l'automatisation sans surveillance, exécutez pi dans un environnement confiné. Utilisez un conteneur, une VM, une micro-VM, un sandbox distant ou un sandbox contrôlé par une stratégie avec uniquement les fichiers et les informations d'identification requis pour la tâche.

Les modèles courants sont documentés dans Containerization:

• exécuter l'ensemble du processus pi dans un conteneur/sandbox
• exécutez l'hôte pi tout en acheminant l'exécution de l'outil intégré dans une micro-VM Gondolin
• monter uniquement les chemins d'espace de travail auxquels l'agent doit accéder
• évitez de monter l'hôte ~/.pi/agent à moins que le conteneur ne doive accéder aux sessions, aux paramètres et aux informations d'identification de l'hôte
• passez le minimum de API key requis ou utilisez des informations d'identification de courte durée
• restreindre l'accès au réseau lorsque la tâche n'en a pas besoin
• examiner les différences et les sorties avant de recopier les résultats vers des systèmes fiables

Si vous montez en liaison un espace de travail hôte en lecture/écriture, les écritures depuis l'intérieur du conteneur ou de la VM peuvent toujours modifier les fichiers hôte. Utilisez des montages en lecture seule ou copiez des fichiers vers et depuis le sandbox lorsque vous avez besoin d'une protection plus renforcée contre les écritures involontaires.

Pour signaler un problème de sécurité, suivez le référentiel Security Policy. N'ouvrez pas de problème public pour les rapports sensibles en matière de sécurité.

Le comportement attendu de l'agent local, l'absence de sandbox intégré, l'injection rapide de contenu non fiable et le comportement des extensions ou compétences installées par l'utilisateur sont généralement en dehors des limites de sécurité, à moins que le rapport ne démontre un véritable contournement des limites de privilèges ou montre comment pi accorde un accès que l'utilisateur local n'avait pas déjà.