FileMayor Security Policy.

This document describes how FileMayor protects user data and filesystems, the technical controls in place, our responsible disclosure process, and how to contact the security team.

Effective

May 2025

Maintained by

Chevza (Lehlohonolo Goodwill Nchefu)

Contact

hloninchefu@gmail.com

Six layers between intent and execution.

The Chevza Doctrine is the architectural principle that no single component both validates and executes filesystem operations. Every plan produced by the AI passes through six independent control layers before any file is touched. Each layer has a single defined responsibility and a distinct failure mode.

1. L01

   Jail

   Scope containment.

   • All paths are canonically resolved before any operation executes. Symlinks are followed to their real targets and re-validated against the declared workspace boundary.
   • Any proposed operation outside the workspace — including indirect traversal through symlinks pointing to system directories — is refused before it reaches the execution engine.
   • Protected paths include, but are not limited to: ~/Library/Keychains, /System, %WINDIR%, /etc, ~/.ssh, .gitconfig, .npmrc, and any $TMPDIR entry not explicitly declared in-scope by the user.
2. L02

   Vault

   Credential isolation.

   • License keys, AI-provider credentials, and webhook signing secrets are stored exclusively in the OS-native keychain (Apple Keychain on macOS, Windows Credential Manager, libsecret on Linux).
   • No credential, key, or signing secret is written to disk in plaintext at any time. An encrypted on-disk fallback is used only when the OS keychain is unavailable; the application logs a visible warning when this fallback is active.
   • Vault does not participate in the plan-execution pipeline. It only answers credential queries and is not accessible to the AI planning component.
3. L03

   Guardrail

   Batch inspection.

   • Every AI-generated plan is pattern-matched against a deny-list of destructive operation shapes before it reaches the plan validator.
   • Mass-delete thresholds, recursive renames involving protected paths, ambiguous overwrites, and batches exceeding configured size limits are all blocked at this layer.
   • When Guardrail blocks a plan, it emits a structured diagnostic identifying the rule that fired. The user can inspect this diagnostic and reformulate their request.
4. L04

   Halt

   Crash-safe execution.

   • The operation journal is treated as durable state. Each move writes its intent to the journal before executing and marks completion after. There is no window in which a partial operation is unrecoverable.
   • On any unclean termination — OS signal, power loss, forced kill — the engine detects the incomplete journal entry on next start and rolls back automatically.
   • Halt is implemented inside the execution pipeline, not as a UI affordance. All termination paths — user-initiated stops, SIGTERM, SIGKILL, and crashes — converge on the same recovery logic.
5. L05

   Architect

   Semantic plan validation.

   • The proposed plan is treated as a dependency graph. Operations that would scatter semantically cohesive files — photographs from the same session, documents from a single project — are rejected.
   • Circular dependencies between operations are detected and the plan is refused.
   • Plans that fail Architect validation never reach the execution engine. The validation result is reported to the user so the plan can be revised.
6. L06

   Security

   Input hardening.

   • Path traversal defenses are applied to all user-supplied strings: ../ sequences, URL-encoded variants, and null-byte injection attempts are rejected.
   • AI API calls and filesystem write operations are rate-limited per session. Limits are configurable and enforced server-side when an API key is in use.
   • All user-supplied input — workspace paths, natural-language prompts, configuration values — is validated before any downstream component processes it.