Security Model
This page describes the security architecture as it actually works in the current beta — including the boundaries and the things AccessVault does not yet do.
The bridge architecture
Claude (MCP client) │ stdio (MCP protocol) ▼AccessVault MCP sidecar ← no database drivers at all │ HTTP, 127.0.0.1 only, bearer token ▼AccessVault desktop app ← credentials, audit log, policy │ native PostgreSQL driver ▼Your databaseThe MCP sidecar is a separate bundled binary with zero database dependencies — it cannot open a database connection even if compromised. Its only capability is calling the desktop app’s local HTTP API. That API:
- exposes exactly two routes: a status check and the query-execute endpoint;
- binds to 127.0.0.1 only — it is never reachable from the network;
- requires a bearer token: 32 bytes from the OS CSPRNG (64 hex characters), compared in constant time, and regenerated fresh on every app launch;
- caps every result at 1,000 rows, with a
truncatedflag when the cap bites.
Because the sidecar can only talk to the app, and the app enforces auditing, there is no path from the AI to your database that bypasses the audit log. The corollary: AccessVault must be running for the AI to query anything.
Credential storage
Database passwords, SSH secrets, and your Anthropic API key are stored in the macOS Keychain. Connection profiles persist as local JSON, but they hold only a UUID reference to the Keychain item — secrets are never written to disk in plaintext. Credentials never leave the app: the AI side of the bridge only ever holds the local bearer token.
The audit guarantee
For every query the AI runs, the exact sequence is:
- The query executes against your database.
- An audit entry is written — capturing the request ID, connection, tool, parameters, and the outcome (row count and duration on success; the error message on failure).
- Only then are results returned to the AI.
This holds for failures too: an errored query still produces an audit entry before the error is returned. If the audit write itself fails, the whole request fails — results are never handed back unaudited. Database-touching actions you take in the app UI are logged the same way.
Honest limits: the audit log is a plain append-only JSON Lines file. It is append-only by API design — nothing in the app can edit or delete entries — but it is not cryptographically tamper-evident: there is no hash chain or signature, and anything with filesystem access could modify the file. See The Audit Log.
What the AI can and cannot do
The AI never sends arbitrary SQL. It can only invoke the parameterized tools you have enabled
in a connection’s catalog, with typed parameters bound natively (never
string-interpolated into SQL). Tool SQL is validated to be read-only (SELECT/WITH only) when a
tool is created or edited.
Honest limits: that read-only validation runs at authoring time, not at execution time — there is no second statement check when a query runs, and queries do not run in a read-only transaction. The practical mitigation is the one the audit-readiness scanner itself checks for: connect AccessVault to your database with a least-privilege role that has only the access your tools need.
On top of the catalog, data exposure policy rules can deny or mask specific columns in every result that crosses the bridge.
SSH tunnels
SSH tunnels run in-process (pure Rust) with password or private-key authentication. Honest limit: the current beta does not verify SSH host keys — every host key is accepted and logged. Until host-key verification ships, an SSH tunnel protects you from passive snooping but not from an active machine-in-the-middle on the SSH connection. There is also no ssh-agent support yet. See SSH Tunneling.
Local-first
AccessVault runs entirely on your machine: no account, no cloud component, no telemetry — nothing
phones home. The single exception is opt-in: if you add an Anthropic API key and use the
AI tool generator, schema metadata (never row data) is sent to
api.anthropic.com, and nowhere else.