# Svault Security & Project Review

**Project**: [nim444/Svault](https://github.com/nim444/Svault) — AI-aware secret access layer (Rust)  
**Version reviewed**: 0.5.0  
**Review date**: 2026-05-29 16:55 EEST  
**Reviewed by**: Grok 4.3 (xAI) — April 2026 release  
**Review location**: Active development tree at `repos/svault` (cross-checked against fresh GitHub clone)  
**Reviewer perspective**: Professional security assessment for corporate and medium-sized company adoption, including infrastructure and server deployment considerations.

---

## Executive Summary

Svault 0.5.0 is a **solid, professionally implemented** AI-aware secret manager. The addition of a proper **Unix daemon** in this release represents a **meaningful security improvement** over 0.4.0, particularly around the long-standing weakness of caching the master passphrase on disk.

**Current risk posture for corporate or medium company use**:

- **Unix developer workstations**: Low–Medium (good improvement when the daemon is used)
- **Servers / CI / Infrastructure (Unix)**: Medium (noticeably better than before, but still requires care)
- **Windows environments**: High (no daemon support yet)
- **High-value production secrets with heavy AI automation**: Medium-High

### Major Positive Development in 0.5.0
The new Unix daemon (`svault daemon start`) replaces the file-based `.session` (which stored the raw passphrase on disk) with an in-memory key store served over a 0600 Unix socket. Keys are zeroized on lock, idle timeout, hard-max timeout, and daemon shutdown. This directly addresses one of the highest-risk areas identified in the 0.4.0 review.

### Remaining High-Severity Concerns
- `svault.policy.yaml` remains unsigned and unauthenticated (anyone who can write to the project tree can weaken or bypass agent controls).
- The daemon (and old file session) still trusts any process running as the same user.
- Windows continues to use the weaker file-based session mechanism.
- Supply chain / release hardening (signing, SBOMs, attestations) is still absent.

---

## Scope & Methodology

### What Was Reviewed
- Full source tree at 0.5.0, with special focus on the new daemon and client routing layers.
- Key files: `src/daemon.rs`, `src/client.rs`, `src/crypto.rs`, `src/vault.rs`, `src/policy.rs`, `src/recovery.rs`, `src/meta.rs`, `src/main.rs`, and TUI components.
- Updated documentation: `docs/daemon.md`, `docs/security.md`, `docs/architecture.md`, `docs/roadmap.md`.
- CI/CD and release workflows.
- Dependency security and code quality tooling.

### Tools Executed on 0.5.0 Codebase
- `cargo test --locked` → **74 tests passed** (up from 65)
- `cargo clippy --all-targets -- -D warnings` → Clean
- `cargo audit --deny warnings` → 1 low-impact TUI-related advisory (`lru` via ratatui)
- Manual review of daemon socket creation, permission handling, key storage, auto-eviction logic, and client fallback behavior.

---

## Security Findings

### High Severity

| Finding | Impact | Status in 0.5.0 | Details |
|---------|--------|------------------|---------|
| **Policy file is unsigned** | High | Unchanged | `svault.policy.yaml` controls scopes, tiers, rate limits, and high-sensitivity blocks. It has no signature or integrity protection. A malicious change in the repo tree can neuter the AI-aware protections. |
| **Same-user trust boundary** | High | Partially improved | Both the old file session and the new daemon trust any process running as the same UID. The daemon is better (keys in memory only), but the fundamental local privilege model has not changed. |
| **Windows fallback** | High | Unchanged | On Windows the daemon is unavailable. All "unlock" behavior falls back to writing the raw passphrase to `.session` (0600). |

### Medium Severity

| Finding | Impact | Status in 0.5.0 | Details |
|---------|--------|------------------|---------|
| **Missing supply-chain hardening** | Medium | Unchanged | No binary signing, SBOMs, or attestations. Release process remains basic. |
| **Passphrase sent over Unix socket** | Medium | New context | During `svault unlock` with the daemon, the raw passphrase travels once over the 0600 socket in cleartext. Acceptable for local use, but worth noting in threat models. |
| **TUI dependency advisory** | Medium (limited) | Improved | Only `lru` soundness issue remains (via ratatui). The previous `paste` unmaintained advisory is no longer flagged. |
| **Lightweight passphrase policy** | Medium | Unchanged | Still only basic length + character class checks. |

### Low / Informational

- Only two small, well-contained `unsafe` blocks in the daemon (required `libc::setsid` and `libc::kill`).
- Socket and pid files are correctly created with 0600 permissions.
- Keys are stored using `Zeroizing<[u8; 32]>` and properly cleared on eviction/shutdown.
- Auto-lock uses two independent timers (idle + hard-max) with background zeroizing.

---

## Positive Security Properties (0.5.0)

- **Significant improvement to session security** via the new daemon on Unix.
- Cryptography remains correct and conservative.
- Excellent secret handling discipline (no values in logs, generic error messages, on-demand decryption).
- Strong test coverage increase with the daemon addition.
- Clean separation between read path (can use daemon) and write path (still requires direct passphrase).
- Socket permissions and file cleanup on shutdown are handled correctly.
- Zeroization is applied consistently to cached keys.

---

## The New Daemon in 0.5.0 — Detailed Security Analysis

### What It Does Well
- Derived keys live **only in memory** inside the daemon process (never written to disk after initial unlock).
- Keys are zeroized on explicit lock, idle timeout (default 15 min), hard-max timeout (default 8 hours), and daemon shutdown.
- Very small mutex critical section for `Get` requests — the actual decryption happens outside the lock.
- Socket (`daemon.sock`) is bound and then explicitly set to mode `0600`.
- Pid file is also created 0600.
- Background ticker thread evicts and zeroizes expired keys.
- The daemon never exposes write operations or the original passphrase over the socket.

### Remaining Risks
- Any process running as the same user can connect to the socket and request secrets for any vault currently held by the daemon.
- The passphrase itself is transmitted in cleartext JSON during the `Unlock` request (one time per vault).
- There is no per-client authentication beyond "able to connect to the 0600 socket."
- If the daemon process is compromised (e.g. via a memory disclosure vulnerability in another component), all currently unlocked vault keys are exposed.

### Overall Verdict on the Daemon
This is a **clear step forward** for Unix environments. For developer machines and many server use cases it meaningfully reduces the window and persistence of secret material on disk. It does not, however, change the fundamental "any process as the same user" trust model.

---

## Infrastructure, Server & CI/CD Deployment Considerations (Updated for 0.5.0)

### Current Reality (0.5.0)

**Strengths**
- On Unix, the daemon provides a much safer "unlock once" experience than the previous file-based session.
- Static binary + no heavy runtime dependencies remains excellent for containers and minimal server images.
- Audit and usage logs continue to be high-quality and easy to ship to SIEM systems.
- `svault get` (agent path) works cleanly through the daemon.

**Important Limitations**
- The daemon is **Unix-only**. Windows, many CI runners, and some container environments will still use the weaker file session.
- Even with the daemon, any process running as the same user on the host (or in a container sharing the UID/volume) can request secrets.
- Writes (`secret add`, `secret remove`) still require the passphrase directly — they do not go through the daemon.
- There is still no central policy management or signed policy files.

### Recommended Patterns (0.5.0)

**Best practice on Unix servers / CI today:**
1. Start the daemon early in the job or on the bastion: `svault daemon start`
2. Unlock vaults through the daemon (passphrase is sent once, then forgotten)
3. Use `svault get ... --caller ... --reason ...` or `svault secret get` for reads
4. Explicitly `svault lock` or let auto-lock timers handle eviction
5. Stop the daemon at the end of the job if desired (`svault daemon stop`)

**High-sensitivity secrets** should still be retrieved only by humans or through very tightly controlled pipelines.

**Windows and non-Unix environments** should continue to treat `svault unlock` as high-risk and prefer one-shot usage with passphrases injected from external secret managers.

---

## Corporate & Team Adoption Recommendations (0.5.0)

### Immediate Actions
- On Unix systems, **strongly prefer the daemon** over the old file session for any non-trivial usage.
- Continue treating `svault.policy.yaml` as high-risk code that must be reviewed.
- Add monitoring of `daemon.log` in addition to `audit.log` and `usage.log`.
- Document when the daemon is required vs. when fallback behavior applies (especially for Windows and CI).

### Before Broader Rollout
- Re-evaluate after the daemon receives more real-world usage and any follow-up security fixes.
- Consider internal controls (e.g. running the daemon under a dedicated low-privilege user where possible, or using filesystem namespaces).
- Wait for clearer Windows support or documented safe fallback patterns before relying on it in mixed environments.

### High-Value Next Features (from a security perspective)
- Signed / centrally distributed policy files
- Some form of client authentication or capability tokens for the daemon socket (beyond UID)
- Windows daemon equivalent (or a well-documented secure alternative)
- Binary signing + SBOMs in the release process

---

## Overall Risk Assessment by Context (0.5.0)

| Context | Risk Level | Notes |
|---------|------------|-------|
| Personal developer workstation (Unix + daemon) | Low–Medium | Good choice when using the daemon |
| Small team (mostly Unix) | Low–Medium | Solid with daemon usage |
| Medium company — CI/CD + AI agents on Unix | Medium | Acceptable with daemon + careful policy review |
| Corporate production infrastructure (Unix) | Medium | Improved, but still needs compensating controls for high-value secrets |
| Mixed Windows + Unix environments | Medium-High | Windows remains the weak link |
| High-security / regulated / crown jewels | High | Not recommended yet without additional layers |

---

## References

- Official security model: [docs/security.md](../../security.md)
- Daemon documentation: [docs/daemon.md](../../daemon.md)
- Policy engine: [docs/policy-engine.md](../../policy-engine.md)
- Architecture: [docs/architecture.md](../../architecture.md)
- Roadmap: [docs/roadmap.md](../../roadmap.md)
- GitHub: https://github.com/nim444/Svault
- Crates.io: https://crates.io/crates/svault-ai

---

*This review reflects Svault version 0.5.0 as of 2026-05-29. The introduction of the Unix daemon is the most significant security-relevant change since 0.4.0. Re-evaluate after future major releases (especially Windows daemon support or policy signing).*

---

## Independent Review Prompt

A reusable, neutral prompt is available in this repository so other AI models can perform their own independent security reviews of the current codebase:

→ [PROMPT.md](../PROMPT.md)

The prompt is kept up to date with the latest version and features (including the daemon) so other models can produce fresh, unbiased assessments.

**End of Security & Project Review**