The Responsibilities Pi Refuses to Hide: Security and Observability
Pi's minimal core leaves two responsibilities unusually visible: the host must contain the effects, and the application must decide what is worth observing. This chapter separates project trust from sandboxing, compares the containment patterns documented for Pi, and then examines its explicit telemetry contracts. The practical result is a layered judgment: you should be able to say what a trust decision protects, what a container protects, what a credential or network policy protects, and how to collect useful diagnostics without turning sensitive work into telemetry.
The distinction follows directly from the integration boundaries. A TUI, SDK, RPC client, or remote service can make the agent easier to control, but none of those interfaces automatically changes the permissions of the process that runs a tool. Likewise, a span that says a provider request failed can help an operator, but it does not become a durable session record or a substitute for verifying a file change. Pi keeps these concerns separate because combining them would make the resulting guarantees difficult to understand.
Trust stops configuration loading; containment stops effects
The misleading symptom is a trust prompt. When Pi starts in a repository containing project-local settings, extensions, skills, prompts, themes, or system-prompt files, it can ask whether the project should be trusted. It is tempting to read that question as “may the agent touch this directory?” That is not what it means. Project trust decides whether Pi loads certain project-controlled resources and settings before work begins. It is an input-loading guard.
Trust matters because a repository can carry more than source code. A project-local extension could register a tool, alter a prompt, or change a provider. A project setting could enable a package or change the agent's behavior. Holding those resources back until approval prevents the repository from silently changing Pi's configuration. User/global and explicitly supplied command-line extensions can participate in the trust decision; project-local resources are loaded only after the decision is resolved.
The guard has a narrow boundary. Context files such as AGENTS.md or CLAUDE.md are loaded according to Pi's context-file rules even when project trust does not activate the other protected resources. More broadly, the model may encounter repository files, comments, documentation, generated output, or command results while doing its work. Those inputs can contain instructions aimed at redirecting the model. Pi's security documentation treats prompt injection from untrusted content as an expected local-agent risk. Trust approval does not make the content truthful, and declining project trust does not make every later input safe.
Sandboxing answers a different question: if the model asks a tool to read, write, or execute something, what can the process actually reach? Pi does not include a built-in sandbox or a general permission system. The built-in tools and TypeScript extensions run with the permissions of the Pi process. A tool can use the user's filesystem, shell, credentials, and network unless the operating system or deployment environment imposes a boundary. An in-process check can provide a useful workflow gate, but it is not equivalent to isolation from a compromised dependency, a shell escape, or a mistake in the agent itself.
That is an intentional trade-off.