Alfred Black handles your most personal information — your relationships, your commitments, your decisions. Security isn’t a feature. It’s the foundation.This page explains how every layer of Alfred’s infrastructure is designed to keep your data private, your vault safe, and your world protected.
Your vault and all associated data are stored on a LUKS2-encrypted volume using AES-256-XTS. The encryption key is generated per instance during provisioning.
All services on your Alfred bind to 127.0.0.1 (localhost only):
Tenant API: 127.0.0.1:3100
OpenClaw Gateway: 127.0.0.1:18789
Temporal Engine: 127.0.0.1:7233
No service listens on a public interface. External access is only possible through Tailscale (for the SaaS proxy) or Cloudflare Tunnel (for OpenClaw device connectivity, outbound-only).
Alfred uses OpenClaw as the gateway for conversational access — the interface you use when you pair a device and talk to Alfred directly. Because OpenClaw connects a language model to your vault, it introduces a surface area that demands careful layering.
Before any device can talk to your Alfred, it must be paired and approved:
A device requests pairing through the OpenClaw gateway
The request appears in your dashboard as pending
You approve or reject it
On approval, a cryptographically random device token is generated and returned once
The device uses this token for all subsequent connections
Every conversation requires a valid device token. Tokens can be revoked instantly from your dashboard — cutting off access immediately. You can also rotate a device’s token if you suspect it’s been compromised, without removing the device.
When you talk to Alfred through OpenClaw, the language model can interact with your vault — but only through a tightly controlled gate.The agent does not have direct filesystem access. Every vault operation goes through the alfred vault CLI, a mediation layer that enforces rules before any read or write touches your data:
You → OpenClaw → Language Model → alfred vault CLI → Your Vault ↑ Scope check, path validation, schema validation, mutation log
The agent can:
Read records, search your vault, and get context
Create or edit records (when running as the Curator)
Fix or remove broken records (when running as the Janitor)
Surface learning records (when running as the Distiller)
What it cannot do:
Access files outside your vault — path traversal is blocked at the CLI layer
Bypass its scope — a Curator session cannot delete, a Janitor session cannot create, a Distiller session can only create learning types
Run arbitrary commands — the agent’s only tool is the vault CLI, not a general-purpose shell
Access the network — the OpenClaw container has no outbound internet access except to configured LLM providers
Escape its container — no privilege escalation, no Docker socket, no system capabilities
Alfred uses external LLM providers (like OpenRouter, Anthropic, or OpenAI) to power the language model behind conversations. These are the only third-party services your Alfred connects to.
No third-party plugins — Alfred ships only its own curated skills (Curator, Janitor, Distiller). Third-party skill installation from ClawHub is disabled by default.
No arbitrary API access — the agent cannot make outbound HTTP requests to services you haven’t configured
Provider credentials are stored on your encrypted volume (LUKS2) with restricted file permissions (mode 0600)
You choose the model — you can select which language model each specialist uses from your dashboard
Prompt injection — where malicious content in your data tricks the language model into doing something unintended — is one of the most discussed risks in AI systems. Alfred defends against this at multiple layers.
No AI system can guarantee 100% immunity to prompt injection. Alfred’s approach is defense in depth — even if the language model is tricked, the damage it can do is bounded by technical enforcement that the model cannot override.
Layer 1 — Scope enforcement (code-level)Even if the model is manipulated, it physically cannot perform operations outside its scope. A Curator session cannot delete records. A Distiller session cannot edit your existing data. These rules are checked in code before every operation — not by the model, but by the vault CLI itself.Layer 2 — Path validation (code-level)Every file path is resolved to its absolute form and verified to be within your vault directory. Attempts to reference ../, symlinks, or paths outside the vault boundary are rejected. This is enforced at the filesystem level, not by the model.Layer 3 — Schema validation (code-level)Record types are validated against a fixed set of 22 known types. Status values are checked against per-type allowed values. List fields must be arrays. Invalid frontmatter is rejected. The model cannot invent new record types or set impossible statuses.Layer 4 — Mutation logging (code-level)Every write operation — every create, edit, move, and delete — is recorded in an append-only audit log with timestamps and attribution. If something unexpected happens, you have a complete record of what changed, when, and which specialist did it.Layer 5 — Skill instructions (prompt-level)Each specialist receives detailed instructions that define its role, boundaries, and acceptable behavior. These include explicit constraints: “never access the filesystem directly,” “never delete unless it’s garbage,” “never modify source records.” While prompt-level defenses are not absolute, they significantly reduce the likelihood of unintended behavior.The key insight: Layers 1 through 4 are technical controls enforced in code. The language model cannot bypass them regardless of what instructions it receives. Layer 5 adds behavioral guidance on top. Even in a worst-case prompt injection scenario, the blast radius is bounded by the technical layers beneath.
Alfred’s specialists (Curator, Janitor, Distiller, Surveyor) are constrained by multiple layers of security — whether they’re running as background workers or through an OpenClaw conversation.
Each specialist has strict rules about what vault operations it can perform:
Specialist
Create
Read
Edit
Move
Delete
Curator
Yes
Yes
Yes
Inbox only
No
Janitor
No
Yes
Yes
No
Yes
Distiller
Learning types only
Yes
No
No
No
The Curator can create and edit records but cannot delete anything — preventing data loss during intake
The Janitor can edit and remove broken records but cannot create new ones — limiting its blast radius to fixes only
The Distiller can only create learning records (assumptions, decisions, constraints, contradictions, syntheses) — it cannot modify your existing records
These rules are enforced in code before every vault operation. A specialist that attempts an unauthorized action receives a scope error and the operation is blocked.
Each specialist invocation receives a unique, temporary session file. Mutations are tracked per-session, and sessions are cleaned up after processing. Concurrent invocations cannot interfere with each other.
Each tenant has SSH keys generated during provisioning. Users can download their private key from the dashboard to connect directly to their Alfred instance.
Keys are generated per-tenant during instance provisioning
Storage
Private keys are stored encrypted on the platform and delivered over HTTPS
Isolation
Keys are never shared between tenants — each instance has its own key pair
Access level
SSH provides full access to the tenant VPS as the deploy user
SSH gives you full access to your Alfred’s server. You can run any command, modify configuration, and access your vault directly on disk. Use responsibly — changes made via SSH are not tracked in the dashboard audit log.
Your vault is an Obsidian-compatible collection of Markdown files. You can pair a device to access your vault directly and maintain your own local copies at any time.
