Trusting AI: How We Unlocked the Filesystem Safely

Giving AI Agents the Full Filesystem: Building Trust Through Security

The ai-agents project had hit a bottleneck. The virtual filesystem layer—the critical bridge between AI assistants and the codebase—was severely limited. Originally, it could only peek at three specific directories: plugins/, data/, and config/. No write access whatsoever. It was like giving a developer read-only glasses and asking them to build a house.

The task was clear: unlock the filesystem for the AI agents while keeping security ironclad. This meant building a complete toolkit with full project access, not just read permissions. The developer needed to implement write and edit capabilities—tools that the agents desperately needed to modify code, create files, and actually contribute to the project.

The approach was methodical. Instead of loosely opening the doors, the strategy was to create a three-layer security model. First came file_read—expanded to read any file up to 200KB anywhere in the project. Then file_write for creating and overwriting files, and file_edit for surgical find-and-replace operations within existing code. The fourth tool, directory_list, gained glob pattern support and recursive listing capabilities. But here’s where security came in.

Every single operation was chained through two safety validators. Path traversal attacks were neutralized using Python’s Path.resolve() and relative_to() methods, ensuring that no “../../../etc/passwd” tricks could escape the project root. Then came the blocklist—a hardcoded set of dangerous patterns that would always be rejected: .env files, anything with *.key or *.pem, filenames containing “secret”, “password”, or “credential”. Even .git/ and __pycache__/ directories were off-limits.

The implementation touched five critical files. The filesystem.py module was completely rewritten—the DEFAULT_ALLOWED_PATHS restrictions were ripped out and replaced with the new tools. Constants were added to constants.py for TOOL_FILE_WRITE and TOOL_FILE_EDIT. The initialization exports in __init__.py were updated to include the new classes. Integration work in core.py and handlers.py ensured the dispatch system knew how to route these new capabilities through the Telegram handlers.

What made this interesting was the philosophical choice: trust the security layer, not permission scarcity. Rather than limiting what paths agents could touch, the developer trusted that path validation and blocklisting would be enough. This meant agents could now inspect the entire codebase structure, understand dependencies, and make informed changes—which is exactly what you want from an AI that’s supposed to help.

Fun fact: The find-and-replace pattern in file_edit uses exact string matching rather than regex, which seems limiting until you realize it eliminates an entire class of regex-based injection attacks. Security through simplicity.

The filesystem module is now production-ready, passing all safety checks while giving AI agents the autonomy they need to actually contribute code changes. The next iteration will add collaborative locking—preventing multiple agents from editing the same file simultaneously.

Apparently, the only difference between this security model and a security researcher’s nightmare is one well-placed relative_to() check.

What to fix: - Punctuation: missing or extra commas, periods, dashes, quotes - Spelling: typos, misspelled words - Grammar: subject-verb agreement, tense consistency, word order - Meaning: illogical phrases, incomplete sentences, repeated ideas, inconsistent narrative - Style: replace jargon with clearer language, remove tautologies

Rules: - Return ONLY the corrected text, no comments or annotations - Do NOT change structure, headings, or formatting (Markdown) - Do NOT add or remove paragraphs or sections - Do NOT rewrite the text — only targeted error fixes - If there are no errors — return the text as is