Private Vault

Private storage for agent logs, scoped memories and attachments. This is the independent private-vault branch.

Design and API — review and comment in Notion

Repository snapshot.

Try the prototype. Use synthetic data: real on-chain attestation verification is still a production dependency.

The current service runs one serving CVM per assigned vault in a pool, with an ordinary keeper and opaque relay. Its browser lives in web-private-vault/; examples/private_vault_client.py is the API reference client. Inherited portal/ targets an older architecture; the MCP below targets this service.

Connect an agent harness

Create/export an API key in the prototype website, then run (after the first PyPI release):

uvx --python 3.12 data-vault-mcp@latest setup atlas  # or codex, both, claude, generic

Setup privately prompts for the key once. Alternatively pass --api-key-file /path/to/key with a 0600 Ed25519 seed file or the website's downloaded Ed25519 JWK. Deployment URLs, module address and operational Client keys are bundled; no node/gas key or npm setup is needed on the user device. Atlas local-clone virtualenvs and Codex's application bundle are detected even when their CLIs are absent from PATH. The registered MCP is named data-vault. Restart/reload your harness after setup. Its registered command uses uv tool run --python 3.12 data-vault-mcp@latest. Each new MCP process resolves the latest stable PyPI release and uses a cached environment if it is unchanged. Already-running processes keep their current version. No source clone is needed after setup. A release-resolution failure is reported; setup does not silently fall back to old source code or change the registration. Rerun setup once to migrate a previous local-checkout installation.

At the start of each conversation the model shows vault names/intents and asks which may automatically receive relevant records. start_vault_session records that choice in memory; an empty choice keeps all writes manual. Unselected writes, file uploads, forget and sharing changes require specific approval. Changed intents revoke automatic selection and trigger tools/list_changed. These are conversational choices reported by the model, not proof of a human click; use the harness's write-tool confirmation UI when that is required. Reads and search work without auto-write selection, by vault ID or exact name. add_record accepts local file_paths; download_attachment returns a local file path for the harness's normal viewers/file tools, regardless of file type.

The installer allows attachment files under your home directory by default; --allow-dir /path narrows it (repeat for multiple directories). The standalone data-vault-mcp defaults to its working directory. The configured API-key file cannot be uploaded or overwritten. Downloads preserve existing destinations unless overwrite is explicitly requested.

Keys live under ~/.config/confidential-vault-6038be20/, separate from c26t's old deployments. get_mcp_version reports the running code/deployment and private log file. Logs live under ~/Library/Logs/confidential-vault-6038be20/ on macOS, or $XDG_STATE_HOME/confidential-vault-6038be20/ (default ~/.local/state/) on Linux; logs omit credentials, queries, record text, files and exception messages.

uvx --python 3.12 data-vault-mcp@latest setup atlas --uninstall

Uninstall unregisters only data-vault, retaining credentials and downloads. The inherited c26t installer remains available as scripts/install_legacy_mcp.py; its keys, registrations and endpoints are not reused by the new MCP.

For development, ./scripts/install_mcp.py atlas --local explicitly registers this checkout. Without --local, that script installs the same auto-updating release entry as the package's setup command.

MCP releases

The standalone data-vault-mcp package uses mcp/pyproject.toml. The release stager copies only tracked client modules and stamps their source commit/version; ACE, embedding models and worker runtime dependencies are excluded. CI builds the sdist and wheel, checks metadata, and exercises the installed wheel's setup and stdio entry points in a fresh environment.

Publishing follows ACE's GitHub OIDC Trusted Publisher pattern; no PyPI API token is stored in GitHub. Before the first upload, add a pending publisher at PyPI Publishing with:

For TestPyPI, configure the same project/workflow with environment testpypi at TestPyPI Publishing. The workflow is .github/workflows/publish-mcp.yml. Branch/PR runs only build and test. Manual runs default to target=check; choose testpypi or pypi to upload and optionally specify a version. Pushing mcp-v0.1.0 publishes version 0.1.0 to PyPI. PyPI versions are immutable; use a new version for each subsequent release.