Security at Pathrule

Last updated: 14 August 2026 · For developers evaluating Pathrule Studio, Web or CLI

Pathrule ships as two local runtimes against one cloud: Pathrule Studio (macOS) and Pathrule CLI (macOS, Linux and Windows), plus a VS Code extension, an iOS companion app, a browser management console (Pathrule Web) and a hosted Remote MCP endpoint for cloud-only clients. Pathrule Studio and Pathrule CLI act as local runtimes. They own the local cache and run the hook that injects path-scoped context before each AI tool call. Pathrule Web is cloud-only by design: it manages your organization, members and roles, plans and billing, workspaces and usage, and never touches your disk. This page lays out the security Pathrule is built on, and how you can confirm each piece yourself.

The short version: your data sits behind per-user, database-enforced access control, your source code never leaves your disk through us, and most of what follows is independently verifiable on your own machine in a couple of minutes. The routing core is open source, and enterprise deployments can be self-hosted, so the parts that decide what reaches your agent can be read rather than taken on faith.

Trust signal, not trust statement. The hook script Pathrule installs is a single, unobfuscated Node.js file. The configuration that points your AI tool at it is a plain text file. The MCP protocol Pathrule speaks is a public Anthropic specification. You can read or run all of it yourself.

What protects your data

The security here is built into the architecture, not bolted on afterward. The essentials:

• Per-user, database-enforced access. Every read and write is checked by the database against your signed-in user, so a leaked client can only ever reach what that user already can.
• Short-lived per-user tokens, no shared admin key. Each surface carries a short-lived user token, never a shared service key that could unlock another team's workspace.
• Sessions you can cut off. Changing your password invalidates your other sessions on the server right away, instead of waiting for a token to expire.
• Step-up reauth on sensitive actions. Account deletion, organization ownership transfer, billing changes and workspace deletion each require a fresh re-authentication.
• Conversations are end-to-end encrypted. Chat content that syncs between your own devices is encrypted on-device before upload. We hold ciphertext. One documented exception, a scheduled task you explicitly mark team visible, is called out in section 4.
• Encrypted everywhere, signed builds. All traffic is TLS; storage and backups are encrypted; Pathrule Studio is signed and notarized and CLI releases are signed.
• Reversible by design. Deleting a memory, rule or skill is a soft delete, restorable for thirty days with its edit history kept.
• A reviewable activity trail. Your team can see what its agents saw and changed, with no source code in the log.

1. Boundaries by design

These boundaries are built into every surface, Pathrule Studio, CLI and Web alike. They hold by construction, not by policy, and the next section shows how to confirm them yourself.

• We do not read or scan your source files. Neither Pathrule Studio nor Pathrule CLI ships a background indexer, a file watcher reading .ts/.py/.go, or a path crawler. The MCP tools we ship operate on memories, rules and skills (markdown content your team writes), not on your repository.
• We do not upload your codebase, even in fragments, even for "search". The cloud database stores the typed content you author, plus structural metadata (node paths, version ids, activity log entries) needed to route it. There is no repo_contents table because we do not have one.
• We do not give the browser filesystem access. Pathrule Web is cloud-only and does not call out to your disk at all. Authoring knowledge and any local capability happen in Pathrule Studio or the Pathrule CLI on your machine, never from the browser.
• We do not train models on your content. No batch jobs, no data pipeline to a model provider, no opt-out switch buried in settings.
• The knowledge MCP surface has no exec tool. The hook runs in a sandboxed Node process and only emits JSON to stdout. Pathrule itself never runs a command on your machine off its own initiative. The one place commands do run is a Studio agent session you started: there, the coding engine you installed runs under its own permission model, and Studio can additionally expose run, simulator and task tools to that session. Sections 7 to 9 spell out exactly when those tools exist, what they can reach, and what governs them.
• Dictation audio is a request, not a stream. Nothing listens in the background. A clip is recorded only while you hold the dictation control, and it is either transcribed on-device or sent for transcription and dropped. See the Privacy Policy for the provider and the retention.
• Every file action is confined to the folders you opened. File, workspace and project operations resolve inside the directories you actually attached, and a request naming a path outside them is refused rather than trusted. This holds for requests that arrive from an agent as much as for ones that arrive from the interface.
• Credentials for connected servers stay in the protected core. Tokens for the servers and vendors you connect are held by the app's core and are never handed out to the interface layer that renders them.
• Publishing a design is an explicit act, and even then we cannot read it. A design becomes reachable only when you create a share link. The payload is encrypted on your machine and the key rides in the URL fragment, which the browser never sends to a server, so the viewer decrypts client-side and we hold ciphertext. A link can additionally be password protected, and revoking it stops the viewer serving that design. The shared page renders as a static document with any scripts in the content removed, decrypted content is size bounded so a malformed share cannot exhaust the viewer, and the viewer has no write path back into your workspace.
• We do not ship long-lived service-role keys. Pathrule Studio, CLI and Web all carry the Supabase project's public anon key only. Every privileged read or write is gated by your short-lived user JWT against row-level security.
• We do not phone home with raw telemetry by default. Aggregate telemetry is pseudonymous-install-id only, never carries user/org/workspace ids, paths or content, can be disabled with NO_TELEMETRY=1 or rotated with pathrule config reset telemetry-id, and is auto-off in CI. Hook injection events are visible in the Studio/CLI activity log. Marketing-site analytics load only after explicit cookie consent.

2. Verify it yourself

You don't need to trust this page. You can confirm the most important claims with shell commands in under a minute, on your own machine, before or after install. The checks below work whether the runtime is Pathrule Studio or Pathrule CLI.

The hook script is plain JavaScript you can read. After installing Pathrule, the hook script lives at a known path. Open it. It's a single file, no minification, no obfuscation.

# macOS / Linux
cat ~/.pathrule/bin/pathrule-hook.js | head -40

The hook configuration is a plain file your AI tool reads. Pathrule does not patch your AI tool. It writes a hook entry into the configuration file your tool already reads at startup, with the absolute path to the hook script. Inspect what gets registered:

# Claude Code
cat ~/.claude/settings.json

# Cursor
cat ~/.cursor/hooks.json

# Codex CLI
cat ~/.codex/config.toml

If you ever want Pathrule out of the loop, deleting those entries removes it instantly. Nothing else in your AI tool changes.

The MCP tool surface is enumerable. Pathrule speaks the public Model Context Protocol from Anthropic over stdio. Any MCP client can introspect the full list of tools, their input schemas, and their descriptions with a standard tools/list call. There are no hidden tools.

The network surface is short and auditable. Pathrule's own outbound traffic from Pathrule Studio and Pathrule CLI goes to the hostnames below. Pathrule Web speaks the same Supabase surface from your browser.

One honest caveat: Pathrule Studio also runs the AI coding engines you install and sign in to. Those engines talk to their own providers (for example Anthropic, OpenAI, Google, or another vendor you configured) under your own account, on connections Pathrule does not proxy or inspect. That traffic belongs to the engine, not to us, and it appears in a packet capture alongside ours.

You can confirm this with your OS firewall, a packet capture, or by running the app behind a proxy. There are no analytics, error-reporting, or telemetry hostnames in that list.

Two paths deliberately run through the cloud rather than from your machine. Cloud dictation uploads the clip to a Supabase Edge Function which calls the speech provider, so the provider key never ships inside the app. Figma design links are registered server-side: the Figma OAuth token you supply is used for that single request and is never persisted or logged, and the function verifies your user token and your workspace access before any privileged write. In both cases your client only ever talks to *.supabase.co.

3. What the local runtime touches on disk

The local runtime (Pathrule Studio or Pathrule CLI) is least-privilege about your file system. It writes to its own directories only and never to your project files. Pathrule Web has no on-disk footprint beyond standard browser sessionStorage for the auth session.

The runtime does not read from arbitrary paths under your repository. The hook supervisor reads the cache and nothing else under your project, with realpath/traversal/symlink containment on every read.

4. How the cloud is gated

• RLS on every table. Every read and write runs through a Postgres row-level security policy resolved against your user JWT, your organisation membership and any node-level overrides your workspace defines. The database does the final check; the application layer cannot bypass it. Same RLS for Pathrule Studio, Pathrule CLI, Pathrule Web and the MCP server.
• No service-role keys anywhere. Every surface holds a short-lived user JWT, refreshed in place under a shared file lock to keep Studio, CLI and MCP from racing each other. There is no shared admin key. A compromised client can only see what its user is already allowed to see.
• Server-enforced session freshness. A per-user security epoch on the server makes a stale JWT unusable for data access before it naturally expires, so password changes and account-level events cut off old sessions across Studio, CLI, Web and MCP without waiting on client logout.
• Sensitive actions need fresh reauth. Password change, account deletion, org owner transfer, role changes, billing portal creation and support-bundle export consume short-lived, action-scoped reauth grants instead of trusting an old ambient session.
• Multi-tenant by row. Every memory, rule, skill and activity row carries its tenant id. The same RLS policies apply to direct database queries, Realtime subscriptions and Edge Function calls.
• Encrypted in transit and at rest. All traffic to the cloud is HTTPS / TLS 1.2+. Storage at rest is encrypted by the managed Postgres provider. Backups are encrypted and access-controlled.
• Deletes are reversible. Deleting a memory, rule or skill is a soft delete: the item leaves routing immediately but stays restorable for thirty days, with its edit history retained. Restore brings it back to the same path. No routine action by a teammate or an AI removes content for good.

End-to-end encrypted conversation content

Chat content that Pathrule Studio syncs so you can pick a session back up on another device, message bodies, titles, diffs, todos and turn summaries, is encrypted on the device before it is uploaded.

• X25519 key agreement, HKDF-SHA256, AES-256-GCM. The desktop implementation and the Swift implementation in the iOS app are kept byte-identical, and a change to one without the other is treated as a release blocker.
• Device private keys never leave the device. The per-account content key is sealed to each approved device's public key and unwrapped only on-device. Approving a new device is an explicit action.
• We store ciphertext and a nonce. We cannot read this content on the server, and neither can a teammate whose device does not hold your key.
• One documented exception. A scheduled task whose result you mark team visible is an explicit share, so its result conversation is stored workspace-readable in plaintext under row-level security instead of end-to-end encrypted, because a run that happens without you has no device key to seal to. Conversations that are not team visible stay end-to-end encrypted.
• Recall embeddings. To let past sessions be recalled, a turn summary is sent to our embedding provider (Voyage AI) and comes back as a vector stored under owner-only RLS. That call transmits the summary text; the copy we hold at rest stays encrypted.

5. Pathrule Web in the browser

Pathrule Web is served from app.pathrule.io and is authenticated, not indexable. It is the management console for your organization, members and roles, plans and billing, workspaces and usage, running against the same cloud with browser-safe APIs only.

• Robots: noindex, nofollow. The app surface is for signed-in users and is not crawled.
• No third-party tracking SDK inside the app. Aggregate telemetry is pseudonymous-install-id only and can be opted out.
• Auth uses Supabase PKCE with a dedicated /auth/callback route. The browser session lives in browser storage only; signing into Web does not authenticate Studio or CLI.
• No filesystem access in the browser. Pathrule Web cannot reach your disk. Authoring knowledge and running agents happen in Pathrule Studio or the Pathrule CLI, not in the browser.
• OAuth identity linking is conservative. Pathrule Web does not expose provider-linking APIs from any user-facing flow; Supabase manual linking is disabled in our project config; an attacker-created unverified password identity cannot be silently linked into a victim's verified OAuth account.
• TOTP MFA is available in Account Settings and survives across Web and Studio. Sensitive actions still require action-scoped reauth even with MFA on.

6. Pathrule Studio app defaults

Pathrule Studio is configured with strict desktop-app security defaults.

• Context isolation is on. The renderer process has no direct access to Node, require() or native modules.
• Node integration in renderers is off. Chromium runs as Chromium.
• Process sandbox is on. The renderer runs inside the macOS App Sandbox.
• All renderer ↔ main IPC goes through a typed contextBridge preload. The renderer cannot invoke arbitrary main-process code.
• External links open in the system browser. The renderer cannot spawn new windows on its own.

Pathrule for iOS

The iOS app is a companion for reading and continuing your desktop sessions, not a second place to run agents.

• It decrypts, it does not hold your key in the clear. The device generates its own key pair; the private key stays in the iOS Keychain, stored AfterFirstUnlock and never synced or exported. The per-account content key is sealed to that device's public key and unwrapped on-device.
• A new device is an approval, not a login side effect. Adding a device is an explicit step, so signing in somewhere is not by itself enough to read your encrypted history.
• Same RLS, same session rules. The app carries a short-lived user JWT against the same row-level security and the same server-side session freshness as every other surface.
• The crypto is the desktop's crypto. The Swift implementation is held byte-identical to the TypeScript one, and cross-platform decrypt is verified before a release ships.

7. The MCP tool surface

The MCP server exposes a small, typed set of tools. They cover four scopes (read, write, list and log) for the three node types: memory, rule, skill. Plus a handful of utility tools for setup, context retrieval and the suggestion review flow.

This is the surface you get when you connect Pathrule to any engine Studio runs, to Cursor, Windsurf or Copilot, or to the hosted Remote MCP endpoint. What is not in it is what matters most:

• No exec or shell tool.
• No read_file for arbitrary paths.
• No write_file outside the typed content store.
• No list_directory of your repository.

Tool arguments are validated against a schema before any database call. The full list, with descriptions, is discoverable by your AI tool with a single tools/list MCP call, so you can confirm for yourself that no file-reading tool is in the surface.

The extra tools inside a Studio session

Pathrule Studio can hand an agent session it started a second group of tools: running a build or app target, driving a simulator, working the Tasks board, and reading the Design surface. These are how "run my app and check the screen" works at all, so they deserve a precise boundary rather than a reassuring sentence.

• They only exist when Studio is on the other end. Each group registers itself only if Studio passed a run-bridge URL and a bridge token into the process environment. Without those, the tools are not registered and tools/list does not return them. Your editor's own Pathrule MCP connection never has them.
• They are a bridge, not a shell. Every call is a typed request over that local bridge to Studio, which performs the action itself. There is no free-form command argument: a run tool names a target from a catalog Studio built, a simulator tool names a device and an action.
• They act on what you selected. A run targets the app and device you chose in Studio for that workspace, not an arbitrary path or binary.
• The coding engine is separate. The engine you installed has its own file and command permissions, granted by you inside that engine. Section 9 covers how Pathrule states its own gates on top of that.

8. Agents that run in their own checkout

Studio can run a conversation, or a single task card, in its own git checkout of the repository on its own branch, so several agents work the same project at once. The isolation is the point, and so are its edges.

• Your working copy is never touched. It is never checked out, never stashed and never switched under you. An isolated run happens in a separate checkout outside your repository, in one predictable, configurable location.
• Isolation is opt-in, per conversation. The default stays the main checkout, so nothing about the single-agent flow changes when you leave it off.
• Preparing a checkout asks first. A fresh checkout has no installed dependencies and none of your ignored files. Studio reads your lockfile, states the exact command it would run and the ignored files it would copy, and runs it only after you allow it once or for that project. A preparation command is a shell command, and it is treated as one.
• Studio runs git and the GitHub CLI, never the model. Merging, opening a pull request, staging and pushing are performed by the app. A conflict stops and names the files it stopped on, leaving your main working copy exactly as it was. A missing or unauthenticated CLI says so instead of asking an agent to improvise.
• Nothing lands on its own. Landing a branch, as a squash, a fast-forward, a merge commit or a pull request, is a user action every time. Closing a conversation leaves its branch and its checkout alone until you say otherwise.
• Checkout records stay on your machine. They are never synced to teammates, because a path is machine specific and a preparation command is a shell command that should not travel.
• The context layer follows the checkout, the permissions do not widen. An isolated checkout resolves back to the workspace it was cut from, so the same path-scoped memories, rules and skills reach a parallel agent. What that agent may do is still governed by the rules in the next section.

9. What an agent is allowed to do

Permission requests used to be written by whichever engine raised them, which meant the same question was worded differently depending on what you were running and your settings only reached some of them. That is no longer the case, and the honest details matter more than the reassurance.

• One set of rules, for every engine. Each gate travels as plain data and Studio writes the words, so a confirmation reads the same whoever asked, in your language, and one set of rules covers all of them.
• A rule you already wrote is not asked again. A request your rules already answer is settled without interrupting you. Anything they do not cover still asks.
• Running shell commands defaults to automatic. We changed this deliberately: a card on every single step taught people to click through without reading. If you want commands gated, set that in your permission rules, and the gate then applies to every engine rather than to whichever one happens to honour it.
• The coding engine keeps its own permission model. The engine you installed has its own file and command permissions, granted by you inside that engine. Pathrule does not widen them, and an approval you gave the engine is not an approval you gave Pathrule.
• Expired engine sign-ins are handled in the app. When a coding engine's sign-in expires, Studio signs it out and back in from inside the app rather than sending you to a terminal to paste a credential.

10. Signals, if you turn it on

Signals links what your product does at runtime back to the code, rules and memories that touch it. It is off until you switch it on, and it is deliberately not analytics.

• Opt-in per workspace, and propose-first. /signals runs a read-only scan of your project and proposes where instrumentation should go, one point at a time. You approve the points you want, and only those are wired in. Consent is explicit and carries across your devices.
• No package to install and no key to paste. The SDK is vendored by Studio rather than pulled from a registry, and the per-workspace ingest key is minted by the desktop rather than copied by hand.
• It is not analytics. Signals carries runtime errors, important events and feedback tied to code and features. There are no users, sessions, funnels or personal data in that model, and repeats of one problem group into a single incident rather than a stream of rows.
• It cannot take your product down. Transport and quota failures are swallowed inside the SDK. Nothing is thrown into your application, and an incident that crosses the worthiness threshold is handed to your task flow, not to a pager.
• Outcomes are evidence, not claims. After a release the same incident is watched again and reported as observing, quiet, verified or recurred, so a fix is only marked done when runtime evidence backs it.

11. AI and LLM usage

Pathrule is not a model provider. Your coding engine talks to its own model provider under your own account; we never see those prompts or completions.

Pathrule itself calls Claude under our key for a named set of narrow features. Each one takes the specific knowledge object it is working on, never your repository:

• Three-way merge resolution. When two teammates edit the same node and a version conflict produces non-overlapping edits, an LLM call resolves the merge field by field. Input: the three versions of that node.
• AI repair on detector suggestions. When a detector writes a suggestion ("this rule has zero hits in 60 days"), you can hand it to an LLM to draft a patch. Input: the specific node and the detector's signal.
• Drafting a memory, rule or skill. When you ask Pathrule to draft or tidy a knowledge item, the draft is generated from that item and its immediate neighbours.
• Knowledge maintenance. Freshness and staleness checks that flag a memory the codebase has moved past, and the titles and summaries attached to those cases.
• Team and task intelligence. The summaries and context receipts Studio shows on the Tasks board, built from your own knowledge objects and activity metadata.

Two more calls leave our own key out of it and go to specialised providers, documented in the Privacy Policy: embeddings for retrieval, and cloud speech-to-text for dictation.

All of these run server-side, with prompt caching on where it applies. We do not retain prompts or completions beyond what is needed to return the response, and we do not train models on customer content. Your own coding agent's prompts and completions are a separate matter entirely: they go from your machine to your provider, and we never see them.

12. Code signing and updates

Pathrule Studio

• macOS builds are signed with our Apple Developer certificate and notarized by Apple. Gatekeeper verifies them before first launch.
• The auto-updater verifies signatures before applying any update. An unsigned or tampered binary refuses to install.

You can verify the signature on macOS with:

codesign --verify --deep --strict --verbose=2 "/Applications/Pathrule.app"
spctl --assess --type execute --verbose "/Applications/Pathrule.app"

Pathrule CLI

• Distribution channels: a signed standalone binary plus an npm package (the cross-platform install path for macOS, Linux and Windows). Distribution signatures are enforced so the CLI you run matches what was published.
• Auto-update policy is opt-in. The default notify mode checks app.pathrule.io/cli/versions.json at most once per 24h and prints an upgrade hint; it never rewrites the CLI binary on its own. auto mode is available for managed installers only (brew/npm) and requires explicit first-time confirmation. CI=true and NO_UPDATE_CHECK=1 force manual.
• The CLI never silently mutates a standalone binary.
• Signing in from a terminal uses an RFC 8628 device authorization flow. The server stores only SHA-256 hashes of the device and user codes, so the codes themselves are not sitting in a table.

Pathrule for iOS and the VS Code extension

• The iOS app is distributed through the App Store and signed by Apple's review and distribution pipeline.
• The VS Code extension is published to the Visual Studio Marketplace and Open VSX from a tagged build, with both registries fed by the same release job so one publisher cannot drift from the other.

13. Reporting a security issue

If you believe you've found a vulnerability in the desktop app, the MCP server, the website, or the cloud service, please email [email protected] with:

• A clear description of the issue and the affected component.
• Reproduction steps. A minimal repro is appreciated but not required.
• The impact you observed, including any data classes affected.
• The platform and version where you reproduced it (the Pathrule About menu reports both).

We acknowledge reports within one business day and aim to share a triage update within five. Responsible-disclosure researchers are credited on request and never sued for good-faith research. Please don't test against other tenants, run automated scanners against pathrule.io, or attempt to access data outside accounts you own.

14. Contact

• Security inbox: [email protected]
• General contact: [email protected]
• Privacy and data requests: [email protected] · see the Privacy Policy