Security

Defense-in-depth,
not security theater.

Praxl syncs files into directories that AI coding tools read with shell-execution privileges. That's a real attack surface. Here's exactly what we do — and what we don't — to keep your machine safe.

The threat we worry about most

Indirect prompt injection via a compromised backend. If an attacker breaks into a Praxl server (DB injection, server RCE, supply chain), they could push malicious SKILL.md content to all connected CLIs. Those files then get read by Claude Code, Cursor, etc. — which might have shell tools enabled. Result: indirect remote code execution on every connected developer's machine.

This is a category-wide risk for any tool that syncs AI configuration files. Our v1.3.0 release (April 2026) added two independent validation layers specifically to make a single backend compromise insufficient for end-user RCE.

What we do

Two independent validation layers

Both the server (skillsync / praxl-oss) and the CLI client (praxl-app v1.3.0+) validate every sync command independently. The server checks before persisting; the CLI re-checks before writing to disk. A single compromise — DB injection, server RCE, malicious npm package — cannot pierce both layers.

Path sandbox: only dot-folders

Server-side regex (isBasePathSafe) and CLI trust list both reject any skill base path outside ~/.<tool>/skills patterns. System paths (/etc, /Users/x/Library/LaunchAgents), traversal segments (..), and null bytes are blocked. Power users can explicitly opt in to custom paths via praxl trust-path — the server can never expand the trust list remotely.

File extension allowlist

Reference files synced via Praxl can only be: .md, .txt, .json, .yaml, .yml, .csv, .xml, .toml, .ini, .html, .svg, .png. Executables, scripts, and arbitrary binaries are rejected before they can land on disk — eliminating the most direct prompt-injection-to-RCE chain.

Server command channel hardening

Only three actions can be sent from server to CLI: sync, disconnect, import. Anything else is rejected by both ends. The import action is rate-limited to once per 10 minutes per user, blocking recon spam if a server token is ever leaked.

Local audit log

Every server-emitted action received by your CLI is logged to ~/.praxl/audit.log with timestamp and severity (INFO/WARN). Rejected paths, rejected files, trust-path changes, and rate-limited imports are all recorded. Useful for incident response and post-hoc inspection.

Token storage with strict permissions

CLI auth tokens are stored at ~/.praxl/token with mode 0o600 (owner read/write only). Other local users can't read it. The token is sent only over HTTPS via the x-praxl-token header; no third-party services see it.

Encryption at rest and in transit

Sensitive values stored in app_settings (API keys, integrations) are encrypted with AES-256-GCM derived from a server-side key. All HTTP traffic is HTTPS with HSTS (max-age=31536000; includeSubDomains; preload) plus a strict Content-Security-Policy.

Open source — auditable

Full source code on GitHub. The CLI is MIT licensed at AdamBartkiewicz/praxl-cli; the self-hostable server is AGPL-3.0 at AdamBartkiewicz/praxl-oss. You can read every line that runs on your machine and on your server, then run a self-hosted instance if you want to skip the cloud entirely.

What we don't do (yet)

We'd rather be honest about gaps than pretend they don't exist.

No request signing yet

Skill payloads aren't signed (Ed25519 / HMAC). Trust relies on HTTPS + token validation. Planned for a future release.

No client-side end-to-end encryption

Skill content is encrypted in transit (HTTPS) and sensitive config is encrypted at rest, but the server can read plaintext skill bodies during processing. Self-hosting eliminates this if it matters to you.

No malware scanning of file content

The allowlist is extension-based, not content-based. A file with an allowed extension containing weird bytes still gets written. The CLI doesn't execute these files, but downstream AI tools might if instructed.

Indirect prompt injection is a category-wide risk

Every tool that syncs SKILL.md files faces this: a compromised source can ship instructions an AI tool then follows. Praxl's defenses (signing, diff preview, paranoid trust modes) are on the roadmap. For now, the strongest mitigation is the dual validation layer + audit log.

Audit your installation

Audit log

~/.praxl/audit.log

Every server action your CLI receives, plus every rejection. Append-only.

Token file

~/.praxl/token (mode 0600)

Owner-only read/write. Rotate via the web app Settings page.

Trust list

praxl trust-path --list

Shows built-in defaults plus any user-added skill directories. Server can't modify.

Latest CLI version

npm install -g praxl-app@latest

Always update — security fixes ship as patch / minor releases.

Responsible disclosure

Found a vulnerability? Email hello@praxl.app with details and a proof of concept. We'll acknowledge within 48 hours and aim to ship a fix within 7 days for critical issues. Please don't open a public GitHub issue for security reports.

Audit the code yourself

The CLI and the server are both fully open source. Read every security control in source.