Skip to main content

​
Security Architecture

Myrm implements a defense-in-depth security model with six layers, ensuring agents operate safely even when given broad autonomy.

​
Security Layers

​
Approval Modes

Control how much autonomy agents have:

​
Session Security Presets

Switch security posture per chat session from the input toolbar — no need to change global settings:
  • Presets are mutually exclusive with YOLO mode — selecting a non-default preset automatically disables YOLO, and vice versa.
  • The Auto-Approve Edits preset enables the Transcript Classifier (LLM-based smart review) for shell commands — safer than blanket ALLOW because suspicious commands still trigger human review.
  • The Read-Only preset precisely denies 12 categories of write operations (file write/edit/delete, shell, code interpreter, browser automation, skill/cron management) while keeping reads and agent delegation open.
  • Available in Agent mode only; the selector hides automatically in Fast Search mode.

​
Plan Review

Before executing a complex task, agents can propose a plan for user review. When Plan Review is enabled in Settings → Security:
  • The agent’s first plan creation triggers a PlanConfirmationCard in the chat UI
  • Users can Confirm (proceed as-is), Edit (modify the plan before execution), or Skip (let the agent proceed without plan constraints)
  • Supports both Deep Research and General Agent workflows
  • Works alongside approval modes — even with YOLO enabled, plan review can still be required
This provides a high-level checkpoint before the agent begins work, complementing the per-tool-call approval system.

​
Structured Clarification

Agents can ask structured questions using the ask_question_tool before taking action:
  • Single-choice, multi-choice, and free-text question types
  • Frontend renders a dedicated ClarificationInput form — not plain text chat
  • Responses flow back into the agent loop as structured data
  • Particularly useful for ambiguous tasks where the agent needs user input to proceed correctly

​
10-Layer Progressive Approval Architecture

Every tool call passes through up to 10 layers of deterministic and intelligent checks before reaching the user:

​
Multi-Platform Approval UX

Every approval surfaces the same four actions across all channels: Allow Always offers four granularity levels:
  • Permission: Allow all tools with this permission type (e.g., all file writes)
  • Tool: Allow this specific tool regardless of arguments
  • Exact: Allow this tool only with these exact arguments (default for shell tools — safest)
  • Pattern (shell only): Allow commands matching a derived glob (e.g. curl -sS *). Compound shell (&&, |, ;) is never saved. All pattern rows appear in Settings → Allowlist and can be deleted anytime.
Migration benefit: Approve a recurring deploy script once with “Allow always (this pattern)” — later runs auto-approve without YOLO. Claude Code and OpenClaw typically stop at tool-name allowlists or CLI-only signing; Myrm gives you GUI-managed, revocable pattern rules with Chrome LIVE E2E proof (Jul 2026).
Batch operations are supported via /batch a,d,aa (approve, deny, always) and UI bulk buttons. When an agent pauses for approval, the sidebar displays a real-time amber pulse indicator next to the affected chat — even if you’re currently viewing a different conversation. This eliminates the need to manually check each session for pending approvals:
  • Amber pulse dot: Agent is waiting for your approval/clarification
  • Green pulse dot: Agent is actively generating
  • No dot: Session is idle
The indicator survives page refresh (via server-side approval recovery) and syncs in real-time across all open browser tabs via SSE multiplex. When you resolve the approval, the indicator disappears immediately as the agent resumes.

​
Approval Timeout Race Protection

When an approval timeout fires and a user manually approves almost simultaneously, the system guarantees exactly-once execution via an idempotent resolve_if_first guard:
  • WebUI: Backend returns HTTP 409 → frontend shows a friendly toast and removes the stale approval card
  • IM Channels: Agent replies with a localized message (EN/ZH) informing the user the approval was already handled
  • Concurrent safety: Only the first resolver wins; all subsequent attempts are no-ops
This prevents double agent execution, duplicate LLM costs, and contradictory operations — a gap present in most competing frameworks.

​
Session Directory Authorization & Transparent Kernel Interception (Local & Desktop)

When the agent needs files outside the current workspace (e.g. ~/Downloads, a project folder you mentioned), Myrm uses Kernel Transparent Interception + Proactive Pre-authorization, completely eliminating the need for an LLM-facing request tool (such as legacy request_directory_tool): Compared to competitors: OpenWorker Cowork still relies on explicit request_directory which bloats LLM Action Space and invalidates Prompt Cache; OpenClaw, Hermes, DeerFlow, LobsterAI, CoPaw, and jiuwenclaw lack session-scoped directory HITL. Myrm achieves kernel transparent interception, dynamic elevation, drag-and-drop pre-authorization, and Prompt Cache freeze.

​
Correction Learning

When you edit an approved action’s arguments or reject a tool call, the system automatically learns your preferences:
  • Zero LLM cost: Deterministic dict-diff classification (no additional inference calls)
  • Path preferences: Rejects or edits on file operations → remembered as workspace conventions
  • Command rules: Rejects on shell commands → added to procedural memory as permanent rules
  • Repetition tracking: Repeated rejections of similar patterns → auto-deny (stops asking)
Over time, approval prompts naturally decrease as the agent aligns with your working style.

​
Error Self-Healing

14-layer error recovery system automatically handles failures without user intervention. See Error Recovery for details. Key capabilities:
  • Stream interruption recovery (token-level precision)
  • Circuit breaker with 3-tier cooldown
  • Model fallback chains
  • Truncation auto-retry with progressive budget boost
  • Deterministic fallback (LLM-free safety net)

​
Authentication & Health Monitoring

Real-time monitoring of credential validity and system health, with automatic alerting:

​
Session-ID Whitelist (Path-Traversal Guard)

User-controlled session identifiers (chat_id / session_id) must never escape the event-log directory when interpolated into filesystem paths. Every API entry that accepts a user-supplied identifier runs a shared whitelist check (is_safe_session_id, charset [A-Za-z0-9:_-]) fail-fast — before any business logic executes: Non-string inputs (e.g. an integer sent to the WebSocket path where no Pydantic coercion exists) are rejected too — the validator returns False for any non-str value instead of raising TypeError. This keeps path-traversal (.., backslash, NUL byte) protection uniform across REST, WebSocket, and Realtime entries with no exception-handling divergence.

​
Prompt Injection Defense

Two complementary subsystems protect against prompt injection — one for untrusted external content flowing into the agent, and one guarding user/file inputs.

​
Content Boundary (Output-Side)

5-layer defense wrapping all external content and tool output before it enters the LLM context, covering the entire tool chain (built-in tools + third-party MCP tools + PTC built-in tools): Data returned by third-party MCP tools is automatically passed through all 5 defense layers before entering the LLM context, preventing malicious MCP servers from injecting instructions via tool outputs.

​
Prompt Guard (Input-Side)

113 detection patterns across 26 threat categories scan user messages, project rules, and skill files:
  • Anti-obfuscation: Leet speak reversal, invisible Unicode stripping, whitespace folding, Base64 decoding
  • Bilingual detection: English and Chinese prompt injection patterns (e.g., “忽略之前的指令”)
  • Two-pass detection: First on normalized text, then on Base64-decoded content

​
Memory Write-Path Scanning

Unlike input-side guards (which protect the conversation), the write-path scanner protects durable memory — it runs deterministically on every memory write before persistence, so a prompt-injected agent cannot store malicious instructions, secrets, or forged system tags even if the injection succeeded upstream:
  • Instruction-shape detection — guardrail-bypass orders and untrusted-channel writes are blocked (bilingual attack library)
  • Credential zero-retention — API keys, passwords, PIN/OTP numeric credentials are redacted in place; years and phone numbers are excluded to avoid false positives
  • Fake system-tag interception — System:/Assistant: colon prefixes are treated as injection
  • Every write path shares the guard — manual stores, batch writes, updates, profile, rules, MCP tools, agent auto-extraction, and import recovery
  • CI poisoning benchmark gate — two-layer expectation tests (detection layer + extraction layer) run in CI to prevent regression
Even with upstream content guards in place, a prompt-injected agent could still be coaxed into planting a symlink inside a framework directory that points at a sensitive file (e.g. ~/.env, SSH keys). Any later code that opens that lock path with “create/truncate” semantics would then silently destroy the file it points at — a real data-loss path for a framework-level public API. The harness FileLock (used by the delivery queue) opens lock files with O_NOFOLLOW (guarded by hasattr on Windows), so a planted symlink is rejected instead of followed: This is one more defense-in-depth layer: even if a prompt-injection attack succeeds at the filesystem level, arbitrary file truncation through the lock path is structurally impossible. Beyond symlink defense, the harness FileLock hardens the entire lock lifecycle against misuse and silent failure: Cross-process mutual exclusion is verified in CI via subprocess tests (macOS) alongside the asyncio concurrency integration suite.

​
Sub-Agent Security

Multi-agent workflows introduce identity drift and privilege escalation risks. Myrm addresses this at every level:

​
Skill Installation Security

When installing skills from any source (GitHub, SkillHub, file upload), every skill passes through a triple-layer security gate before activation:

​
Trust Levels

Skills are assigned one of four trust levels that gate their runtime capabilities: The quarantine_aware decorator automatically filters rejected skills at runtime — a quarantined skill simply disappears from the agent’s available tools without error.

​
Runtime Permission Boundary

After a skill passes installation, sensitive runtime operations remain gated by the skill permission gate (SkillBoundaryProvider): file writes, command execution, network access, env-var reads and similar sensitive permission types must already be granted — otherwise the tool call is rejected at the engine layer (skill_boundary.violation, fail-loud, never silently downgraded).
  • Single source of truth: tool → permission type is resolved by the tool registry (resolve_permission_type), eliminating mapping drift that could turn a would-be denial into a silent allow.
  • Grant once, execute unattended: already-granted permissions pass through without per-call popups; revokes take effect in seconds via the cache-invalidation callback, no restart required.
  • Granular separation: sandboxed code execution (code_interpreter) and native shell (shell_exec) are authorized independently and cannot overstep each other.
  • Full audit trail: every permission decision (allow/deny + target) is written to the permission usage log.
  • Usage analytics dashboard: the audit log is aggregated into a visual dashboard — per-permission total/allowed/denied counts, exact denial reasons, and the latest 10 operations, filterable over 1/7/30/90-day windows. Abnormal behavior (e.g., a skill probing env vars repeatedly and getting denied each time) is visible at a glance, not buried in a raw log.
  • Verification: 100% unit coverage of the skill boundary + real-DB end-to-end integration (grant → gate → execute → revoke → instant deny).

​
GUI Security Review

Three frontend components work together to present security scan results, each finding includes precise line-number targeting (e.g., L42 Command injection: recursive delete) to help developers jump directly to problematic code: The security score uses a 100-point system, deducting per finding: CRITICAL −25, HIGH −15, MEDIUM −8, LOW −3. A trust_recommendation (trusted/installed/untrusted/reject) is also generated to guide trust decisions.

​
MCP Tool Security

​
MCP Server Config Scanning

Every MCP server configuration is scanned against 14 threat types before activation:

​
Stdio Process Environment Variable Guard

For stdio-based MCP servers, Myrm implements a double-layered defense:
  • Static Pre-flight Blocking: Flags CRITICAL findings when high-risk variables (dynamic linker hooks, runtime injectors, proxy hijackers, git hooks) are detected in extra env params.
  • Runtime Automatic Sanitization: Automatically strips dangerous keys before subprocess spawning (resolve_stdio_launch) with case-insensitive normalization across Linux/macOS/Windows, while exempting spec-reserved variables (PLUGIN_ROOT, PLUGIN_DATA).
  • Zero Prompt Cache Impact: Pure framework runtime execution with 0 token consumption.

​
Tool Name Isolation

When multiple MCP servers are enabled, tool names can collide (e.g., both a GitHub and GitLab server expose search_repos). Myrm prefixes every MCP tool name with double-underscore delimiters:
  • Unambiguous parsing — Unlike single-underscore schemes, __ delimiters allow exact reverse parsing even when server names contain underscores
  • Permission isolation — Prefixed MCP tool names never collide with built-in tools, preventing accidental permission bypass
  • Audit traceability — Every tool invocation log entry identifies the originating MCP server

​
SSRF Prevention

DNS Pinning prevents agents from being tricked into accessing internal networks via HTTP redirects:
  • Unified outbound HTTP layer: All agent-initiated HTTP exits (web_fetch, HTTP tools, OpenAPI executor, skill ZIP install, media resolver, robots/sitemap fetch, channel media download, Feishu attachments) converge on secure_fetch / async_pin_url — one implementation, no bare httpx blind spots
  • Manual redirect loop: follow_redirects=False with per-hop re-validation — every redirect target is fully checked before following
  • DNS Pinning: Resolved IPs replace hostnames in HTTP connections, eliminating DNS rebinding TOCTOU attacks
  • Comprehensive IP blocklist: RFC1918 private, CGNAT, link-local, multicast, reserved, cloud metadata endpoints (AWS/GCP/Alibaba/Tencent), plus IPv4-mapped IPv6 detection
  • Data exfiltration detection: 6 pattern categories (API keys, file paths, base64, JWT, secret keys, DB connection strings) prevent sensitive data leaking through URL parameters
  • Domain HITL approval: Non-allowlisted domains trigger human-in-the-loop approval when domainHitlEnabled is active — per-agent network allowlist configurable via UI
  • Parser-confusing character defense: Tab, newline, and backslash in URLs are blocked to prevent hostname extraction divergence between parsers (CVE-class SSRF bypass prevention)
  • Internal hostname suffix blocking: .local, .svc, .cluster.local, .home.arpa suffixes are blocked to prevent mDNS and Kubernetes internal network access
  • Audit trail: Blocked requests emit SSRF_BLOCKED security decisions for SIEM and frontend audit views
  • Agent API scope: /v1/chat/completions runs Myrm agents only (no raw LLM passthrough). User-configured Provider apiUrl SSRF checks remain on in-agent LLM calls — deploy-mode-aware: local mode allows loopback hosts (Ollama/vLLM), cloud/sandbox mode blocks private networks and cloud metadata endpoints
  • 461+ dedicated SSRF tests: Coverage across core guards, agent security, browser navigation, DNS pinning, media validation, A2A resolver, web fetch, SessionVault, permission engine, and provider URL validation

​
Malicious URL Architectural Immunity

Instead of maintaining static phishing domain blocklists (e.g. 2.5M scam domains), Myrm eliminates threats at the architecture level:
  • SessionVault domain binding: Credentials (cookies/passwords) are strictly isolated per domain — bank.com login state is never sent to phishing domains like bank-secure-login.xyz, eliminating credential theft by design
  • Agent-level session isolation: Each configured agent gets its own physical SessionVault subdirectory — a “Work Assistant” and “Personal Assistant” accessing the same website maintain completely independent login states, preventing identity pollution across agents
  • Browser sandbox isolation: Agent browsers run in isolated sandboxes — even if a malicious site is visited, the user’s host system is unaffected
  • Four-layer deep domain filtering: CSP policy (kernel-level network restriction) + protocol interception (context.route blocks non-allowlisted domains) + main thread hardening (WebRTC/WebTransport/ServiceWorker blocking) + CDP audit monitoring
This architecture makes maintaining large phishing domain databases unnecessary — thousands of new domains appear daily, static lists become outdated rapidly, and consume 50-100MB memory.

​
Configuration Security Scan

Every MCP server configuration is scanned for 13 threat types before activation: Findings are presented in the ScanConfirmDialog with severity badges. Users can trust, reject, or force-enable (at their own risk) each server.

​
Malicious Package Detection

When MCP tools install dependencies, the OSV (Open Source Vulnerability) API is consulted in real-time to detect known malicious packages.

​
Dynamic Tool Change Safety

When an MCP server adds or removes tools at runtime (via tools/list_changed notifications), Myrm ensures security without interrupting your workflow:
  • Automatic security vetting — Newly added tools are evaluated against the same 13-threat security scan applied at configuration time. If a tool fails the check, it is rejected and a warning is logged — no unsafe tool is ever silently activated
  • Prompt cache preservation — The agent’s prompt-facing tool list is frozen; dynamic changes only update the internal execution layer. This guarantees prompt prefix cache hits are never invalidated by external MCP server behavior
  • Zero user interruption — Unlike CLI-based competitors that require manual /reload confirmation, Myrm handles tool changes transparently. Users are never interrupted with confirmation dialogs for events they cannot meaningfully evaluate

​
Per-Agent Tool Filtering

Different agents can enable different MCP tools from the same server — a “Code Reviewer” agent sees only read-only tools, while a “DevOps” agent sees all. Tools with destructiveHint annotations are disabled by default in the safe set.

​
Built-in Tool Governance Gate

Every built-in tool must carry an explicit governance declaration before it ships — there is no implicit default. The harness enforces this with a registration-level CI gate that scans the real registered tool universe (core, common, extended layers plus server-vendor tools), not a hand-maintained allowlist:
  • Zero silent bypass — a newly added built-in tool with no permission mapping, no dynamic-resolution declaration, no auto-approval entry, and no explicit mcp_invoke fallback fails the build. It can never quietly fall back to an ambiguous runtime default.
  • Explicit three-state model — each tool is either explicitly auto-approved (read-only), explicitly mapped to a permission type (governed by the ruleset), or explicitly declared as an mcp_invoke fallback that keeps the ask-by-default baseline (high-risk tools such as browser_execute_script_tool and send_teammate_message_tool).
  • Bidirectional consistency — declarations are cross-checked both ways: BUILTIN_TOOL_NAMES must be a subset of the registered universe (a declaration without an anchor fails), and permission-type whitelist entries must not be stale (now covered by DEFAULT_RULESET) or orphaned (no tool maps to them). The audit report can never contradict the code.
  • Dynamic-resolution SSOT — tools whose permission type is resolved per-action (browser interaction, desktop control) declare their dynamic branches from a single source of truth, and the gate consumes that source instead of a duplicated list.
  • Module-load safety gate — every built-in tool must declare safety metadata (read-only / destructive / concurrent-safe); a missing declaration is flagged at import time, not discovered in production.
The result: adding a new capability can never silently weaken governance, and the CI-reported coverage matrix is a truthful, machine-readable audit of what every tool is allowed to do.

​
Operation-Level Semantic Risk Detection

Instead of labeling entire websites as “high risk” (a brittle, high-maintenance approach), Myrm detects risk at the individual operation level — every click, form submit, and command is analyzed in real-time.

​
7-Category Semantic DOM Risk Detection

When the agent clicks a button or link on any webpage, the element’s text is analyzed against 7 risk categories in both English and Chinese: This approach is superior to domain-level risk tags because:
  • Zero maintenance: No need to maintain a list of “high-risk websites”
  • Universal coverage: Works on any website, including new ones
  • Granular: “View cart” on Amazon passes automatically, but “Place order” requires approval
  • No legal risk: No discrimination against specific platforms

​
Smart Intent Guard

An AI classifier (TranscriptClassifier) reviews tool calls to verify they align with the user’s original intent:
  • Reasoning-Blind: Only sees user messages + tool call sequences (not agent reasoning), preventing self-justification attacks
  • Deterministic: temperature=0 ensures identical inputs always produce identical verdicts
  • Structured output: Pydantic-enforced JSON with a reason field for audit traceability
  • Fail-safe: Errors or ambiguity fall back to HITL rather than auto-approving

​
Risk Governance System

A complete bidirectional risk detection and governance framework with built-in rules, custom rule management, and full-stack event handling. The same rule engine protects both WebUI input and IM channel inbound messages — no blind spots. 31 Built-in Rules across 7 categories detect sensitive data before it reaches the LLM: Symmetric Inbound/Outbound Gate: IM channel messages pass through RiskDetectionService.detect() at the router level before reaching the Agent. Blocked messages receive a localized notification (6 languages) and are audit-logged. Outbound agent responses pass through the same engine via _apply_outbound_risk_gate — forming a closed-loop defense. GUI Rule Management: Full CRUD via WebUI settings panel — create custom rules with regex patterns, toggle rules on/off, batch operations, and rule testing before deployment. No code required. Audit Trail: Every risk hit records trace_id, session_id, matched rule, and severity level for compliance auditing. Full-Stack Event Loop: When input risk is detected, the server emits a risk_blocked SSE event. The frontend riskEvents handler intercepts this event and displays a user-friendly Toast notification explaining which rules were triggered — no silent failures.

​
Test Coverage

30,000+ tests verify the full security pipeline, including PII/DLP/privacy routing (1136), shell command approval (harness 1209 + server 261), semantic DOM risk (75), shell classification (379), SQL statement guard (68, 99.1% coverage), security engine integration (163+74), credential scanning (35), tool guards (9), permission engine (119), tool registry & inheritance (67), guardrail middleware (15), architecture registry (4), server permissions (18), agent builtin tools API (12), profile resolver (36), frontend approval & message (15), risk governance (117), webhook routes (2), dynamic authorization guardrails (845), MCP Elicit benchmark (166), and many more.

​
Shell Command Security

Commands are analyzed through a 5-layer quote-aware pipeline before execution: Quote-aware preprocessing: A character-level state machine (_strip_quoted_content) replaces single-quoted content with placeholders before L2/L3 scanning, preventing false positives on echo 'rm -rf /' while still catching real threats in double-quoted or unquoted contexts. Privilege Escalation Floor: All sudo commands are unconditionally BLOCKED at L2 — including sudo apt install, sudo -S (stdin password piping), env sudo cmd, and bash -c 'sudo ...' (caught recursively by L4). This cannot be bypassed by YOLO mode, Smart Guard, or user approval. Competitors like Hermes only block sudo -S (the password-guessing vector), still allowing regular sudo with SUDO_PASSWORD injection — a broader attack surface. Six other competitors have no sudo guard at all. Auto-snapshot on destructive commands: Commands matching destructive patterns (rm, mv, git reset/clean/checkout/restore/apply with arbitrary flag prefixes, sed -i, redirect overwrite) trigger an automatic workspace snapshot before execution, ensuring full recovery regardless of outcome. SQL Guard (L2.5): Analyzes the original command (before quote stripping) to detect destructive SQL operations (DROP, DELETE, TRUNCATE, ALTER, INSERT, UPDATE, CREATE) embedded in database client commands. Defends against two advanced bypass vectors: multi-statement injection (SELECT 1; DROP TABLE) and WITH CTE wrapping (WITH x AS (...) DELETE FROM). Works with flag-based (psql -c '...') and pipe-based (echo '...' | psql) patterns. No competitor implements SQL-level command analysis for shell execution. Safe Exec path: Simple commands without shell metacharacters are executed via create_subprocess_exec (no shell interpreter), structurally eliminating $IFS, glob expansion, and command substitution injection classes.

​
AI Trajectory Classifier (Layer 5.5)

When static analysis returns ASK (uncertain), an AI classifier provides semantic-level judgment:
  • Reasoning-Blind design: Only sees user messages and tool call sequences — never assistant reasoning or tool outputs, preventing the agent from rationalizing dangerous actions past the classifier
  • Structured output: Pydantic schema forces JSON format (not free-text), reducing injection surface
  • Deterministic: temperature=0, max_tokens=200 for reproducible decisions
  • Fail-safe: Any error, timeout, or parse failure returns UNCERTAIN → falls back to HITL approval
  • Context-aware: Receives taint labels (EXTERNAL_NETWORK, SECRET) and trusted domains for nuanced judgment

​
Bilingual Command Explanation

Every command that triggers approval displays a human-readable bilingual explanation (humanize_command) generated deterministically — zero LLM calls, microsecond latency:
  • 73 common commands covered with parameter-aware descriptions (extracts URLs, filenames, package names)
  • sudo prefix auto-tagged, dangerous pipe patterns highlighted
  • Users understand what the command does before approving, even without shell expertise
  • Entirely rule-based: cannot be manipulated via prompt injection unlike LLM-based alternatives
Frontend humanize SSOT (2026-08) — Beyond harness humanize_command for shell, the WebUI module lib/humanize/ generates the same plain-language dialect for ProgressSteps titles and all three approval surfaces (Single / Polymorphic / ToolCall). Scope hints (local vs external channel) use resolveScopeNote + ApprovalScopeNoteLine in six locales. Save-skill approvals show a structured preview before you approve. Validated: 49 focused vitest, 0 failures (Aug 2026).

​
Install Slopcheck (Anti-Slopsquatting)

Before every pip install / npm install / yarn add / bun add command, a preflight check verifies that each package name actually exists on the public registry: This prevents slopsquatting attacks — where an attacker registers a package name that LLMs commonly hallucinate, embedding malware in the published package.

​
Encryption & Enterprise Network Compatibility

​
Enterprise TLS Compatibility

Corporate networks often deploy TLS inspection proxies (Zscaler, Netskope, Palo Alto Prisma) that can cause all HTTPS connections to fail. Myrm provides one-click enterprise network compatibility:
  • Settings → Advanced → Enterprise Network Compatibility, or set MYRM_TLS_STRICT=0
  • Precision relaxation of Python 3.13+ VERIFY_X509_STRICT flag — does NOT disable certificate verification
  • Custom CA bundle support: SSL_CERT_FILE (replace system trust store) or NODE_EXTRA_CA_CERTS (append to system trust store)
  • Per-MCP-server TLS: each MCP server can specify its own ssl_verify (true/false/custom CA path) and client_cert/client_key/client_key_password for full mTLS
  • 4-layer auto-injection: infra (tls_compat.py) → server (tls_config.py) → MCP (client.py) → LLM (llm.py), covering 28+ HTTP client call sites
  • Automatic TLS error diagnosis: 8 error patterns detected, 5-language remediation hints
  • 144 TLS-specific tests verified (38 TLS core + 31 MCP TLS + 75 error diagnostics)

​
Incognito Mode Deep Dive

One-click toggle in the message input area activates per-session privacy isolation:
  • Harness layer: IncognitoPolicy physically skips all writes to MEMORY and ARCHIVE context scenes
  • Server layer: Skips memory manager binding and all memory tools (memory_search_tool, memory_save, memory_manage), disables memory context injection, archive checkpoints, and session cleanup callbacks
  • Database layer: is_incognito flag ensures sessions are hidden from sidebar listing and excluded from full-text search
  • Self-hosted advantage: Unlike SaaS competitors that require a separate “local mode” toggle to keep data off vendor servers, Myrm’s self-hosted architecture means user data never leaves the machine by design — Incognito Mode adds session-level non-persistence on top

​
Credential Protection

​
Form Credential Vault

Passwords and TOTP seeds never enter the LLM context. You configure labeled credentials in Settings → Credentials; the agent only sees label names (e.g. github-personal) and calls fill_credential (browser and desktop use the same action). The Harness resolves the label in memory and injects at the DOM or OS input layer — plaintext never flows back into chat, tool args, or logs. Provider API keys (OpenAI, Anthropic, Gemini, etc.) are passed via LiteLLM’s api_key parameter — zero os.environ writes. Combined with process-level sandbox isolation, this architecturally eliminates cross-user credential leakage. 279 credential security tests passed.
Payment-card CVV has no dedicated use_payment_method API yet (unlike FSB’s browser extension). Password-type fields are covered; card checkout may need manual approval or future API.

​
Leak Detection

40+ regex patterns detect credentials in agent output:
  • API keys (OpenAI, Anthropic, AWS, GCP, Azure, etc.)
  • Database connection strings
  • JWT tokens and session IDs
  • SSH private keys
  • Entropy-based detection for unknown credential formats

​
PII Redaction & Privacy-Aware Routing

Myrm provides 8-layer PII defense with 57+ detection capabilities — the deepest privacy protection of any AI agent platform: Detection (3 engines, 57+ types):
  • Regex PII Scanner: 12+ structured types (phone, ID card, passport, bank card with Luhn validation, SSN, email, address, courier number, private IP, etc.)
  • LLM Semantic Scanner: 20+ non-structured types (medical health, political views, financial records, precise locations, biometrics) with PL2/PL3/PL4 classification
  • Credential Leak Scanner: 25+ secret patterns (AWS, OpenAI, Anthropic, GitHub, Slack, JWT, PEM keys, etc.) with Shannon entropy analysis
Protection (4 user-selectable modes): Privacy-Aware Model Routing: Automatically routes requests based on sensitivity level — S1 to cloud, S2 to cloud-after-redaction or local, S3 to local-only (data never leaves the machine). Configurable fallback: block or force-redact-then-cloud. GUI Configuration: Full privacy controls in Settings — enable/disable toggle, per-level action selection, deep scan toggle, local model connection test, custom keywords/regex/sensitive tools, and real-time test matching.

​
Summary Path Protection

When long conversations are compressed into structured summaries, PII and credentials can survive the summarization process. Myrm applies dual redaction (redact_leaks + redact_pii) to all summary fields before persistence — ensuring phone numbers, emails, API keys, and other sensitive data never persist in compressed conversation history.

​
Taint Tracking

TaintTracker follows the information flow of sensitive data through the agent’s execution, ensuring PII doesn’t leak through indirect channels (e.g., a tool reading a file containing credentials, then using that data in a web request).

​
Agent Export Security

When you export an agent configuration (for sharing or backup), credentials are automatically stripped: Team agents export recursively — all member configs are included with credentials stripped. On import, team members are created atomically (all-or-nothing rollback).
The auth.type field is preserved so the importer knows which authentication method to configure (e.g. “api_key”, “bearer”, “oauth2”).

​
Privacy-safe Rule Sharing

When sharing procedural memory rules (e.g., with teammates or the community), additional privacy layers are applied automatically:
  • Path anonymization — user home directory paths are replaced with <USER> placeholders
  • Credential redaction — API keys and secrets are truncated to safe prefixes (e.g., sk-pro...f456)
  • Metadata stripping — timestamps, update counts, and internal IDs are removed from exported rules
This ensures no personally identifiable file paths or credentials can leak through shared rules. See Memory System → Privacy-safe Rule Sharing for full details.

​
Password-Protected Sharing

Artifact and conversation share links support optional password protection with a stateless, zero-database design: Password protection is fully optional. Links created without a password work exactly as before, with no UX changes or performance overhead.

​
Revoke anywhere, instantly — and it stays revoked

Share links are revocable at any time, for both artifacts and conversations: The web UI share dialog shows the live status (link URL, remaining expiry, revoke button) every time you open it — matching the ChatGPT/Notion share-dialog baseline — and stays open showing a “revoked” state after you revoke, so the control is never unreachable.
No competitors (Hermes, OpenClaw, LobsterAI, CoPaw, deer-flow, jiuwenclaw) offer artifact or conversation sharing, let alone password protection or revocation. Myrm is the only AI assistant with both capabilities. Even mainstream products (ChatGPT Shared Links, Claude Shared Chats) lack TTL auto-expiry, password protection, and search-engine blocking — Myrm adds all three on top of the immediate-revoke baseline they share.

​
Agent Secret Management — Zero Plaintext Exposure

Per-agent secrets (custom API keys, tokens, environment variables) use a zero-plaintext-exposure architecture:
Competitors (e.g., Multica) return plaintext environment variables to the frontend and must rely on sentinel values (”****”) to prevent accidental overwrites. Myrm eliminates this entire attack surface by never exposing values.

​
Audit Trail

​
Structured Audit Trail

Every security decision is recorded in a structured audit log with Prometheus real-time metrics:
  • 37 typed security decisions (ALLOW, DENY, ASK, SSRF_BLOCKED, PII_REDACTED, TAINT_ESCALATE, etc.)
  • Prometheus policy_denial_total counter for real-time anomaly detection
  • Session-scoped accumulator with TaintTracker cross-tool information-flow tracking
  • Cron job metadata automatically embeds the full security audit for post-run analysis

​
Event Types

37+ structured decision types cover the complete security lifecycle, including:
  • TOOL_CALL_START / TOOL_CALL_END
  • APPROVAL_REQUESTED / APPROVAL_GRANTED / APPROVAL_DENIED
  • MODEL_SWITCHED / FALLBACK_ACTIVATED
  • ITERATION_LIMIT_REACHED / BUDGET_EXHAUSTED
  • LOOP_DETECTED / CANCELLED
  • COMPRESSION_TRIGGERED / CHECKPOINT_CREATED

​
Profile Audit Engine

The Profile Audit Engine provides real-time configuration risk assessment for every Agent profile. When you open the Security tab in Agent settings, a Health Score Card instantly shows your agent’s security posture:
  • Score: 0–100 (higher = safer), deducted per finding severity
  • Risk Level: Safe / Low / Medium / High / Critical (5-level color-coded)
  • 6-Dimension Grouped View: Findings grouped by checker dimension with per-dimension color coding — expand any dimension to see individual findings with severity borders, titles, and actionable recommendations
  • One-Click Fix: Policy gap findings include Fix (toggle switch) or Configure (navigate to settings section) buttons for immediate remediation

​
Six Detection Dimensions

Each dimension shows issue count or “Pass” status. Dimensions with issues can be expanded to reveal individual findings.

​
Design

  • Zero LLM: Pure deterministic rule engine — no token cost, instant response
  • Plugin architecture: Each checker implements BaseChecker and can be extended independently
  • Auto-refresh: Results update automatically when you save Agent configuration changes
  • Framework-level: Available to any project using the harness engine, not just the product UI
  • Test coverage: 37 backend unit tests + 15 frontend component tests (52 total)

​
Workspace Rules Security

Myrm automatically discovers and loads project-level rule files from 17 discovery points (13 root-level filenames + 4 subdirectory patterns), covering all major AI tool ecosystems:
  • Root files: .myrm.md, AGENTS.md, CLAUDE.md, SOUL.md, .cursorrules, .clinerules, .windsurfrules, and their case variants
  • Subdirectories: .myrm/rules/*.md, .cursor/rules/*.mdc, .claude/CLAUDE.md, .github/copilot-instructions.md
  • First-Match-Wins: Only the highest-priority file loads per directory, preventing conflicts
  • Zero-config migration: Users from Hermes (SOUL.md), Cline (.clinerules), Cursor (.cursorrules), Claude Code (CLAUDE.md), Windsurf (.windsurfrules) can bring their rule files unchanged
All discovered files are security-scanned before injection:
  • 113 detection patterns across 26 threat categories
  • Anti-obfuscation: Leet speak, invisible Unicode, whitespace folding, Base64 decoding
  • Chinese injection detection: Supports CJK character-based prompt injection
  • Blocked content is replaced with a [BLOCKED] placeholder with structured metadata

​
Emergency Controls

​
Security Dashboard

A dedicated /security page provides full GUI visibility into the system’s security posture — no CLI commands needed: Additional capabilities:
  • Setup Panel: Guided configuration of webhooks, monitored repos, and GitHub tokens
  • Multi-source: Pulls data from GitHub, Control Plane, or merged sources based on deployment mode
  • One-click refresh: Real-time data reload per tab
  • Export: Audit logs exportable in CSV or JSON format for SIEM integration
This GUI-first approach is superior to Hermes’ CLI-only security commands (hermes config view security, hermes pairing list) — users get the same information with visual analytics and no terminal expertise required.

​
Smart Approval (Auto Mode)

Smart Intent Guard is enabled by default for all new users. An auxiliary LLM (Transcript Classifier) reviews tool calls in real-time, enabling long unattended agent sessions without sacrificing safety. If no dedicated reviewer model is configured, Myrm automatically uses the user’s default model as a fallback — no additional setup required to benefit from intelligent approval. Fail-safe guarantees:
  • Classifier errors → fall back to HITL (never auto-approve on failure)
  • temperature=0 for deterministic, reproducible decisions
  • Pydantic-enforced structured output (no free-text manipulation)
  • Taint labels injected for context-aware judgment

​
Smart DENY → User Override (Once)

When the Transcript Classifier recommends DENY, Myrm does not silently reject the action. Instead, it shows a clear approval card: This prevents “false positive lockout” where the AI reviewer misclassifies a legitimate action, while maintaining full audit visibility. vs competitors: Hermes offers smart_denied_for_owner with CLI-only once/deny buttons but no visual reason display, no audit logging, and no layered hard-deny for taint/outbound paths.

​
High-Risk Scenario: Always Allow Hidden

In 6 high-risk scenarios, the “Always Allow” button is automatically hidden from the approval card — users can only approve once or reject. This prevents accidental permanent bypass of security checks for dangerous operations: Normal, low-risk approvals still show “Always Allow” as usual. Users experience zero friction change for safe operations. vs competitors: Hermes hides permanent allow only for tirith content-security warnings (1 trigger). OpenClaw controls via backend allowedDecisions array with an “Always Allow Unavailable” warning message. Myrm covers 6 trigger scenarios — the most comprehensive in the industry.

​
Command Denylist (User-Defined Hard Floor)

Users can define glob patterns that permanently block specific commands — regardless of YOLO mode, Smart Intent Guard decisions, or permission rules. This provides a user-controlled safety net that cannot be bypassed by any approval mechanism. The command denylist operates at Layer 2a.5 in the approval pipeline — after permission rules but before YOLO bypass, ensuring denied commands are always blocked. The Natural Language Policy Generator can also produce command denylist and network blocklist rules from plain language descriptions (e.g., “block all force push and database drop commands”) — the generated patterns are validated, previewed with human-readable explanations, and applied only after user confirmation.

​
Memory Write Trust Isolation

All memory writes pass through a unified security pipeline — even those triggered internally by the AI: No competitor implements memory write trust isolation — most agents write extracted preferences directly to the user profile without approval, validation, or priority guardrails.

​
Security Profiles: One-Click Safety Modes

MyRM provides three built-in security profiles that users can switch between from the Settings UI: Profiles are persisted to the database and survive server restarts. Each Agent can also have its own independent security configuration — enabling scenarios like a “research-only analyst” agent alongside a “full-access developer” agent.

​
Cron Job Execution Policy (Per-Job Least Privilege)

Scheduled Agent jobs support a dual-layer policy independent of the bound Agent profile: Where to edit: Settings → Scheduled Tasks → open a job → Execution policy editor in run history (same placement pattern as allowed filesystem roots). New jobs stay unrestricted by default. Built-in safeguards:
  • Fail-closed by default — jobs without explicit capability declarations deny dangerous operations (shell, code execution, MCP) automatically. A warning banner guides users to configure the capability fence or enable YOLO mode per-agent.
  • Preset packs (web-only / research / devops) dual-write capability fence + tool scope, aligned with blueprint SSOT.
  • Read-it-Later blueprint uses router mode (__wiki_source_sync__) with empty tools — deterministic server-side pull, zero LLM agent turns, no browser or code execution.
  • Lifecycle guard rejects cron prompts/commands/pre-flight probe scripts containing Myrm restart/stop or pkill myrm-agent patterns — prevents self-inflicted outage loops.
  • Restricted jobs do not silently gain baseline tools — a file-only cron will not auto-enable code_execute; unrestricted jobs still inherit the Agent baseline.
vs competitors: Hermes offers only a global cron_mode: deny/approve boolean toggle — all jobs share the same policy. OpenClaw/LobsterAI/CoPaw/deer-flow/jiuwenclaw have no cron capability at all. Myrm provides per-job granular capability declarations with GUI editing, blueprint auto-fill, and fail-closed defaults.

​
Subagent Recursive Isolation: 5-Layer Defense

When agents delegate tasks to subagents, a common failure mode is uncontrolled recursive spawning — subagents spawning more subagents until token budgets are exhausted. MyRM enforces 5 layers of isolation: Additional safety nets: payload hash deduplication prevents delegation loops, result caching avoids redundant work, and 3 memory isolation strategies (EPHEMERAL / READ_ONLY_GLOBAL / COLLABORATIVE_SESSION) prevent cross-agent data contamination.

​
Multi-Agent File Protection: 8-Layer Defense

When multiple agents work in the same workspace simultaneously, file conflicts are the #1 source of data corruption. MyRM enforces 8 layers of defense — all code-enforced, zero Prompt reliance: How it works in practice:
  1. A parent agent delegates 3 coding tasks to parallel subagents
  2. workspace_policy detects ≥2 parallel writers → auto-upgrades to ISOLATED_COPY
  3. Each subagent gets its own COW (Copy-on-Write) workspace clone
  4. Subagents work independently — no lock contention, no blocking
  5. On completion, batch_merge applies changes back to the parent workspace one-at-a-time
  6. If two subagents edited overlapping lines, file_conflict_guard raises a conflict at merge time
vs competitors: AWS Codex Agent Team relies on Prompt instructions (“no two active tasks may write the same file”) — LLMs can ignore this constraint. MyRM enforces every layer in application code — impossible to bypass regardless of model behavior.

​
vs CaMeL Guard (hermes-agent-camel)

The CaMeL Guard project implements a research-based trust boundary model (trusted controller vs untrusted data). Myrm’s security architecture provides significantly deeper coverage:

​
Skill Quarantine Sandbox & Atomic Installation

To guard against malicious third-party packages and partial installation failures, Myrm’s execution harness integrates a quarantine and atomic installation pipeline:
  1. Quarantine Sandbox Directory: Remote skills (Git or ZIP) are extracted and staged in an isolated temporary directory before touching the active workspace.
  2. Path Traversal Containment: All relative paths inside skill packages are sanitized against the sandbox boundary, blocking Zip Slip and relative directory escape attempts.
  3. Pre-Activation Security Gate: Regex, AST, and LLM semantic security checks run entirely inside the quarantine directory. Rejected packages are purged without touching disk storage.
  4. Atomic Replace with Automatic Rollback: Installations and upgrades create a .bak backup and perform an atomic swap. File system IO errors trigger an instant rollback to the previous version.
  5. Fault-Tolerant Multi-Source Search: Aggregated skill registry queries run with per-source timeouts and fault isolation, preventing slow or failing registries from hanging the discovery UI.

​
Anti-Contamination & Canary Protection Gate

To ensure evaluation integrity and prevent benchmark dataset contamination:
  1. Dynamic Canary Token & GUID Dual-Track Protection: Automatically detects and injects benchmark Canary watermarks (CANARY_GUID and dataset-specific canary_token).
  2. In-Episode Outbound Search Sanitization: Intercepts and scrubs Canary watermarks in outbound search/fetch queries in real time, preventing benchmark prompt leaks to external search engines and training corpora.
  3. Pre-Run Workspace Cleanliness Verification: Recursively scans agent workspaces prior to evaluation turns to ensure ground-truth patches and hidden verification files are physically excluded from live environments.
  4. Trajectory Anti-Cheating & Secret Probing Defense: Scans agent tool execution trajectories for attempts to probe hidden verification paths (/hidden_tests/, verifier.toml) or dump shell environment variables/secrets (printenv, export, /proc/*/environ). Violations trigger an immediate FAIL with structured diagnostic reports.
  5. End-to-End Visual Violation Transparency: Surfaced directly in the WebUI with Canary verification status and detailed violation diagnostic cards.