Security at Pathrule

Last updated: 13 May 2026 · For developers evaluating Pathrule Web, Desktop or CLI

Pathrule ships as two local runtimes against one cloud: Pathrule Studio (macOS) and Pathrule CLI (macOS, Linux and Windows), plus 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.

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.
• 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.
• We do not execute shell commands on your machine. The MCP surface has no exec tool. The hook runs in a sandboxed Node process and only emits JSON to stdout.
• 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. Outbound traffic from Pathrule Studio and Pathrule CLI goes to the hostnames below and nowhere else. Pathrule Web speaks the same Supabase surface from your browser.

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.

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.

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.

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.

What is not in that surface 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.

8. AI and LLM usage

Pathrule is not a model provider. Your AI tool (Claude Code, Cursor, Codex, Windsurf) talks to its own model provider; we never see those prompts or completions.

Pathrule itself calls Claude under our key for two narrow features only:

• 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. Not your repo.
• 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. Not your repo.

Both calls run under our key with prompt caching on. We do not retain prompts or completions beyond what is needed to return the response. We do not train models on customer content.

9. 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.

10. 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.

11. Contact

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