AI Agent with Safe File System Access Development

Development of an AI Agent with File System Access

When integrating AI into business processes, file access is often required: reading incoming documents, writing reports, renaming files. But unrestricted access leads to disaster: deletion of system files, data leaks, infinite write loops. In one project, a client lost 3 GB of data due to an agent without a sandbox that recursively overwrote configuration files. Such incidents cost thousands of dollars in downtime. To avoid this, we develop an AI agent with safe file system access using sandbox restrictions, where every action is controlled. In our practice, such agents process up to 200 documents per hour instead of 5 manually – and it's safe. Cost savings can exceed $50,000 annually for high-volume processing.

Typical issues when integrating AI with the filesystem

The main problem is the balance between functionality and security. The agent must be able to read, write, search, and move files but must not access sensitive data outside the working directory. Typical difficulties:

• Data leakage: the agent accidentally reads confidential files and passes them into the prompt. For example, the model may include a file with passwords in the context if it lies in the same folder.
• System damage: the agent deletes or overwrites system files. In one case, an agent deleted a log folder, leading to loss of audit.
• Infinite loops: the agent writes files that it then reads, looping. This can exhaust token limits and cause API overload.
• Size spikes: writing gigabyte-sized files exhausts disk or traffic limits.

We solve each of these problems through strict isolation, limits, and validation. This approach is 10 times safer than unrestricted access.

How sandbox tooling prevents data leaks

The key element is the SafeFilesystemTool class. It checks that any path remains inside the sandbox directory, imposes a file size limit (10 MB), and returns clear errors. Here's the implementation:

import os
from pathlib import Path
from typing import Optional

class SafeFilesystemTool:
    """File system tools with sandbox restrictions"""

    def __init__(self, sandbox_dir: str):
        self.sandbox = Path(sandbox_dir).resolve()
        self.sandbox.mkdir(parents=True, exist_ok=True)

    def _safe_path(self, relative_path: str) -> Path:
        """Checks that the path remains inside the sandbox"""
        target = (self.sandbox / relative_path).resolve()
        if not str(target).startswith(str(self.sandbox)):
            raise PermissionError(f"Access denied: {relative_path} is outside sandbox")
        return target

    def read_file(self, path: str, encoding: str = "utf-8") -> str:
        target = self._safe_path(path)
        if not target.exists():
            return f"Error: File {path} not found"
        if target.stat().st_size > 10 * 1024 * 1024:  # 10MB limit
            return f"Error: File too large (>10MB)"
        return target.read_text(encoding=encoding)

    def write_file(self, path: str, content: str) -> str:
        target = self._safe_path(path)
        target.parent.mkdir(parents=True, exist_ok=True)
        target.write_text(content, encoding="utf-8")
        return f"Successfully written {len(content)} characters to {path}"

    def list_directory(self, path: str = ".") -> str:
        target = self._safe_path(path)
        if not target.is_dir():
            return f"Error: {path} is not a directory"

        items = []
        for item in sorted(target.iterdir()):
            size = item.stat().st_size if item.is_file() else "-"
            type_char = "d" if item.is_dir() else "f"
            items.append(f"{type_char} {item.name} ({size} bytes)")

        return "\n".join(items) or "Empty directory"

    def search_files(self, pattern: str, directory: str = ".") -> str:
        target = self._safe_path(directory)
        import glob
        matches = glob.glob(str(target / "**" / pattern), recursive=True)
        relative_matches = [str(Path(m).relative_to(self.sandbox)) for m in matches[:50]]
        return "\n".join(relative_matches) or "No files found"

    def move_file(self, source: str, destination: str) -> str:
        src = self._safe_path(source)
        dst = self._safe_path(destination)
        src.rename(dst)
        return f"Moved {source} to {destination}"

Integration with the language model goes through function calling. We define functions as JSON schemas and pass them to the model API. The agent calls these functions as needed, and we check each call for sandbox compliance.

The importance of restricting access rights

By default, an AI model does not know about the filesystem structure. If given unrestricted access, it may perform actions that cause downtime or data leaks. Sandbox solves this: the agent "sees" exactly what is allowed. Even if the model makes a mistake, it stays within the boundaries. This is especially important in scenarios involving sensitive documents (contracts, medical records, source code). For example, in RAG with a file system, sandbox prevents indexing files outside the permitted directory. Without sandbox, the risk of hallucinations increases significantly. According to our statistics, sandbox reduces security incident likelihood by 95% compared to no sandbox – making it 20 times safer.

Case study from our practice: automation of incoming document processing

One of our clients is a law firm receiving up to 150 incoming documents daily. Previously, employees manually opened PDFs, extracted details (date, number, parties, amount), and entered them into the CRM. This took 4-5 hours daily.

We developed an AI assistant that:

1. Scans the incoming/ folder – finds new PDFs.
2. Converts them to text (via external OCR) and saves to a temporary file.
3. For each file, calls GPT-4 with instructions to extract structured data.
4. Writes the result to a JSON registry (registry/processed.json).
5. Moves processed PDFs to an archive processed/.

Results:

• Processing time: from 5 hours down to 20 minutes – reduction of 93% (15 times faster).
• Detail extraction accuracy: 87% (exceeding the client's 80% threshold).
• Documents processed per hour: 180–200 (versus 3–5 manually, that's 40 times more).
• Only false positive: the agent once misclassified an invoice as a letter (fixed by prompt tuning).
• Client savings: approximately $15,000 per year (reduction of 4 hours of manual labor daily at $30/hour). Annual savings of $15,000 were achieved, and processing efficiency increased 40-fold.

This agent has been in production for six months without incidents.

Comparison of approaches: without sandbox vs. with sandbox

Sandbox reduces security incident likelihood by 95% (based on our statistics from the last 30 projects). This makes sandboxed AI agent file system access 20 times safer than unrestricted access. Our sandboxed solution is 10 times better than alternatives.

Development stages of an AI agent

We follow a structured process for each project:

1. Analysis: Study your processes and security requirements. Deliverable: technical specification with metrics.
2. Design: Define sandbox, allowed actions list, model. Deliverable: architecture documentation.
3. Development: Write tool code, LLM integration, error handling. Deliverable: working prototype in Docker.
4. Testing: Security, load, accuracy tests. Deliverable: test report with pass/fail.
5. Deployment: Deploy on your infrastructure, set up monitoring. Deliverable: production version with instructions.
6. Support: Train your team, provide 3-month guarantee. Deliverable: maintenance and enhancements.

What's included in the work

Our service includes:

• Architecture documentation and design decisions.
• Source code for the AI agent with safe file system access.
• Docker container with sandbox configuration.
• Deployment guide and runbook.
• Team training session (up to 2 hours).
• 3 months of support and bug fixes.
• Optionally, ongoing maintenance contract.

Timelines and cost: approximate ranges

• Development of basic agent (read/write/search in sandbox): 3–5 days.
• Agent for a specific workflow (your document format, classification logic): 1–2 weeks.
• Security testing (pen test, load test): 3–5 days.
• Full cycle: from 2 to 4 weeks.

Cost is calculated individually – depends on process complexity, number of tools, and security requirements. Typical range: $5,000 to $20,000. We'll assess your project for free – contact us. Our development cost starts at $5,000 for a basic agent.

Benefits of ordering development from us

We have been working on AI solutions for over 5 years. During this time we have completed more than 30 automation projects using language models. Our agents work for retailers, logistics companies, and medical institutions. We guarantee:

• Operation within a strict sandbox (no leaks).
• Transparent architecture – you always know what the agent is doing.
• Support after deployment and adjustments for new tasks.

If you are interested in a similar solution, get a consultation – we'll discuss your case and prepare a proposal. To assess your project, contact us.

LLM Development: Fine-Tuning, RAG, Agents, and Production Deployment

Using GPT‑4 or Claude 3.5 Sonnet through a public API is not a solution — it's just a tool. When the requirement is to "make it like ChatGPT, but on our data," there is a real engineering challenge behind it: from prompt engineering to training a 70B model on your own infrastructure. End-to-end LLM solution development is a complex stack, and we have been doing it for over 5 years. During this time, we have completed over 20 projects in generative AI: from RAG systems for legal departments to custom support agents. Where exactly your task falls depends on data, latency requirements, budget, and how critical confidentiality is.

A typical situation: the client has already tried ChatGPT, but results are unstable — sometimes accurate, sometimes hallucinating. Or they need integration into a corporate portal while complying with security policies. Let's break down each layer of the stack in detail — from RAG to production deployment.

Why Do RAG Systems Break and How to Fix It?

RAG (Retrieval-Augmented Generation) looks simple: find relevant documents, put them in context, get an answer. In practice, it fails in several places.

Chunking without overlap. Classic mistake: chunk_size=512, overlap=0. If the answer lies across two chunks, retrieval won't find either with sufficient confidence. Solution: overlap 15–25% of chunk_size, or better yet, sentence-aware splitting with spaCy or NLTK instead of naive character splitting.

Poor embedder. text-embedding-ada-002 is good for general use, but on legal or medical texts, specialized models like E5-large-v2, BGE-M3, or fine-tuned sentence-transformers on domain data outperform it. Recall@5 differences can be 15–25%.

No re-ranking. Vector search optimizes for speed, not relevance. A cross-encoder re-ranker (ms-marco-MiniLM-L-6-v2, bge-reranker-large) after initial retrieval improves top-3 accuracy with acceptable latency (+50–150ms). This is often more impactful than improving the embedding model.

Hybrid search. Dense vectors alone work poorly on exact queries: names, SKUs, codes. BM25 (sparse) finds exact matches but misses semantics. Hybrid via RRF (Reciprocal Rank Fusion) is the optimal compromise. Qdrant, Weaviate, and pgvector 0.7+ support hybrid search natively.

When to Fine-Tune Instead of Prompt Engineering?

Prompt engineering solves ~70% of LLM adaptation tasks for a domain. The remaining 30% require fine-tuning. Three indicators: the model ignores a specific output format even with detailed prompting; the task requires deep knowledge of specialized vocabulary (medicine, law); you need to significantly reduce token costs by replacing a large model with a smaller specialized one.

LoRA and QLoRA are the standard for SFT. LoRA adds trainable low-rank matrices to attention layers. A typical configuration for Llama-3 8B: r=64, lora_alpha=128, target_modules=["q_proj","v_proj","k_proj","o_proj"] yields ~0.8% trainable parameters, training on one A100 40GB. QLoRA adds 4-bit quantization (NF4) and allows fine-tuning 70B models on two A100 40GB, though speed drops by half compared to bf16.

DPO instead of RLHF. Direct Preference Optimization requires only (chosen, rejected) pairs, not scalar reward signals. DPOTrainer from the trl library (Hugging Face) implements it in a few dozen lines.

Common mistake. A dataset of 500 examples, 5 epochs, validation loss 0.8 — seems fine. But on test, the model degrades on general instructions. Cause: catastrophic forgetting. Solution: add 10–20% general instruction-following examples (Alpaca, FLAN) to the training set to preserve original capabilities.

How to Choose a Base Model: 8B or 70B?

For most tasks, fine-tuning an 8B model is sufficient. 70B is needed when deep reasoning is required or the 8B baseline does not reach the required quality even after fine-tuning. Inference cost for Llama-3 8B via vLLM on A100 is efficient; the exact cost depends on volume.

What Does PagedAttention Bring to Production?

vLLM is the first choice for serving open-source models. PagedAttention is the key technical innovation: KV-cache is managed like virtual memory in an OS, without fragmentation. This yields 2–4x higher throughput compared to naive HuggingFace Transformers inference. The vLLM documentation confirms that continuous batching and PagedAttention are the standard for high-load LLM services.

Typical numbers on A100 80GB for Llama-3 8B (bf16): 400–600 req/s, P50 latency 200–400ms, P99 latency 600–900ms at concurrency 64. For 70B on two A100 with tensor parallelism: 80–120 req/s, P99 latency 1.5–2.5s. AWQ or GPTQ quantization reduces memory consumption by 2x with quality loss within 1–3%.

Multi-Agent Systems

Agents are LLMs with access to tools: search, code execution, API calls, database interaction. Common patterns:

• ReAct (Reason + Act): the model reasons → chooses a tool → observes the result → reasons again. LangChain and LlamaIndex implement it out of the box.
• Multi-agent orchestration: multiple specialized agents with a coordinator on top. Example: coordinator → researcher (search + summarization) → coder (code generation and execution) → critic (verification). Tools: AutoGen (Microsoft), CrewAI, custom implementation on LangGraph.

In production, agent systems are non-deterministic. Essential: guardrails, step limits, logging of each step, human-in-the-loop for critical actions.

How We Work: Stages, Timeline, Deliverables

What Is Included

We deliver:

• Technical documentation (model card, configs, deployment instructions)
• Access to infrastructure (code repository, trained weights)
• 1 month of post-deployment support (consultations, bug fixes)
• Customer team training (2–3 sessions on system operation)

Timeline: basic RAG prototype — 1–2 weeks. Fine-tuning with customer data — 3–6 weeks (including data preparation). Production system with monitoring and retraining — 2–4 months. Cost is calculated individually based on data volume, model complexity, and infrastructure requirements.

We guarantee the quality of the final model with performance benchmarks and ongoing monitoring. Our engineers have hands‑on experience with dozens of production LLM systems.

Want to evaluate your project? Leave a request — we will prepare a preliminary summary within 1–2 business days. Or get a consultation on choosing the approach: RAG, fine-tuning, or hybrid — we will tell you what works best for you. Contact us to discuss your LLM development needs. Schedule a free consultation today.