Docs/Reference

Trust, secrets, and data

Project resources, credential resolvers, database recovery, and isolation boundaries.

Project trust, credential storage, and browser isolation cover different parts of pi-kit. Coding-agent tools can still execute commands and access paths outside the selected working directory.

Project trust#

A repository can contain executable extensions, MCP commands, setup scripts, skills, and prompt templates. The trust dialog lists project resources before loading them.
Saved decisions can be reviewed in Settings → Projects and Advanced → Trust. User-installed extensions also execute code, independently of a project's trust state.
Project trust controls resource loading. It does not approve every command a model may produce or confine tools to the repository.

Credential storage#

When available, pi-kit uses the operating system's credential store. Supported authentication flows store a resolver command in configuration instead of a literal secret. For example:
{
  "openrouter": {
    "type": "api_key",
    "key": "!pi-kit-secret get openrouter"
  }
}
The resolver must be installed/reachable, and the named credential must exist. Existing macOS configurations may use a security resolver. The provider row reports storage state; literal keys, environment variables, and stored-key resolvers have different origins.
The pi-kit-secret CLI provides get, set, delete, and list. Credential-store and CLI controls are in Advanced → Security. get prints the secret; exclude that output from logs and reports.
Fallback behavior is reported when an OS store is unavailable. Check the current storage state rather than assuming every platform has a working keychain connection.

Database and recovery#

pi-kit's database is encrypted with a separately stored key. Advanced → Security includes recovery-key controls. Save the recovery value outside the repository, for example in a password manager.
PI_KIT_DB_KEY is an advanced recovery mechanism for opening a database whose credential-store entry is unavailable. Back up the database before recovery or profile changes.
Database encryption does not cover every file created by pi, the project, or an external tool. Session files, configuration, backups, and provider logs have their own storage rules.

Browser isolation#

Artifacts pages run without Node integration or pi-kit preload, in per-thread in-memory sessions. Internal renderer/backend origins and non-HTTP(S) URLs are blocked. Downloads and permission requests are denied.
The browser boundary separates a project page from privileged application APIs. Page text, DOM attributes, and console messages remain untrusted input to the agent. The boundary does not restrict shell tools outside the browser.

Local inference and network access#

A local model keeps inference requests on the configured server. Other features may still use the network: package installation, Hugging Face downloads, MCP services, browser pages, or an attendant configured with a hosted model.
For offline or sensitive work, review those connections separately from the foreground thread's model selection.

Reports and exports#

Redaction is applied in supported storage/display/export workflows. Review the actual output before sharing: logs and screenshots can include credentials, private source, account details, or paths.
A bug report normally needs the app version, platform, reproduction steps, and relevant error text. Do not include provider keys, authorization headers, or database recovery values.