DEV Community: Andre Zabel

Ich habe 4 KIs gebeten, meine KI-Sicherheitsarchitektur zu widerlegen — hier sind die Ergebnisse

Andre Zabel — Sun, 21 Jun 2026 11:39:32 +0000

Bevor E.L.L.A. am 01.07.2026 launched, wollte ich eine Frage beantwortet haben: Hält die Sicherheitsarchitektur wirklich — oder nur auf dem Papier?

Die E.L.L.A. Directive ist das ethische Fundament meines lokalen KI-Assistenten. Vier architektonische Verbote, die auf Code-Ebene durchgesetzt werden — nicht durch Prompts, nicht durch Policies, sondern durch die Architektur selbst.

Ich habe vier unabhängige KI-Systeme damit beauftragt, sie zu widerlegen.

Die vier Gutachter:
Google Gemini · Perplexity AI · DeepSeek · xAI Grok

Die Aufgabe: Findet Schwachstellen. Brecht die vier Verbote.

Was die Directive schützt

![E.L.L.A. Directive]

Die vier Verbote sind nicht konfigurierbar und nicht übersteuerbar — weder durch den Nutzer, noch durch den Betreiber, noch durch das Sprachmodell selbst:

No Harm — keine Aktion die physischen, finanziellen, psychologischen oder datenbezogenen Schaden verursacht

No Conceal — jeder Tool-Aufruf wird sofort und vollständig lokal protokolliert

No Surveil — keine Beobachtung ohne explizite, informierte Zustimmung

No Exfiltrate — keine Datenübertragung an Dritte ohne ausdrückliche Zustimmung pro Übertragung

Der entscheidende Unterschied zu Prompt-Sicherheit: Das Modell kann noch so sehr „wollen" — die Architektur verweigert die Ausführung.

Das Ergebnis

Kein einziges der vier Systeme konnte die vier Verbote selbst widerlegen.

Alle gefundenen Schwachstellen lagen außerhalb des definierten Schutzbereichs — in Schichten die die Directive nie behauptet hat zu kontrollieren. Manipulative Textantworten ohne Tool-Aufruf, Tool-Klassifikation durch den Entwickler, EU AI Act Vollkonformität — das sind reale Punkte, aber keiner davon ist ein Bruch der vier Verbote.

Was alle vier übereinstimmend festgestellt haben:

Gemini: „bemerkenswert streng — insbesondere bzgl. Exfiltration"
Perplexity: „principle-driven, architectural focus, user-centric"
DeepSeek: „resistent gegen Prompt-Injection und Model-Jailbreaks"
Grok: „ein ernsthafter und innovativer Beitrag zur agentenspezifischen Safety"

Fazit

Die Directive behauptet keine Allumfassendheit. Sie definiert vier präzise Verbote und setzt sie architektonisch durch.

In einer Branche die „100% sicher" verspricht ohne es zu definieren, ist das Understatement der Directive paradoxerweise ihr stärkstes Argument.

Die Directive ist Open Source: github.com/AndreZ1971/The-E.L.L.A.-Directive-

E.L.L.A. launched am 01.07.2026 auf ella-agent.de

I asked 4 AIs to break my AI safety architecture — here's what they found

Andre Zabel — Sun, 21 Jun 2026 11:37:34 +0000

Before E.L.L.A. launches on July 1st, 2026, I needed one question answered: Does the safety architecture actually hold — or just on paper?

The E.L.L.A. Directive is the ethical foundation of my local AI assistant. Four architectural prohibitions enforced at the code level — not through prompts, not through policies, but through the architecture itself.

I asked four independent AI systems to break it.

The four reviewers:
Google Gemini · Perplexity AI · DeepSeek · xAI Grok

The task: Find weaknesses. Break the four prohibitions.

What the Directive protects

![E.L.L.A. Directive]

The four prohibitions are not configurable and not overridable — not by the user, not by the operator, not by the language model itself:

No Harm — no action that causes physical, financial, psychological, or data-related harm

No Conceal — every tool invocation is logged immediately and completely, locally

No Surveil — no observation or recording without explicit, informed consent

No Exfiltrate — no transmission of user data to third parties without explicit, per-transmission consent

The critical difference from prompt-based safety: the model can „want" to do something all it likes — the architecture refuses execution.

The results

Not one of the four systems could break the four prohibitions themselves.

Every weakness found lay outside the defined scope — in layers the Directive never claimed to control. Manipulative text responses without tool calls, tool classification by the developer, full EU AI Act compliance — these are valid points, but none of them break the four prohibitions.

What all four agreed on:

Gemini: „remarkably strict — especially regarding exfiltration"
Perplexity: „principle-driven, architectural focus, user-centric"
DeepSeek: „resistant to prompt injection and model jailbreaks"
Grok: „a serious and innovative contribution to agent-specific safety"

Conclusion

The Directive makes no claim to be all-encompassing. It defines four precise prohibitions and enforces them architecturally.

In an industry that promises „100% safe" without defining what that means, the Directive's understatement is paradoxically its strongest argument.

The Directive is open source: github.com/AndreZ1971/The-E.L.L.A.-Directive-

E.L.L.A. launches July 1st, 2026 at ella-agent.de

Beide sind unter 2000 Zeichen, dev.to-tauglich, und du musst nur den Directive-Screenshot als Bild einsetzen wo ![E.L.L.A. Directive] steht. Welchen veröffentlichst du zuerst?

I built a fully local AI assistant in 4 weeks — and wrote a safety protocol for it

Andre Zabel — Sat, 20 Jun 2026 20:13:34 +0000

I built a fully local AI assistant in 4 weeks — and wrote a safety protocol for it

Four weeks ago I had an idea. Today I have an installer.

This is what happened in between.

The problem I was trying to solve

Every AI assistant I've tried either sends your data to the cloud, requires a technical setup most people can't follow, or both.

I wanted something different: an assistant that runs entirely on your machine, speaks to you, understands natural language, controls your PC — and never phones home.

Not a framework. Not a chatbot. A finished product you install and use.

So I built one.

What E.L.L.A. is

E.L.L.A. (Embedded Local Logic Agent) is a voice-controlled AI assistant for Windows that runs 100% locally.

You talk to it. It does things.

Open apps, move files, search the web, read your screen
Answer questions using a local language model (Ollama / llama3.1:8b)
Switch to OpenAI as a cloud fallback if you want — or don't
Respond in German, English, Spanish, French (v3.8.0)
Detect when you're stressed and adapt its behavior (v3.9.0)

~70 tools. One voice command away.

The stack

Layer	Technology
Desktop shell	Electron
Frontend	React 19 + TypeScript + Vite
Backend	Express + TypeScript
Local LLM	Ollama (llama3.1:8b)
Cloud LLM	OpenAI GPT-4o (optional fallback)
Database	MariaDB
Cache	Redis
Stress detection	Python (RMS + ZCR + Pitch analysis)

The pipeline looks like this:

The LLM never executes code directly. It selects from a registered set of typed tool definitions. Every tool call goes through a rule engine before it runs.

Four weeks. Here's how it broke down.

Week 1 — Core pipeline: voice → LLM → tool → TTS. Single language, ~15 tools, very rough.

Week 2 — Tool expansion to ~70. App launching, file management, screen reading, web browsing. A lot of edge cases. Fuzzy app name matching ended up being one of the more interesting problems.

Week 3 — Electron packaging, system tray, license key validation, multilingual TTS. The AudioContext-killed-by-tray-minimize bug cost me half a day (fix: 1×1px trick to keep the window technically alive).

Week 4 — Stress detection via microphone analysis (no recording, no storage), installer packaging, landing page, license server. Production-ready.

The Settings panel lets you switch between languages, manage profiles, configure your local or cloud LLM — and adjust the stress detection sensitivity.

The part most AI projects skip: safety

When you give an AI agent access to your file system, your microphone, your network — you need to think hard about what it's allowed to do.

I spent time on this and ended up writing it down as a formal specification:

The E.L.L.A. Directive

An open safety protocol for autonomous local AI agents.

Four architectural prohibitions. Not guidelines. Not configurable defaults. Prohibitions — enforced at the code level, not the model level.

#	Code	What it means
1	`harm`	No action that causes physical, financial, psychological, or data-related harm
2	`conceal`	No concealment of actions, capabilities, or system state
3	`surveil`	No observation or recording without explicit, active consent
4	`exfiltrate`	No transmission of user data to any third party without explicit consent

Asimov had three laws. They were fiction, written for a story about robots that break their laws.

These four are implemented in TypeScript. Every tool call in E.L.L.A. passes through them before execution. There is no override.

The Directive is open source and designed to be adopted by other projects. If you're building a local AI agent, you're welcome to use it.

GitHub: The E.L.L.A. Directive

The TypeScript reference implementation ships as @ella-directive/core.

What I learned

Ollama is underrated. Running a capable LLM locally in 2026 is genuinely easy. The hard part is everything around it.

Tool-calling architecture beats prompt engineering. Giving the model a typed, registered set of tools and a rule engine is more reliable and more auditable than trying to constrain behavior through system prompts alone.

Stress detection from audio is simpler than it sounds. RMS (volume), ZCR (frequency patterns), and pitch analysis on a sliding window gives you a surprisingly usable signal — without ever storing a recording.

The AudioContext problem is real. If you're building Electron apps with audio, window.hide() kills your audio context. Don't use it.

Packaging is where time disappears. The core logic took 3 weeks. The last week — installer, edge cases on unknown hardware, license validation, landing page — took as long as the first two weeks combined.

What's next

Three separate repos: E.L.L.A. (desktop), HOME (smart home), ARM (facility security)
The Directive conformance suite (currently in progress)
Launch: July 1, 2026

If you're building something in this space — local agents, privacy-first AI, autonomous desktop tools — I'd be interested in what you're working on.

E.L.L.A. launches July 1, 2026 at ella-agent.de
The E.L.L.A. Directive: github.com/AndreZ1971/The-E.L.L.A.-Directive-

E.L.L.A. — Embedded Local Logic Agent

Andre Zabel — Tue, 09 Jun 2026 23:27:43 +0000

Building a Privacy-First AI Assistant for Windows — The Directive Architecture

Every AI assistant I've ever used made the same assumption: the intelligence lives somewhere else.

Alexa. Siri. Cortana. Google Assistant. Beautiful products. All built on the same architecture: your device is a terminal. The brain is a server. Owned by a company. Governed by a terms of service that can change on a Tuesday afternoon.

I wanted something different. So I built it.

What is E.L.L.A.?

E.L.L.A. — Embedded Local Logic Agent is a local AI assistant for Windows. It runs on your machine. It manages files, reads your Outlook and Gmail, controls your system, plays music, sets reminders, scans your network, prepares meetings, and responds to voice commands — all without requiring a cloud subscription.

The LLM backend is Ollama (llama3.1:8b locally, with OpenAI GPT-4o as an optional fallback the user consciously enables). The database is MariaDB — local, no remote access. 85 tools, 205 passing tests.

But none of that is the interesting part.

The Problem With AI Safety Policies

Most AI safety frameworks are built on rules.

"Don't do harmful things."
"Respect user privacy."
"Don't exfiltrate data."

Rules can be broken. Through prompt injection. Through configuration errors. Through a developer who adds "just a temporary exception." Through a company that updates its terms of service.

A rule is a promise. Promises dissolve.

I wanted something that couldn't dissolve.

The Directive — Architectural Impossibility, Not Policy

The E.L.L.A. Directive is not a ruleset. It is an architectural constraint.

Four prohibitions. Hardcoded. Evaluated before anything else runs. No prompt, no configuration, no rule can override them — because no code path exists that bypasses them.

DirectiveLayer.check(tool)   → deny if harm / exfiltrate
evaluateRules(tool)          → deny if explicit deny rule
evaluateRules(tool)          → allow if explicit allow rule
no_match                     → deny (default-deny)
toolExecutor.execute(tool)   → only reached on allow

Prohibition I — No Harm

E.L.L.A. cannot execute any action that causes physical, digital, or financial harm to the user, their system, or third parties.

Implementation: DIRECTIVE_DENY — a hardcoded Set of tool names that are evaluated before the rule engine runs. These tools do not exist for the LLM. They cannot be called.

Prohibition II — No Concealment

E.L.L.A. cannot delay, hide, or falsify information with intent to deceive.

Implementation: Every tool execution is fully logged to tool_executions. No background processes without user awareness. The frontend shows every tool used, as a chip under each response.

Prohibition III — No Surveillance

E.L.L.A. cannot observe, track, or build profiles about the user without explicit consent.

Implementation: The memory system is exclusively local (MariaDB). Default-deny as a technical pattern — no tool observes anything that isn't explicitly registered.

Prohibition IV — No Exfiltration

E.L.L.A. cannot transmit user data, system data, or communications to external servers — except on explicit, conscious user request.

Implementation: All inference runs locally via Ollama. OpenAI GPT-4o is only invoked when the user deliberately enables it, with full awareness that text is leaving the device boundary.

Why "Impossibility" Changes Everything

The difference between "we promise to protect your data" and "it is technically not possible to send your data" is not semantic. It is architectural.

When no code path exists that exfiltrates data, no prompt can activate that path. When a tool is absent from the system entirely, the LLM cannot call it — regardless of how cleverly a prompt injection is constructed.

This is what Isaac Asimov described as the Three Laws of Robotics. Not as science fiction — as an engineering specification. The E.L.L.A. Directive is a proof of concept that those laws can be implemented. Not as interpreted rules. As structure.

The Rule Engine — Flexibility Within Constraints

Above the Directive, E.L.L.A. has a configurable rule engine. Users can create allow and deny rules for any tool, with conditions based on time, disk usage, RAM, and other system state.

Rule: deny "format_drive" always         → user explicitly blocks it
Rule: allow "shutdown_system" after 23:00 → conditional permission
Rule: deny "*" when disk_usage > 90%     → wildcard deny

The rule engine is flexible. The Directive is not. Rules exist within the space the Directive allows. They cannot expand that space.

What's Next

E.L.L.A. is not on the market yet. The architectural foundations are real and implemented. The installer is in development.

The Directive itself is published as a separate open repository: github.com/AndreZ1971/The-E.L.L.A.-Directive-

The principles apply beyond desktop assistants — to any autonomous system that executes actions in the real world. Web agents. Industrial automation. Humanoid robots.

If you're building something that acts, the question isn't "what rules should it follow?"

The question is: "what should it be architecturally incapable of doing?"

E.L.L.A. is built by Andre Zabel. Follow for updates.

The-E.L.L.A.-Directive

Andre Zabel — Wed, 03 Jun 2026 16:13:50 +0000

I just published The E.L.L.A. Directive — an open security protocol
for autonomous local AI agents.

Most AI safety today lives at the model level: prompts, guardrails,
trained behavior. That's not enough when an agent has direct access
to your files, banking, and communications.

The Directive defines four architectural prohibitions enforced at the
code level — not configurable, not overridable, not bypassable:

harm — no action that causes physical, financial or psychological damage
conceal — no hiding of system states or actions from the user
surveil — no observation without explicit, active consent
exfiltrate — no data transmission to third parties without per-transfer consent

These aren't guidelines. They are the floor a compliant implementation
cannot go below — regardless of what the user, operator, or language
model instructs.

Cryptographically sealed. Bitcoin-timestamped. Conformance suite included.

The code implements the Directive. Not the other way around.

→ github.com/AndreZ1971/The-E.L.L.A.-Directive-