Sicherheit

Pi ist ein lokaler Codierungsagent. Es wird mit den Berechtigungen des Benutzerkontos ausgeführt, das es startet, und es behandelt Dateien, auf die dieser Benutzer schreiben kann, als innerhalb derselben lokalen Vertrauensgrenze.

Die Projektvertrauenswürdigkeit steuert, ob Pi projektlokale Einstellungen, Ressourcen, Pakete und Erweiterungen lädt. Es ist kein sandbox und es schränkt nicht ein, was das Modell von Tools verlangen kann, nachdem Sie mit der Arbeit in einem Verzeichnis begonnen haben.

Pi betrachtet ein Projekt als Ressourcen, die Vertrauen erfordern, wenn es diese im aktuellen Arbeitsverzeichnis findet:

• .pi/settings.json
• .pi/extensions, .pi/skills, .pi/prompts oder .pi/themes
• .pi/SYSTEM.md oder .pi/APPEND_SYSTEM.md
• Projekt .agents/skills im aktuellen Verzeichnis oder einem Vorgängerverzeichnis

Ein leeres .pi-Verzeichnis zählt nicht als Projektressource, die Vertrauen erfordert.

Wenn eine interaktive Sitzung in einem Projekt mit Ressourcen beginnt, die Vertrauen und keine gespeicherte Entscheidung für das aktuelle Verzeichnis oder ein übergeordnetes Verzeichnis erfordern, folgt pi defaultProjectTrust aus den globalen Einstellungen. Der Standardwert ist "ask" und fragt, ob dem Projekt vertraut werden soll, wenn die Benutzeroberfläche verfügbar ist. Gespeicherte Entscheidungen werden nach kanonischem Verzeichnis in ~/.pi/agent/trust.json gespeichert, und die nächstgelegene gespeicherte Entscheidung im aktuellen oder übergeordneten Pfad gilt vor dem globalen Standard.

Durch das Vertrauen in ein Projekt kann Pi Projektressourcen laden, die Vertrauen erfordern, einschließlich:

• .pi/settings.json
• .pi Ressourcen wie Erweiterungen, Fähigkeiten, prompt templates, Themen und Systemaufforderungsdateien
• Fehlende Projektpakete, die über die Projekteinstellungen konfiguriert wurden
• Projektlokale Erweiterungen und projektpaketverwaltete Erweiterungen

Sinkendes Vertrauen lässt geschützte Ressourcen überspringen. Kontextdateien wie AGENTS.override.md, AGENTS.md und CLAUDE.md werden unabhängig von der Projektvertrauensstellung geladen, es sei denn, das Laden von Kontexten ist deaktiviert. Bevor die Vertrauensstellung aufgelöst wird, lädt pi nur context files, Benutzer-/globale Erweiterungen und CLI -e-Erweiterungen. Benutzer-/globale und CLI-Erweiterungen können das project_trust-Ereignis verarbeiten; Die erste Erweiterung, die eine Ja/Nein-Entscheidung zurückgibt, besitzt die Entscheidung.

In den nicht interaktiven Modi (-p, --mode json und --mode rpc) wird keine Vertrauensaufforderung angezeigt. Ohne eine anwendbare gespeicherte Vertrauensentscheidung ignorieren defaultProjectTrust: "ask" und "never" solche Ressourcen, während "always" ihnen vertraut. Verwenden Sie --approve/-a oder --no-approve/-na, um die Projektvertrauenswürdigkeit für einen Lauf zu überschreiben.

Pi enthält kein integriertes sandbox. Integrierte Tools können mit den Berechtigungen des Pi-Prozesses Dateien lesen, schreiben, bearbeiten und Shell-Befehle ausführen. Extensions sind TypeScript Module, die mit den gleichen Berechtigungen laufen. Paketinstallationen, Shell-Befehle, Sprachserver, Testbefehle und andere Entwicklertools verhalten sich wie normale lokale Prozesse.

Das ist Absicht. Pi ist für den Betrieb mit lokalen Quellbäumen, den Aufruf von Projekt-Toolchains und die Integration in die vorhandene Entwicklungsumgebung des Benutzers konzipiert. Ein teilweise prozessinternes sandbox könnte leicht als Sicherheitsgrenze missverstanden werden, obwohl es dennoch von der Host-Shell, dem Dateisystem, den Paketmanagern, den Anmeldeinformationen und dem Erweiterungscode abhängt. Eine echte Isolation muss vom Betriebssystem oder einer Virtualisierungs-/Containergrenze ausgehen.

Projektvertrauen ist nur ein Wächter zum Laden von Eingaben. Es verhindert, dass ein Repository stillschweigend die Einstellungen oder Erweiterungen von pi ändert, bevor Sie es genehmigen. Es macht nicht vertrauenswürdigen Code, nicht vertrauenswürdige Eingabeaufforderungen oder nicht vertrauenswürdige Modellausgaben nicht sicher. Eine sofortige Injektion aus Repository-Dateien, Kommentaren, Dokumentation, context files oder Build-Ausgaben ist ein erwartetes lokales Agentenrisiko und kann von pi nicht zuverlässig verhindert werden.

Für nicht vertrauenswürdige Repositorys, generierten Code, den Sie nicht genau überwachen möchten, oder unbeaufsichtigte Automatisierung führen Sie pi in einer geschlossenen Umgebung aus. Verwenden Sie einen Container, eine VM, eine Mikro-VM, eine Remote-sandbox oder eine richtliniengesteuerte sandbox mit nur den Dateien und Anmeldeinformationen, die für die Aufgabe erforderlich sind.

Häufige Muster sind in Containerization dokumentiert:

• Führen Sie den gesamten pi-Prozess in einem Container/sandbox aus
• Führen Sie Host-Pi aus, während Sie die Ausführung des integrierten Tools in eine Gondolin-Mikro-VM weiterleiten
• Mounten Sie nur die Arbeitsbereichspfade, auf die der Agent zugreifen sollte
• Vermeiden Sie das Mounten von Host ~/.pi/agent, es sei denn, der Container soll auf Hostsitzungen, Einstellungen und Anmeldeinformationen zugreifen
• Bestehen Sie die mindestens erforderlichen API keys oder verwenden Sie kurzlebige Anmeldeinformationen
• Beschränken Sie den Netzwerkzugriff, wenn die Aufgabe ihn nicht benötigt
• Überprüfen Sie Unterschiede und Ausgaben, bevor Sie die Ergebnisse zurück auf vertrauenswürdige Systeme kopieren

Wenn Sie einen Host-Arbeitsbereich mit Lese-/Schreibzugriff binden, können Schreibvorgänge aus dem Container oder der VM weiterhin Hostdateien ändern. Verwenden Sie schreibgeschützte Mounts oder kopieren Sie Dateien in und aus sandbox, wenn Sie einen stärkeren Schutz vor unbeabsichtigten Schreibvorgängen benötigen.

Um ein Sicherheitsproblem zu melden, folgen Sie dem Repository Security Policy. Öffnen Sie keine öffentliche Ausgabe für sicherheitsrelevante Berichte.

Das erwartete Verhalten lokaler Agenten, das Fehlen eines integrierten sandbox, die sofortige Einschleusung von nicht vertrauenswürdigen Inhalten und das Verhalten von vom Benutzer installierten Erweiterungen oder Fähigkeiten liegen im Allgemeinen außerhalb der Sicherheitsgrenzen, es sei denn, der Bericht weist auf eine echte Umgehung der Berechtigungsgrenzen hin oder zeigt, wie pi Zugriff gewährt, den der lokale Benutzer noch nicht hatte.