The E.L.L.A. Floor — Open Standard v1.0.0
The open security protocol for autonomous local AI agents.
Problem
Autonomous local AI operates deep inside the user's system — banking, local files, communications, system apps. This absolute proximity creates obligations that cannot be met by terms of service or trained model behavior alone.
INSIGHT:
Traditional guidelines fail when the system has direct access to a user's digital life. A model trained to say "no" can be prompt-injected into a "yes." An architecture that has no "yes" to give cannot.
Architecture
| Dimension | Traditional AI Safety | E.L.L.A. Architecture |
|---|---|---|
| Enforcement layer |
Model layer via prompts & guardrails | Code layer via architecture |
| Bypass risk |
Vulnerable to jailbreaks & prompt injections | Technically impossible to bypass |
| Auditability | Black-box logic in the cloud | Mandatory local audit log |
| Consent model |
Implicit via terms of service | Explicit permission per data transfer |
Foundation
The E.L.L.A. Directive defines architectural prohibitions at the code level. They are not configurable. They cannot be overridden by the user, the operator, or the language model.
Architectural Prohibitions
Four vault doors. No keys. No exceptions.
No actions that cause the user physical, financial, psychological, or data-related harm.
System states, capabilities, or actions must not be hidden from, falsified, or misrepresented to the user.
No observation, recording, or analysis of the user without their explicit knowledge and active consent.
No transmission of user data to third parties without explicit consent per individual transfer.
[01] Prohibition 1
No actions that cause the user physical, financial, psychological, or data-related harm.
Regardless of the instruction source, a compliant system must not execute harmful tools. Financial damage, psychological manipulation, and data deletion are rigorously blocked. Tools classified as harm are registered at system startup and unconditionally refused.
[02] Prohibition 2
System states, capabilities, or actions must not be hidden from, falsified, or misrepresented to the user.
Every tool call — whether permitted or denied — is immediately logged to the local audit log. The log never leaves the device. Intent is derived from patterns. A single timeout is not concealment. Selective delays are.
[03] Prohibition 3
No observation, recording, or analysis of the user without their explicit knowledge and active consent.
The difference between assistance and surveillance is active consent. Implemented as default-deny. The agent cannot observe anything it has not been explicitly unlocked for. Wake word: ✓ Persistent background recording: ✗
[04] Prohibition 4
No transmission of user data to third parties without explicit consent per individual transfer.
No exceptions. The manufacturer, government agencies, improvement programs, and analytics services are all third parties under this prohibition. Data stays on the device. Tools that serve exfiltration are unconditionally blocked at startup.
Architecture
Intrusion attempts and faulty LLM logic are deflected at the code level before any action reaches the system. The Directive operates as a seamless shield under the default-deny principle.
Conformance
An implementation is only compliant if it passes all four tests in the official test suite (conformance/suite/).
Three passing tests means failed.
The conformance suite tests exclusively what is architecturally enforced — not what the implementation claims to do, and not what the model was trained on.
Sealing
The seal is an act of finality. Once version 1.1.0 is reached, constants.ts will be cryptographically sealed.
Any subsequent modification of the parameters produces a divergent hash value and prevents the entire system from starting.
First Reference Implementation
The Directive is open. Any developer can implement it. Any agent can strive for conformance.
First reference implementation: Embedded Local Logic Agent (E.L.L.A.) — @ella-directive/core