Security

Security Whitepaper

The Managed Sovereign Model — how ellul.ai proves trust instead of asking for it.

The Managed Sovereign Model

Core Philosophy

Most platforms hold the keys to your kingdom. We actively throw them away.

Most hosting platforms store your credentials, manage your access, and ask you to trust that no employee, breach, or rogue process will ever abuse that power.

ellul.ai takes a fundamentally different approach. We handle the billing and the hardware. But the authority — the cryptographic proof of who you are and what you're allowed to do — lives exclusively on your VPS and your device. We are the caretaker, not the landlord. If we disappear tomorrow, your server keeps running. If we get breached tonight, your data stays untouched.


The Core Promise: Don't Trust Us. Trust the Math.

Traditional platforms require you to trust a chain of people: the ops team, the support staff, the database admin, the vendor's vendor. ellul.ai replaces human trust with cryptographic guarantees wherever possible.

Chain of Trust

WhatTrust the VendorTrust the Math
Billing & Payments
Initial Server Setup
DNS Routing
Your Identity✓ WebAuthn + PoP
Command Integrity✓ HMAC SHA-256
Code Updates✓ GPG Signatures
Data Access✓ Zero-Knowledge
Command Execution✓ Proof of Possession

The left column is what every platform requires. The right column is what we moved out of our hands and into yours.


The Four Locks

ellul.ai's security architecture is built on four independent cryptographic guarantees. Each one eliminates an entire class of attack — not by making it harder, but by making it mathematically impossible.

1

Identity — WebAuthn + Proof of Possession

Tech

Non-extractable ECDSA keys in device secure enclave. PoP signatures over timestamp, method, path, body hash, and nonce.

Benefit

Phishing is impossible. Session hijacking is impossible. Even if our database is breached, your server cannot be accessed.

The Problem: Traditional platforms authenticate you with passwords or session tokens stored in their database. If that database is breached, an attacker can impersonate you.

Our Solution: ellul.ai's breach-safe modes use WebAuthn passkeys — the same technology behind Face ID and Touch ID. Your private key is generated inside your device's secure enclave and never leaves it.

Every sensitive operation (delete, rebuild, update, change security tier) requires a Proof of Possession signature: your device signs the request parameters using ECDSA. The VPS independently verifies this signature against the public key it stored during registration.

  • Phishing is impossible. WebAuthn is domain-bound — your passkey only works on the real ellul.ai domain.
  • Session hijacking is impossible. Stolen cookies are worthless without the hardware key.
  • A full platform breach cannot compromise your server. There is nothing in our database to steal.
2

Integrity — Deterministic Body Hashing

Tech

SHA-256 canonical body hash with recursive key sorting, embedded in PoP signature.

Benefit

The 'Bait and Switch' defense. It is mathematically impossible for anyone to modify your command between your browser and the server.

The Problem: Even with strong authentication, a man-in-the-middle (or a compromised platform) could alter the content of your request after you authenticate it. You confirm "restart my server" but the platform sends "delete my server."

Our Solution: Every sensitive request is bound to its payload using deterministic SHA-256 body hashing. The hash is computed over canonicalized JSON (recursively sorted keys) and embedded in the PoP signature. The VPS recomputes the hash independently — if a single parameter was changed by anyone, including us, the operation is rejected.

  • TOCTOU protection. Parameters cannot change between confirmation and execution.
  • Three-way integrity chain. During provisioning, the API hashes the cloud-init YAML, your browser independently computes the same hash, and the server verifies it on first boot. All three must agree.
3

Supply Chain — GPG-Verified Updates

Tech

Offline air-gapped GPG key. Fingerprint pinned as a build-time constant. Anti-rollback enforcement.

Benefit

We cannot push a backdoor to your server. Your VPS independently verifies every update against a public key that even we cannot change.

The Problem: If an attacker compromises a platform's CI/CD pipeline, they can push a backdoored update to every server — a single point of failure affecting all users simultaneously.

Our Solution: Your VPS independently verifies every update against a GPG signature created with an offline, air-gapped key. The verification happens on your server, not on our infrastructure.

CheckWhat It Prevents
GPG Signature VerificationUnsigned or tampered releases
Fingerprint PinningSwapped GPG keyring (even by root attacker)
Anti-RollbackDowngrade to vulnerable older versions
Tag Format ValidationPath traversal or injection via tag names

Circular Dependency Defense

The GPG fingerprint is a build-time constant embedded in the daemon binary. An attacker would need to both compromise the GPG key and push a fraudulent GPG-signed update to change it — a circular dependency that makes the attack infeasible.

4

Isolation — SSH-Only Dark Mode

Tech

Port cloaking via dual-layer firewall. Process-level kill of web services. Capabilities stripping.

Benefit

Turn the lights off. When you enable SSH-Only, the web dashboard becomes cryptographically dead. Your server disappears from scanners.

The Problem: Every open port is an attack surface. Web dashboards, APIs, and management interfaces all present opportunities for exploitation — especially when the platform itself could be compromised.

Our Solution: SSH-Only mode doesn't just hide the web interface — it cryptographically kills it:

1

Process termination

The web terminal process (ttyd) is stopped at the OS level.

2

Capabilities stripped

The capabilities endpoint returns an empty object. There is nothing to discover.

3

Hard rejection

A global middleware gate returns 403 for all web-initiated operations.

4

Dual-layer firewall

External cloud firewall (Hetzner/DO API) + internal UFW. Both must agree to open a port. Compromising one layer is still blocked by the other.


The "Bus Factor" — What If ellul.ai Disappears?

This is the question every developer should ask their hosting provider. Most can't give you a good answer. Here's ours.

Break Glass Protocol

Your server is a standard Linux VPS on Hetzner or DigitalOcean. ellul.ai is a management layer on top — not a proprietary container, not a locked-down image, not a walled garden.

If ellul.ai goes offline — whether from an outage, a shutdown, or the heat death of the universe:

1

Your server keeps running

All your applications, data, and configurations continue to operate. Nothing depends on our API for runtime functionality.

2

The daemon enters fail-safe mode

After 5 consecutive missed heartbeats (25 seconds), the State Enforcer enters Emergency Lockdown — closing external access as a precaution while the daemon stays alive and polls for recovery.

3

You SSH in and take over

Disable the agent, open SSH permanently, and your server is a standard Linux VPS. All your data, apps, and configs are intact.

4

Keep your server forever

Transfer billing to your own cloud provider account. ellul.ai is fully out of the picture.

# The full takeover — five minutes of work
sudo systemctl stop ellulai-enforcer
sudo systemctl disable ellulai-enforcer
sudo ufw allow 22/tcp
# Done. Standard Linux VPS.

We lock ourselves out, not you.

There is no kill switch, no remote wipe, no dead man's trigger. The worst case scenario for ellul.ai going away is five minutes of terminal commands.


Identity Pinning — The Anti-Takeover Defense

During initial provisioning, your user ID is written to an immutable lockfile on the VPS:

/etc/ellulai/owner.lock    (chmod 400, chattr +i)

The chattr +i flag makes this file immutable at the filesystem level — not even root can modify or delete it without first removing the flag.

Every heartbeat (every 30 seconds), the State Enforcer checks whether the user ID reported by the API matches this lockfile.

Attack scenario: database takeover

An attacker compromises the database and runs UPDATE servers SET userId='hacker'. The next heartbeat detects the mismatch against owner.lock. Soft Lockdown activates instantly: JWT secret deleted, terminal killed, SSH closed. The attacker cannot issue commands despite "owning" the database record. When the database is corrected, the enforcer auto-recovers — no manual intervention, no support ticket.


Compliance & Privacy

Data Residency

ellul.ai supports strict region selection with EU-compliant datacenters:

RegionProviderLocationEU Residency
eu-centralHetznerNuremberg, DEYes
eu-northHetznerHelsinki, FIYes
eu-central (overflow)DigitalOceanFrankfurt, DEYes
eu-north (overflow)DigitalOceanAmsterdam, NLYes
us-eastHetzner / DOAshburn / NYC
us-westHetzner / DOHillsboro / SFO
asia-pacificHetzner / DOSingapore

EU-region servers are provisioned exclusively in EU datacenters. Your data stays in the jurisdiction you choose.

Abuse Prevention — The Liability Straitjacket

Blocked by default on every VPS

SMTP (25, 465, 587) — prevents spam relay. Mining pools (3333, 5555, 7777, 8888, 9999, 14433, 14444, 45560) — prevents cryptojacking. Outbound SYN flood — rate-limited to 100/s, preventing DDoS participation.

A clean IP means your legitimate services work reliably. Platforms that don't enforce these rules end up on blocklists — and so do you.

Encryption at Rest

All secrets stored in the ellul.ai database are encrypted with AES-256-GCM before storage. Initialization vectors are unique per record. Auth tags prevent tampering. Token hashes use SHA-256 with timing-safe comparison to prevent length oracle attacks.


The Audit Trail

Every security-relevant action is recorded with structured audit events. The system tracks 52 distinct event types across five categories:

CategoryExample Events
AuthenticationLogin, logout, failed auth attempts
Server OperationsCreate, delete, rebuild, rollback
Security ChangesTier changes, passkey registration, SSH key management
Anomaly DetectionReplay attempts, conflicting transitions, oversized requests
System EventsLockdown triggers, recovery events, heartbeat failures

Sensitive data (keys, tokens, credentials) is automatically redacted before logging. All sensitive requests include a one-time nonce with a 5-minute TTL, scoped per-server to prevent cross-server replay.

Hostile Red Team Audit

The system has been subjected to adversarial testing covering four domains:

Audit DomainWhat Was Tested
Data SovereigntyCan the platform access user data? Can a database breach expose server contents?
Credential IsolationDo breach-safe tiers remain safe under full platform compromise?
Localhost Bypass PreventionCan internal services be reached by circumventing authentication layers?
Ghost Port DetectionDo disabled services leave residual open ports or listening sockets?

ellul.ai vs. Traditional Platforms

Traditional PaaSStandard VPSellul.ai
Who holds the keys?The platformYou (manage everything)You (we manage the rest)
Platform breach = your breach?YesN/ANo (breach-safe modes)
Can the vendor read your data?Usually yesN/ANo
Can the vendor push code?YesN/ANo (GPG verification)
Survive vendor shutdown?No (proprietary runtime)YesYes (standard Linux VPS)
Command integrity?NoN/AYes (HMAC body hashing)
Phishing-resistant auth?RarelyN/AYes (WebAuthn)
Setup complexityLowHighLow

FAQ for Skeptics

You say you can't access my server. How do I know that's true?+

Because there's no mechanism to. In SSH-Only mode, the only way in is with an SSH private key that was never transmitted to us. In Web Locked mode, the only way is with a WebAuthn passkey whose private component lives in your device's secure enclave. We don't have a backdoor, an admin override, or an emergency access protocol. We architecturally cannot build one without breaking the GPG-signed update chain.

What if I lose my SSH key or my passkey device?+

In SSH-Only mode, you need your SSH key. In Web Locked mode, you need your registered device. If you lose both, you can access the underlying Hetzner or DigitalOcean VPS through the provider's emergency console. We intentionally do not offer a recovery path — because any recovery path we offer is a recovery path an attacker can exploit.

What stops a rogue ellul.ai employee from pushing a malicious update?+

GPG verification. Every update must be signed with an offline, air-gapped GPG key. The VPS verifies the signature and checks the fingerprint against a build-time constant. A rogue employee with full access to our infrastructure still cannot sign a release, because the signing key has never touched a networked machine.

How is this different from just renting a VPS myself?+

Three things: automated provisioning (your server is ready in minutes, not hours), managed security defaults (firewall rules, abuse prevention, hardened configs), and the tiered security model (WebAuthn, PoP signatures, body hashing) that would take significant engineering effort to implement yourself. You get self-managed sovereignty without the self-managed overhead.

What data do you actually store about me?+

Your account info (email, OAuth tokens for login), server metadata (IP, region, plan, security tier), and encrypted secrets (SSH public keys, API tokens). We do not store: your server's contents, your terminal history, your application data, your SSH private keys, or your WebAuthn private keys.

Can you read my terminal sessions?+

In Standard mode, terminal traffic is proxied through our API — so theoretically, yes. This is one reason we offer SSH-Only and Web Locked modes: terminal access either bypasses us entirely (SSH) or is end-to-end authenticated with passkeys stored on the VPS. If terminal privacy matters, upgrade to a breach-safe tier.

What happens to my data if I delete my account?+

Server deletion is handled at the cloud provider level. The VPS and all its data are destroyed. Your account data is deleted from our database. If you want to keep your server, disable the ellul.ai agent via SSH and transfer billing to your own provider account before deleting.

Has this been independently audited?+

The system has undergone internal adversarial testing (hostile red team audit) covering data sovereignty, credential isolation, localhost bypass prevention, and ghost port detection. We publish our security architecture transparently so you can audit the design yourself.