Most secret managers protect secrets in storage. We protect them in use.
49% of breaches involve stolen credentials. Encrypting secrets at rest is table stakes. The real question is what happens when your application needs to use them. That is where every other vault falls short, and where FyVault begins.
SOC 2 Type II
Audit trail compliance
AES-256-GCM
Client-side encryption
FIDO2/WebAuthn
Hardware security keys
Nitro Enclaves
Confidential compute
Defense in Depth
The problem
Your vault locks the front door. Your .env file leaves a window open.
Traditional Flow
FyVault Flow
Traditional Vault
Secrets are fetched from a vault, then placed into environment variables or config files. They sit in plaintext in process memory, core dumps, and /proc filesystem. Any code execution vulnerability gives an attacker direct access to every credential your app uses.
FyVault
Your application only holds FYVAULT:: placeholders. Real credentials are injected at the kernel boundary via eBPF, exist for microseconds during the syscall, and never enter your application's address space. A memory dump reveals nothing.
PLACEHOLDERS_ONLY
Application Layer
Your application never touches a real secret. Every environment variable, every config value, every connection string is a FYVAULT:: placeholder. A full memory dump of your running process returns nothing useful to an attacker.
Data Flow
- No secrets in env vars
- No secrets in /proc/PID/environ
- No secrets in core dumps
- Safe to log environment
EBPF_SEALED
Kernel Layer
When your application makes an outbound syscall, eBPF programs intercept it at the kernel boundary and rewrite FYVAULT:: placeholders with real credentials sourced from the kernel keyring. The secret exists in transit for microseconds.
Data Flow
- Kernel keyring isolation
- Per-syscall credential injection
- ~3µs overhead per rewrite
- Separate OS user for key storage
ZERO_KNOWLEDGE
Cloud Layer
Every secret is encrypted on your device with AES-256-GCM before it ever leaves. We store opaque ciphertext. Your encryption key is derived from your organization passphrase and never transmitted.
Data Flow
- AES-256-GCM client-side
- Key derived from org passphrase
- Server stores opaque blobs
- Offline after boot
By the numbers
What runtime protection looks like in practice
Memory exposure
Overhead per rewrite
AES-GCM encryption
Offline capable
Here is exactly what we protect and what we don't
Ten attack vectors. Eight fully mitigated. One partially covered. One documented architectural limit. No surprises.
Attacker reads .env file
Sees FYVAULT:: placeholders — no real credentials present
Memory dump of application process
No plaintext secrets found in process address space
Man-in-the-middle on network traffic
TLS 1.3 with certificate pinning — intercepted traffic is encrypted
Stolen device authentication token
Hardware fingerprint mismatch blocks use on any other device
Database breach of FyVault servers
Only AES-256-GCM ciphertext stored — we cannot decrypt it
Compromised or severed cloud connection
Agent operates fully offline after initial boot sequence
Supply chain attack via frontend JavaScript
Crypto runs in isolated Worker with non-extractable keys and strict CSP
Secret leakage from SDK or CLI output
SDK returns rotating handles (fvh_) that expire in minutes and only work on localhost
Root access to application server
Kernel keyring stored under separate OS user — reduces blast radius
Full kernel compromise with root escalation
Assumes kernel integrity — this is a documented architectural limit