​

Security

OpenPawz is designed with defense-in-depth: multiple layers protect against prompt injection, data exfiltration, and unauthorized actions.

​

Human-in-the-Loop (HIL)

Every tool is classified by risk level. High-risk tools require explicit human approval before execution.

​

Auto-approved tools (no approval needed)

fetch · read_file · list_directory · web_search · web_read · memory_search · memory_store · soul_read · soul_write · soul_list · self_info · update_profile · create_task · list_tasks · manage_task · email_read · slack_read · telegram_read · image_generate

​

HIL-required tools (human must approve)

exec · write_file · delete_file · append_file · email_send · webhook_send · rest_api_call · slack_send · github_api

​

Agent policies

Per-agent tool access control with four presets: You can also create custom policies with specific tool allowlists/denylists.

​

Risk classification

​

Prompt injection defense

All incoming channel messages are scanned for injection attempts before reaching the agent.

​

Detection

Pattern-based scoring across 9 categories (8 in the Rust backend scanner, 9 in the TypeScript frontend scanner which adds obfuscation):

​

Severity levels

Channel bridges automatically block messages with critical severity.

​

Container sandbox

Execute agent commands in isolated Docker containers:

​

Presets

​

Command risk assessment

Commands are scored before execution:

• Low — ls, cat, echo
• Medium — pip install, npm install
• High — curl, wget, network commands
• Critical — rm -rf /, chmod 777, dangerous patterns

​

Browser network policy

Control which domains agents can access: Default allowed: AI provider APIs, DuckDuckGo, Coinbase, localhost Default blocked: pastebin.com, transfer.sh, file.io, 0x0.st (data exfiltration risks)

​

File system protection

Sensitive paths are blocked from agent access — agents cannot add these as project folders or browse into them. Additionally, the home directory root itself (~, /home/user, /Users/user) and the filesystem root (/, C:\) are blocked as too broad. :::tip Per-project scope guard When a project is active, all file operations are constrained to the project root. Directory traversal sequences (../) are detected and blocked even within the allowed path. :::

​

Credential security

Credentials are protected by two independent encryption layers:

​

Layer 1: Skill credential encryption (XOR)

• API keys encrypted with XOR using a 32-byte random key
• Encryption key stored in OS keychain (paw-skill-vault)
• High-risk credentials (Coinbase, DEX) are server-side only — never injected into prompts
• Credentials are decrypted only at execution time

​

Layer 2: Database field encryption (AES-256-GCM)

Sensitive database fields are encrypted with AES-256-GCM via the Web Crypto API before being stored in SQLite. :::info Two independent layers The XOR layer protects skill credentials stored in the skill_credentials table. The AES-256-GCM layer protects other sensitive fields across the database. Both derive their keys from the OS keychain but use separate keychain entries. :::

​

Tool execution security

Tool execution is governed by multiple safety mechanisms in the engine’s central tool executor.

​

Source code introspection block

Agents cannot read engine source files — any read_file call targeting paths containing src-tauri/src/engine/, src/engine/, or files ending in .rs is rejected. This prevents agents from exfiltrating their own implementation details or discovering internal security mechanisms.

​

Credential write block

The write_file tool blocks content that contains credential-like patterns:

• PEM private keys (-----BEGIN ... PRIVATE KEY-----)
• API key secrets (api_key_secret, cdp_api_key)
• Base64-encoded secrets with secret or private keywords

​

Execution limits

​

Output truncation

Tool results are capped to prevent context window overflow:

​

Network policy enforcement

The fetch tool enforces domain-level network policy — blocked domains are always rejected, and when an allowlist is active, only listed domains are permitted.

​

Exfiltration detection

Outbound network commands are audited for data exfiltration patterns:

• Piping file contents to curl, wget, or nc
• File upload flags (curl -T, curl --data-binary @, wget --post-file)
• Redirects to /dev/tcp/
• scp and rsync to remote hosts

:::warning Exfiltration detection is pattern-based and applies to exec tool invocations. It supplements — but does not replace — the container sandbox for high-security environments. :::

​

Budget enforcement

Daily spending limits with progressive warnings:

​

Trading safety

​

Channel access control

Each user gets an isolated session — no cross-user data leakage.

​

Reporting vulnerabilities

See SECURITY.md in the repository for reporting instructions.