Seguridad

Pi es un agente de código local. Se ejecuta con los permisos de la cuenta de usuario que lo inicia, y trata los archivos escribibles por ese usuario como dentro del mismo límite de confianza local.

Confianza del proyecto

La confianza del proyecto controla si pi carga configuración, recursos, paquetes y extensiones locales del proyecto. No es un sandbox y no restringe lo que el modelo puede pedir a las herramientas después de empezar a trabajar en un directorio.

Pi considera que un proyecto tiene recursos que requieren confianza cuando encuentra cualquiera de estos desde el directorio de trabajo actual:

.pi/settings.json
.pi/extensions, .pi/skills, .pi/prompts o .pi/themes
.pi/SYSTEM.md o .pi/APPEND_SYSTEM.md
.agents/skills del proyecto en el directorio actual o un directorio ancestro

Un directorio .pi vacío no cuenta como recurso de proyecto que requiera confianza.

Cuando una sesión interactiva inicia en un proyecto con recursos que requieren confianza y no hay decisión guardada para el directorio actual o un directorio padre, pi sigue defaultProjectTrust de la configuración global. El valor por defecto es "ask", que pregunta si confiar en el proyecto cuando hay UI disponible. Las decisiones guardadas se almacenan por directorio canónico en ~/.pi/agent/trust.json, y la decisión guardada más cercana en la ruta actual o padre se aplica antes del valor global por defecto.

Confiar en un proyecto permite a pi cargar recursos del proyecto que requieren confianza, incluyendo:

.pi/settings.json
recursos .pi como extensiones, habilidades, plantillas de prompts, temas y archivos de system prompt
paquetes de proyecto faltantes configurados mediante la configuración del proyecto
extensiones locales del proyecto y extensiones gestionadas por paquetes del proyecto

Rechazar la confianza omite recursos protegidos. Los archivos de contexto AGENTS.md y CLAUDE.md se cargan independientemente de la confianza del proyecto, a menos que la carga de contexto esté desactivada. Antes de resolver la confianza, pi solo carga archivos de contexto, extensiones de usuario/global y extensiones CLI -e. Las extensiones de usuario/global y CLI pueden manejar el evento project_trust; la primera extensión que devuelve una decisión sí/no posee la decisión.

Los modos no interactivos (-p, --mode json y --mode rpc) no muestran un prompt de confianza. Sin una decisión de confianza guardada aplicable, defaultProjectTrust: "ask" y "never" ignoran esos recursos, mientras que "always" los confía. Usa --approve/-a o --no-approve/-na para anular la confianza del proyecto en una ejecución.

Sin sandbox integrado

Pi no incluye un sandbox integrado. Las herramientas integradas pueden leer archivos, escribir archivos, editar archivos y ejecutar comandos shell con los permisos del proceso pi. Las extensiones son módulos TypeScript que se ejecutan con los mismos permisos. Las instalaciones de paquetes, comandos shell, servidores de lenguaje, comandos de prueba y otras herramientas de desarrollo se comportan como procesos locales ordinarios.

Esto es intencional. Pi está diseñado para operar en árboles de código fuente locales, invocar cadenas de herramientas del proyecto e integrarse con el entorno de desarrollo existente del usuario. Un sandbox parcial en proceso sería fácil de malinterpretar como un límite de seguridad mientras sigue dependiendo del shell del host, el sistema de archivos, los gestores de paquetes, las credenciales y el código de extensiones. El aislamiento real debe venir del sistema operativo o de un límite de virtualización/contenedor.

La confianza del proyecto es solo una guarda de carga de entradas. Evita que un repositorio cambie silenciosamente la configuración o extensiones de pi antes de que lo apruebes. No hace seguro el código no confiable, los prompts no confiables o la salida del modelo no confiable. La inyección de prompts desde archivos del repositorio, comentarios, documentación, archivos de contexto o salida de compilación es un riesgo esperado de agentes locales y no puede prevenirse de forma fiable con pi.

Ejecutar trabajo no confiable o sin supervisión

Para repositorios no confiables, código generado que no piensas supervisar de cerca, o automatización desatendida, ejecuta pi en un entorno contenido. Usa un contenedor, VM, micro-VM, sandbox remoto o sandbox controlado por políticas con solo los archivos y credenciales requeridos para la tarea.

Los patrones comunes están documentados en Containerization:

ejecutar todo el proceso pi dentro de un contenedor/sandbox
ejecutar pi en el host mientras se enruta la ejecución de herramientas integradas a un micro-VM Gondolin
montar solo las rutas del workspace a las que el agente debe acceder
evitar montar ~/.pi/agent del host a menos que el contenedor deba acceder a sesiones, configuración y credenciales del host
pasar las claves API mínimas requeridas o usar credenciales de corta duración
restringir el acceso a la red cuando la tarea no lo necesite
revisar diffs y salidas antes de copiar resultados de vuelta a sistemas confiables

Si montas un workspace del host en lectura/escritura, las escrituras desde dentro del contenedor o VM aún pueden modificar archivos del host. Usa montajes de solo lectura o copia archivos dentro y fuera del sandbox cuando necesites mayor protección contra escrituras no deseadas.

Informar problemas de seguridad

Para informar un problema de seguridad, sigue la Security Policy del repositorio. No abras un issue público para informes sensibles de seguridad.

El comportamiento esperado de agentes locales, la falta de sandbox integrado, la inyección de prompts desde contenido no confiable, y el comportamiento de extensiones o habilidades instaladas por el usuario están generalmente fuera del límite de seguridad, a menos que el informe demuestre un bypass real del límite de privilegios o muestre cómo pi concede acceso que el usuario local no tenía ya.