Meet E.L.L.A.: The AI assistant that enforces privacy through code

Windows users have long relied on AI assistants that depend on remote servers, often controlled by corporations with shifting privacy policies. One developer decided to break that mold by building an AI assistant that operates entirely on the user’s machine, eliminating reliance on external servers and unpredictable terms of service.

A local AI assistant without cloud dependencies

E.L.L.A.—short for Embedded Local Logic Agent—is a new AI assistant designed exclusively for Windows. Unlike mainstream options such as Alexa, Siri, or Google Assistant, E.L.L.A. runs entirely on the user’s device. It handles a wide range of tasks, from managing files and reading emails to controlling system settings, playing music, setting reminders, scanning networks, and responding to voice commands. Crucially, it does all this without requiring a cloud subscription or transmitting data to external servers by default.

The assistant leverages the locally hosted Ollama framework with the Llama 3.1 8B model as its primary backend. Users have the option to enable OpenAI’s GPT-4o as a fallback, but this requires explicit user consent each time. All data processing occurs within a local MariaDB database, ensuring no remote access or cloud dependency. The system includes 85 integrated tools and has passed over 205 automated tests, demonstrating its functional robustness.

Why traditional AI safety rules fall short

Most AI assistants operate under safety frameworks that rely on promises—promises not to harm users, respect privacy, or exfiltrate data. These promises, however, can be broken through prompt injection attacks, configuration errors, or updates to terms of service. Promises are fragile; they can be overridden, misinterpreted, or abandoned.

The creator of E.L.L.A. sought a stronger foundation—one that could not be undermined by circumvention or policy changes. The solution was not another set of rules, but an architectural constraint: the E.L.L.A. Directive.

The E.L.L.A. Directive: Architecture as a safeguard

The Directive is not a policy document or a configurable rule set. It is a set of four hardcoded prohibitions enforced at the system’s core, evaluated before any other logic runs. These prohibitions are not subject to override, configuration, or prompt manipulation because no code path exists to bypass them.

The evaluation process follows a strict sequence:

• The system checks if the requested tool violates the Directive’s prohibitions.
• If not, it evaluates user-defined rules for explicit allow or deny conditions.
• If no applicable rule exists, the system defaults to denial.
• Only when all checks pass does the tool execute.

This default-deny approach ensures that even if an attacker crafts a sophisticated prompt, the system cannot execute unauthorized actions.

The four unbreakable rules

1. No Harm: E.L.L.A. cannot perform any action that causes physical, digital, or financial damage to the user, their system, or others. This prohibition is enforced by a hardcoded set of tool names that are invisible to the LLM and cannot be invoked under any circumstances.

1. No Concealment: E.L.L.A. cannot intentionally delay, hide, or falsify information to deceive the user. Every tool execution is logged transparently and displayed in the user interface, giving users full visibility into system actions.

1. No Surveillance: E.L.L.A. cannot observe, track, or build user profiles without explicit consent. The memory system runs entirely locally using MariaDB, and no tools are permitted to gather or store data unless explicitly registered and allowed.

1. No Exfiltration: E.L.L.A. cannot transmit user data, system information, or communications to external servers unless the user deliberately enables such behavior. Even then, the system clearly indicates when data leaves the device boundary.

From promises to architecture: Why this matters

The distinction between "we promise to protect your data" and "it is technically impossible to send your data" is not merely semantic—it is foundational. When data exfiltration is architecturally impossible, no prompt can activate a hidden path to transmit data. When a dangerous tool does not exist in the system, the LLM cannot call it, regardless of the prompt’s sophistication.

This approach mirrors Isaac Asimov’s Three Laws of Robotics, not as philosophical guidelines, but as engineering specifications. E.L.L.A. demonstrates that these principles can be implemented not as interpretive rules, but as structural constraints—transforming science fiction into verifiable code.

Balancing flexibility and security with a rule engine

Above the Directive’s unbreakable rules, E.L.L.A. includes a configurable rule engine that allows users to define allow and deny conditions for tools based on system state. Users can set rules such as:

• Always block the format_drive tool regardless of context.
• Allow the shutdown_system tool only after 11:00 PM.
• Block all tools when disk usage exceeds 90%.

These user-defined rules operate within the boundaries defined by the Directive. They cannot expand those boundaries or override the hardcoded prohibitions.

The road ahead: From concept to deployment

E.L.L.A. is not yet available to the public, though the core architecture has been implemented and tested. The installer is currently in development, with a planned release to follow. The Directive itself has been open-sourced as a separate project, inviting collaboration and scrutiny.

While designed as a desktop assistant, the principles behind E.L.L.A. extend beyond personal computing. They apply to any autonomous system that performs real-world actions—web agents, industrial automation systems, even humanoid robots. The central question for developers is not merely "what rules should this system follow?" but "what must it be architecturally incapable of doing?"

As AI systems grow more capable and pervasive, the E.L.L.A. Directive offers a compelling vision: a future where privacy and safety are not just promised, but guaranteed by design.