Skip to content
FileMayorby Chevza
Download
Security · architecture reference

The Chevza Doctrine.

Six named layers between an AI plan and your filesystem. The principle: no single component decides, validates, and executes. Responsibility is split along the path so a failure in any one layer is caught by the next.

This page is the canonical reference. For a narrative version, see the essay.

Principle

Defense in depth, by name.

An AI proposing filesystem operations is a powerful tool and a credible threat. Useful because it generalizes; risky for the same reason. The Doctrine is the answer: the AI can propose, but cannot directly execute. There is always a boundary, and the boundary is layered, named, and inspectable.

When a plan flows from intent to execution, it passes through six checks. Each has a single responsibility, a code home, and a failure mode you can read.

The layers

Six checks, in order.

  1. L01

    Jail

    cli/core/jailer.js

    Constrains scope.

    • Symlink-aware sandbox. Resolves every path before any operation runs.
    • Refuses any move outside the declared workspace, including indirect paths through symlinks pointing to system directories.
    • Hard-blocked targets: ~/Library/Keychains, /System, %WINDIR%, /etc, ~/.ssh, .gitconfig, .npmrc, anything in $TMPDIR not explicitly opted in.
  2. L02

    Vault

    cli/core/vault.js

    Holds secrets.

    • OS keychain integration: Apple Keychain on macOS, Credential Manager on Windows, libsecret on Linux.
    • License keys, AI provider credentials, and webhook signing secrets never touch disk in plaintext.
    • Falls back to an encrypted on-disk store only if the OS keychain is unavailable, with a clear console warning.
  3. L03

    Guardrail

    cli/core/guardrail.js

    Inspects every batch.

    • Runs after the AI returns a plan, before the validator. Pattern-matches the proposed batch against a deny-list of destructive shapes.
    • Mass-delete thresholds, recursive renames touching protected paths, ambiguous overwrites, batches that exceed configured maxima — all blocked at this layer.
    • A failed Guardrail check produces a diagnostic that explains which rule fired and what to ask the AI for instead.
  4. L04

    Halt

    cli/core/emergency-halt.js

    Crash-safe persistence.

    • Treats the journal as durable state. Every move writes its intent to disk before the move happens, and writes its completion after.
    • Forced shutdown mid-operation always rolls back cleanly on next start. There is no "half-applied" state.
    • Halt is not a UI feature — it sits inside the execution pipeline so that user-initiated stops, OS signals, and process crashes all converge on the same recovery path.
  5. L05

    Architect

    cli/core/validator.js

    Validates the plan.

    • Refuses domain-scattering moves. Treats the proposed plan as a graph and rejects it if it would split semantically related files (e.g. screenshots from the same session, photos from a single trip).
    • Detects circular dependencies between operations.
    • Plans that fail validation never reach the execution engine.
  6. L06

    Security

    cli/core/security.js

    The boring layer that matters.

    • Path traversal checks (rejects ../ escape attempts, encoded variants, NUL bytes).
    • Rate limiting on AI calls and on filesystem writes per session.
    • Input validation on every user-supplied string — workspace paths, prompts, configuration values.
    • The layer with the fewest interesting decisions and the most consequential bugs if it ever fails.
What "0 runtime vulnerabilities" actually means

Runtime, not build chain.

When we say 0 runtime vulnerabilities, we mean: the three packages that ship to your machine and execute when FileMayor runs — electron-updater, tar, yauzl — have no published advisories at their pinned versions.

Build-time tools (Electron, Vite, esbuild, Rollup, TypeScript) are a separate category. They sit in the development dependency tree, run on the build machine, and never ship to your computer. GitHub Dependabot reports advisories for them too, and we patch them as part of routine maintenance — but a moderate audit on a build tool is not the same kind of risk as a runtime CVE. Conflating the two is how a tool ends up looking either too alarmed or too complacent.

You can verify the runtime claim yourself:

npm audit --production

That command audits production dependencies only. If it ever returns non-zero, this page and the homepage metric update the same day.

Honest scope

What we have not yet done.

The Doctrine is an architecture, not a certification. FileMayor has not been third-party audited at the time of writing. We treat that as a planned milestone, not an accomplished one. The 128-test suite covers Doctrine layers extensively (see tests/test-security.js and tests/MASTER_TEST_V3.js) and a third-party security review will update this page when complete.

Found a vulnerability? Email hloninchefu@gmail.com with the subject line [security]. Disclosure window: 90 days for high-severity reports. Coordinated disclosure preferred; we will credit you in the changelog if you wish.