8000 GitHub - jmecom/pi-ifc: information flow control in pi · GitHub
[go: up one dir, main page]

Skip to content
jmecomPublic

About

information flow control in pi

Resources

Stars

0 stars

Watchers

0 watching

Forks

Repository files navigation

pi-ifc

A small Pi extension for experimenting with information flow control while coding.

pi install ~/development/pi-ifc
cd /path/to/project
pi

Requires macOS sandbox-exec, Python 3.10+, and Xcode command-line tools.

Start with policy.ts for our trust choices, destination permissions, and deliver functions. ifc.ts combines labels and checks flows; extension.ts applies those decisions around tool execution.

  • Sandbox: The current directory is the approved workspace. File and shell tools can edit and test locally, but cannot access the network.

  • Labels: Confidentiality scopes track sharing permissions: project_private for workspace data, other_private for other private inputs, and none for public data. Combining data keeps both scopes. Integrity is trusted/untrusted. Reads label the conversation; edits and shell calls also label the whole workspace. Restrictions persist across sessions and do not stop local coding.

  • Hidden values: References keep text out of the main model's context. Reads and web replies hide results that would taint a trusted conversation. quarantined_llm_call processes hidden text without tools. Its answer stays hidden and keeps the labels. inspect reveals text and inherits its labels. Once the conversation is untrusted, results stay visible.

  • Read approvals: Outside reads ask you to deny, read as untrusted, or trust that read. Trust changes integrity only; the other_private scope stays. ifc_read_many groups exact files into one decision for that batch.

  • Planning: ifc_plan reports labels and push/web requirements so the model can anticipate taint and reduce interruptions. A plan grants no permissions.

  • Research: research has its own model history and only public web fetches (up to 8). You review its brief for public use, then edit and endorse its plan before the coding model sees it. Rejected plans stay out of the conversation. Endorsement preserves private scopes and earlier taint; sandbox and destination checks still apply. Human review can miss malicious recommendations.

  • Controlled pushes: git_push sends a fixed commit and its history to your configured SSH remote. Authorize public-only or project_private data. Other scopes require release approval; untrusted influence also requires endorsement. We trust the configured server's replies and show them directly. Approval does not reset labels.

  • Web: web_fetch makes one HTTPS GET. Private or untrusted URL influence needs approval for that request, before DNS. Replies stay untrusted and keep the request's scopes. No credentials, redirects, non-public IP addresses, or workspace access; shell stays offline. Text only, up to 1 MiB and 20 seconds.

  • Bookkeeping: State and worker copies live outside the editable workspace. Tool calls run in order; a lock prevents competing IFC sessions.

  • /ifc: status

  • /ifc debug: toggle colored label traces

  • /ifc push: configure the destination

  • /reload: load extension changes

Research code. The initial workspace, Pi, other extensions, runtimes, and model provider are trusted. The provider may receive all scopes. Changes made by other host programs are not tracked.

RPC clients

IFC supports Pi 0.85's RPC mode when a trusted frontend implements the review contract below. That frontend sets PI_IFC_RPC_UI=human-review-v1 on the Pi process it launches with --mode rpc. Without this declaration, IFC refuses RPC startup. Interactive and print mode keep their existing behavior.

The declaration is a compatibility contract, not authentication or permission to bypass IFC. The RPC client is trusted in the same way as Pi's terminal UI: it can see private review text and return decisions on the user's behalf. Do not set this variable globally or use it to enable an unverified adapter.

The client must handle Pi's extension_ui_request messages for select, confirm, input, and editor. It must show the full title, message, choices, and editor prefill, preserving multiline review text. It must wait for an explicit user submission or cancellation and return extension_ui_response with the matching request ID. A prefilled editor is not an approval.

These dialogs must never go through automatic permission approval, including an application's Full access mode. Unknown dialogs, unsupported controls, timeouts, closed views, and cancellation must produce cancellation, not an affirmative default. Stop and disconnect must cancel pending reviews; late replies cannot authorize the cancelled operation. The client must keep review text out of model messages and must not inject file contents or untrusted machine output as if the user typed them. Access to those files still belongs through IFC's tools and labels.

IFC accepts only a literal boolean true for confirmations, an exact offered choice for selections, and strings for editor/input replies. Push snapshot checks, exact-file read grants, research endorsement, labels, tool ownership, and the offline shell sandbox remain enforced in the extension. The normal RPC bash command also goes through IFC's sandbox hook.

The released pi-acp@0.0.33 adapter does not implement this contract: it cancels editor/input requests and translates confirmations to ordinary permissions. It must be updated before Alto can set the declaration. Enabling this variable alone does not make that adapter safe or complete.

Run npm run check and npm test to validate changes. The RPC integration tests require macOS and the local Pi dev dependency. They use temporary workspaces and an isolated test profile, without model calls, real pushes, or changes to the user's Pi configuration.

Papers: FIDES, CaMeL, Prudentia, Denning, agent design patterns.

About

information flow control in pi

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

0