[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-1938":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":16,"stars30d":17,"stars90d":15,"forks30d":15,"starsTrendScore":18,"compositeScore":19,"rankGlobal":9,"rankLanguage":9,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":23,"hasPages":21,"topics":24,"createdAt":9,"pushedAt":9,"updatedAt":25,"readmeContent":26,"aiSummary":27,"trendingCount":15,"starSnapshotCount":15,"syncStatus":28,"lastSyncTime":29,"discoverSource":30},1938,"hermes-vault","asimons81\u002Fhermes-vault","asimons81","Hermes-native local-first credential broker, scanner, and encrypted vault.",null,"Python",213,14,143,1,0,3,57,9,3.53,"MIT License",false,"master",true,[],"2026-06-12 02:00:34","# Hermes Vault\n\n![Hermes Vault promo image](assets\u002Fhermes-vault-promo-image.png)\n\nHermes Vault is a local-first credential broker and encrypted vault for Hermes agents. It scans for risky plaintext secrets, stores credentials locally, verifies them before re-auth claims, and generates skill contracts that keep agents on the same workflow.\n\n## What It Does\n\n- Scans Hermes-relevant files for plaintext secrets, duplicates, and insecure permissions\n- Encrypts credentials in a local SQLite-backed vault\n- Brokers access with per-agent policy and ephemeral environment materialization\n- Verifies credentials before any re-auth recommendation\n- Refreshes already-authorized OAuth credentials without opening a browser when a refresh token exists\n- Generates `SKILL.md` files for Hermes agents and sub-agents\n- Provides a token-guarded local dashboard for operator visibility and safe actions\n\n### CLI snapshot\n\nThe original terminal-first banner still reflects the operator workflow that powers the project:\n\n![Hermes Vault CLI banner](assets\u002Fhermes-vault.png)\n\n## Install\n\nReleased CLI installs are safest with an isolated tool manager:\n\n```bash\nuv tool install git+https:\u002F\u002Fgithub.com\u002Fasimons81\u002Fhermes-vault.git@vX.Y.Z\npipx install git+https:\u002F\u002Fgithub.com\u002Fasimons81\u002Fhermes-vault.git@vX.Y.Z\n```\n\nFor local development, use `uv` or editable `pip`:\n\n```bash\nuv sync --extra dev\n```\n\nOr with pip:\n\n```bash\npython3 -m pip install -e .[dev]\n```\n\nHermes Vault targets Python 3.11+.\n\n## For Contributors\n\nStart with [CONTRIBUTING.md](CONTRIBUTING.md) for local setup, safe test vault usage, test commands, and PR expectations.\n\nQuick contributor loop:\n\n```bash\nuv sync --extra dev\nuv run python -m pytest tests\u002F -q\n```\n\nOr with an editable pip install:\n\n```bash\npython3 -m venv .venv\nsource .venv\u002Fbin\u002Factivate\npython -m pip install -e '.[dev]'\npython -m pytest tests\u002F -q\n```\n\nHelpful docs:\n\n- [Contributor architecture map](docs\u002FARCHITECTURE.md)\n- [Detailed architecture notes](docs\u002Farchitecture.md)\n- [Operator guide](docs\u002Foperator-guide.md)\n- [MCP server guide](docs\u002Fmcp-server.md)\n- [Threat model](docs\u002Fthreat-model.md)\n- [Credential lifecycle](docs\u002Fcredential-lifecycle.md)\n\nFor issues and PRs, use the GitHub templates. Never paste real tokens, passphrases, vault databases, provider token responses, or unredacted `.env` files into issues, docs, tests, logs, or screenshots.\n\n## Update\n\nCheck for the latest tagged release without changing the environment:\n\n```bash\nhermes-vault update --check\n```\n\nApply a guarded update:\n\n```bash\nhermes-vault update\n```\n\n`hermes-vault update` currently auto-updates only for `pipx` and `uv tool` installs. Editable\u002Fdev installs, generic `pip` installs, and unknown environments receive an explicit manual command instead of an automatic mutation.\n\n## Quick Start\n\n```bash\nexport HERMES_VAULT_HOME=~\u002F.hermes\u002Fhermes-vault-data\nexport HERMES_VAULT_PASSPHRASE='choose-a-strong-local-passphrase'\nhermes-vault --help\nhermes-vault bootstrap --from-env ~\u002F.hermes\u002F.env --agent hermes --dry-run\nhermes-vault bootstrap --from-env ~\u002F.hermes\u002F.env --agent hermes\nhermes-vault verify --all\nhermes-vault policy doctor\nhermes-vault generate-skill --all-agents\nhermes-vault dashboard --no-open\n```\n\nDefault runtime state lives in `~\u002F.hermes\u002Fhermes-vault-data`. The first `list`, `scan`, import, or bootstrap command initializes the runtime layout and default policy if they don't exist yet. Preview imports and recovery operations before mutating the vault.\n\n## First Safe Agent Bootstrap\n\nv0.11.0 adds the guided path from `.env` to safe agent access:\n\n```bash\nhermes-vault bootstrap --from-env .env --agent hermes --dry-run --json\nhermes-vault bootstrap --from-env .env --agent hermes\n```\n\nThe bootstrap report is deliberately redacted. It shows importable env names, skipped env names, policy-doctor summary, generated skill contract path, broker-env next command, and an MCP config snippet. It never prints secret values. `--dry-run` does not mutate the vault or the source `.env` file. Non-dry-run imports mapped credentials into the encrypted local vault, and `--redact-source` comments out only lines that were successfully imported.\n\nUse repeatable `--map ENV_NAME=service:credential_type` when an env name is intentionally non-standard:\n\n```bash\nhermes-vault bootstrap --from-env .env --agent coder --map CUSTOM_VENDOR_TOKEN=custom-vendor:api_key\n```\n\nFor browserless first login, use either explicit device login or the unified headless shortcut:\n\n```bash\nhermes-vault oauth device-login google --alias work\nhermes-vault oauth login google --alias work --headless\n```\n\nProviders without device-code support fail closed and tell you to use the browser callback path with `--no-browser` instead.\n\n## Importing `.env` Files\n\nPreview first:\n\n```bash\nhermes-vault import --from-env .env --dry-run\n```\n\nThe env importer reports both importable names and skipped names. Known hints and safe suffixes are imported automatically: `*_API_KEY`, `*_TOKEN`, `*_AUTH_TOKEN`, and `*_ACCESS_TOKEN`. Public config such as `NEXT_PUBLIC_*`, broad DB URLs, passwords, JWT\u002Fsession\u002Fapp secrets, and unknown names stay skipped unless you explicitly map them.\n\nUse repeatable `--map` overrides when a skipped key is intentional:\n\n```bash\nhermes-vault import --from-env .env --map CUSTOM_VENDOR_TOKEN=custom-vendor:personal_access_token\nhermes-vault import --from-env .env --map DATABASE_URL=postgres:connection_url\n```\n\nWhen `--redact-source` is used, only successfully imported env lines are commented out. Skipped lines remain unchanged and are counted in the summary. `--dry-run --redact-source` never changes the source file.\n\n## Hermes Vault Console\n\nHermes Vault Console, introduced in v0.8.0, is the local dashboard for the credential broker. It gives operators one browser view of vault health, credential metadata, policy drift, audit activity, MCP binding, recovery posture, and safe operations without turning the browser into a secret viewer.\n\nLaunch it from the same machine that owns the vault:\n\n```bash\nhermes-vault dashboard\nhermes-vault dashboard --no-open\nhermes-vault dashboard --port 8765\nhermes-vault dashboard --ttl-seconds 3600\n```\n\nUse `--no-open` for headless or remote terminal sessions, then open the printed URL from a local browser that can reach `127.0.0.1` on that machine.\n\nThe console runs locally on `127.0.0.1` with token-guarded access. The launch command prints a process-local tokenized URL, and API calls need that token until the TTL expires or the process stops. The browser UI is served from packaged static assets under `hermes_vault\u002Fdashboard_static\u002F`; packaged installs need those assets present in the wheel or source distribution. API responses redact raw secret and token material, so browser clients receive metadata and bounded action results rather than credential payloads. Keep treating the browser session as local operator access, not as a remote admin surface.\n\nDashboard views include Health, Credential Inventory, Policy Findings, Audit Activity, MCP Binding Status, Recovery Posture, and Operations Panel. Together they answer the questions an agent operator needs before handing credentials to autonomous systems: is the vault healthy, are credentials stale or invalid, is policy least-privilege, is MCP bound to the expected agents, can backups be verified, and what would maintenance do next?\n\nDashboard actions stay inside a conservative safety boundary. The console can run health checks, policy doctor, credential verification, OAuth refresh dry-run, maintenance dry-run, backup verification, and restore dry-runs. Live token refresh, live maintenance mutation, credential editing, policy editing, destructive restore, cloud sync, raw encrypted payload display, and remote binding stay out of the console.\n\n![Hermes Vault Console overview](docs\u002Fassets\u002Fv0.8.0-dashboard\u002Fdashboard-overview.png)\n\nScreenshot set captured with a temporary demo vault and fake\u002Fdemo credentials only:\n\n- [Health view](docs\u002Fassets\u002Fv0.8.0-dashboard\u002Fdashboard-health.png)\n- [Credential Inventory view](docs\u002Fassets\u002Fv0.8.0-dashboard\u002Fdashboard-credential-inventory.png)\n- [Audit Activity view](docs\u002Fassets\u002Fv0.8.0-dashboard\u002Fdashboard-audit-activity.png)\n- [MCP Binding Status view](docs\u002Fassets\u002Fv0.8.0-dashboard\u002Fdashboard-mcp-status.png)\n- [Recovery Posture view](docs\u002Fassets\u002Fv0.8.0-dashboard\u002Fdashboard-recovery-posture.png)\n- [Operations Panel view](docs\u002Fassets\u002Fv0.8.0-dashboard\u002Fdashboard-operations.png)\n\nThe screenshots and launch notes above document the v0.8.0 dashboard launch. They remain accurate for the current local console safety boundary unless a later release note says otherwise.\n\n## MCP Server\n\nHermes Vault exposes the broker as an MCP (Model Context Protocol) server so that compatible hosts can request credentials programmatically.\n\n```bash\nhermes-vault mcp\n```\n\nConfigure your MCP host (Claude Desktop, Cursor, etc.) to run:\n\n```json\n{\n  \"mcpServers\": {\n    \"hermes-vault\": {\n      \"command\": \"hermes-vault\",\n      \"args\": [\"mcp\"],\n      \"env\": {\n        \"HERMES_VAULT_PASSPHRASE\": \"your-passphrase\"\n      }\n    }\n  }\n}\n```\n\nIf the MCP server is started without an allowed-agent binding, every tool call still requires a caller-supplied `agent_id`. When the server is launched with both `HERMES_VAULT_MCP_ALLOWED_AGENTS` and `HERMES_VAULT_MCP_DEFAULT_AGENT`, the host may omit `agent_id` and the server uses the configured default agent within that allowed set.\n\nExample bound launch:\n\n```bash\nexport HERMES_VAULT_MCP_ALLOWED_AGENTS='hermes,claude-desktop'\nexport HERMES_VAULT_MCP_DEFAULT_AGENT='claude-desktop'\nhermes-vault mcp\n```\n\nThe same `policy.yaml` that gates CLI access also gates MCP access. The bound-agent env vars are a deployment guardrail, not a replacement for policy.\n\n### MCP Tools\n\n| Tool | Description | Policy Gate |\n|---|---|---|\n| `list_services` | List credentials visible to the agent | `capability:list_credentials` |\n| `get_credential_metadata` | Fetch credential metadata (no secrets) | `can_read(service)` |\n| `get_ephemeral_env` | Materialise ephemeral env vars | `can_env(service)` |\n| `verify_credential` | Verify a credential against its provider | `can_verify(service)` |\n| `rotate_credential` | Rotate a credential to a new secret | `can_rotate(service)` |\n| `scan_for_secrets` | Scan filesystem for plaintext secrets | `capability:scan_secrets` |\n| `oauth_login` | Initiate PKCE OAuth login (returns auth URL) | `capability:add_credential` |\n| `oauth_refresh` | Refresh an OAuth access token using stored refresh token | `action:rotate` |\n\nMCP access is brokered through policy-gated tools. Prefer `get_ephemeral_env` for TTL-bounded environment materialization instead of direct raw-secret handling.\n\n### OAuth via MCP\n\nHermes Vault can broker OAuth logins so agents avoid raw-password handling. `oauth_login` returns an authorization URL and spins up a local callback server -- open the URL in a browser, and tokens are stored automatically. `oauth_refresh` renews existing OAuth tokens proactively before expiry. This is still callback-based PKCE login plus unattended refresh, not device-code or truly browserless first login. See [docs\u002Fmcp-server.md](docs\u002Fmcp-server.md) for full tool schemas.\n\n## Common Commands\n\n```bash\nhermes-vault scan\nhermes-vault update --check\nhermes-vault import --from-env ~\u002F.hermes\u002F.env --dry-run\nhermes-vault import --from-env ~\u002F.hermes\u002F.env\nhermes-vault import --from-env ~\u002F.hermes\u002F.env --map CUSTOM_VENDOR_TOKEN=custom-vendor:personal_access_token\nhermes-vault add openai --alias primary\nhermes-vault list\nhermes-vault verify openai\nhermes-vault broker env openai --agent dwight --ttl 900\nhermes-vault audit --agent dwight --since 7d\nhermes-vault status\nhermes-vault status --stale 7d\nhermes-vault status --invalid\nhermes-vault set-expiry openai --alias primary --days 90\nhermes-vault clear-expiry openai --alias primary\nhermes-vault verify --all --format table\nhermes-vault verify --all --report ~\u002F.hermes\u002Fhermes-vault-data\u002Freports\u002Fverify-latest.json\nhermes-vault health\nhermes-vault health --format json\nhermes-vault maintain --dry-run\nhermes-vault maintain\nhermes-vault maintain --print-systemd\nhermes-vault dashboard --no-open\nhermes-vault policy doctor\nhermes-vault oauth normalize\nhermes-vault backup-verify --input ~\u002Fvault-backup.json\nhermes-vault restore --dry-run --input ~\u002Fvault-backup.json\nhermes-vault sync-skill --check\nhermes-vault backup --metadata-only --output ~\u002Fmeta-backup.json\nhermes-vault diff --against ~\u002Fmeta-backup.json\nhermes-vault rotate-master-key\nhermes-vault oauth login google --alias work\nhermes-vault oauth refresh google --alias work\nhermes-vault oauth providers\n```\n\n## What's New in 0.10.1 - Device-Code Login\n\nv0.10.1 adds explicit OAuth device-code login for supported providers. Use it when you need first-time authorization on a headless machine or don't have a browser on the box.\n\n```bash\nhermes-vault oauth device-login google --alias work\n```\n\n`oauth login` is still the browser-based PKCE path, and `oauth refresh` still covers unattended renewal after a refresh token exists.\n\n## What's New in 0.10.0 - Unattended OAuth and Custom Verifiers\n\nv0.10.0 is the published partial unattended-auth release. It ships non-interactive refresh for OAuth credentials that already have a stored `refresh:\u003Calias>` token, plus generic custom verifier endpoints. It doesn't ship browserless first login or OAuth device-code login yet.\n\n### Unattended OAuth refresh\n`hermes-vault oauth refresh \u003Cservice>` is the non-interactive renewal path for stored OAuth credentials. It uses the paired `refresh:\u003Calias>` record, requires `rotate` permission on the service, and is also available through `hermes-vault maintain` for scheduled runs. If a refresh token is missing or the provider refuses renewal, the command fails closed instead of guessing.\n\nInitial OAuth authorization still uses browser-based PKCE with a localhost callback. Use `--no-browser` when you need to copy the authorization URL manually, but don't treat that as device-code support.\n\n### Generic custom verifiers\n`HERMES_VAULT_VERIFY_URL_\u003CSERVICE>` lets you point any service at a custom OpenAI-compatible verification endpoint without writing a plugin. Service names normalize hyphens, dots, and spaces to underscores and are uppercased, so `deepseek` becomes `HERMES_VAULT_VERIFY_URL_DEEPSEEK`.\n\n## What's New in 0.9.0 - Profiles, Verifiers, and MCP Expansion\n\n### Verifier plugin architecture\nv0.9.0 introduces a modular, file-based YAML verifier plugin system (under `src\u002Fhermes_vault\u002Fverifiers\u002F`). This allows operators to define custom validation checks for new services and register them via entry points, while maintaining backward compatibility with built-in verifiers.\n\n### Multi-vault profile support\nEnables complete profile isolation via CLI flags like `--profile work` and `--profile personal`. Each profile manages its own isolated SQLite database, custom policies, OAuth registries, and verifier plugins. Pending OAuth states are scoped to prevent token pollution, and profile contexts propagate properly across worker threads (including MCP and local dashboard launches). Profiles support dedicated passphrases via environment variables like `HERMES_VAULT_PASSPHRASE_PROFILE`.\n\n### MCP read-only resources\nExposes `vault:\u002F\u002Fservices`, `vault:\u002F\u002Fservices\u002F{name}`, `vault:\u002F\u002Fhealth`, and `vault:\u002F\u002Fpolicy` as Model Context Protocol (MCP) resources. The resources are agent-bound and policy-scoped, returning metadata and status summaries only—ensuring raw secrets and encrypted payloads are never exposed to the host.\n\n### Credential tags and notes\nAdds support for persistent top-level tags and notes. Operators can supply tags and notes via the CLI (`add --tag \u002F --note`), update them, view them in metadata commands, and expose them programmatically in dashboard and MCP tool returns.\n\n### Community onboarding\nImproves community onboarding with standardized repository guides:\n- [CONTRIBUTING.md](CONTRIBUTING.md): Setup instructions, test suites, and contributor rules.\n- [docs\u002FARCHITECTURE.md](docs\u002FARCHITECTURE.md): Contributor-focused module layouts and security boundary maps.\n- GitHub issue templates (`bug.md`, `feature.md`, `verifier.md`) and pull request template (`PULL_REQUEST_TEMPLATE.md`).\n\n## What's New in 0.8.0 - Hermes Vault Console\n\n### Local operator console\n`hermes-vault dashboard` serves Hermes Vault Console from packaged assets on `127.0.0.1` with token-guarded access. It adds a local browser surface for Health, Credential Inventory, Policy Findings, Audit Activity, MCP Binding Status, Recovery Posture, and Operations Panel. The wheel and sdist need the `hermes_vault\u002Fdashboard_static\u002F` package data for installed dashboard launches.\n\n### Safe action boundary\nThe console uses existing service-layer workflows for visibility and guarded operator actions: health, policy doctor, credential verification, OAuth refresh dry-run, maintenance dry-run, backup verification, and restore dry-run. Live OAuth refresh and live maintenance stay in the CLI. Raw secret display, raw token display, encrypted payload display, credential or policy editing, destructive restore, cloud sync, and remote binding stay out of the dashboard.\n\n### Redaction and README screenshots\nDashboard responses serialize credential metadata and bounded action output, not raw secret\u002Ftoken material or encrypted payloads. The release documentation includes demo screenshots under `docs\u002Fassets\u002Fv0.8.0-dashboard\u002F`, captured from a temporary demo vault with fake\u002Fdemo credentials only.\n\n## What's New in 0.7.0 - Operational Autonomy\n\n### Maintenance command\n`hermes-vault maintain` is the v0.7.0 operator entry point for scheduled-safe OAuth refresh, health checks, stale-verification checks, and backup-age warnings. `--dry-run` reports what would happen without mutating tokens. `--format json` is available for automation.\n\n### Policy doctor\n`hermes-vault policy doctor` inspects `policy.yaml` for least-privilege drift, unknown services or actions, legacy capability grants, risky `raw_secret_access` settings, stale generated skills, and OAuth readiness gaps. Use `--strict` to fail CI or scheduled checks on high-risk findings.\n\n### OAuth storage normalization\nv0.7.0 adds `hermes-vault oauth normalize` to migrate older OAuth records to sanitized metadata and alias-scoped refresh pairing. Access-token metadata keeps provider-safe fields such as `token_type`, `provider`, `issued_at`, `expires_at`, and `scopes`. Refresh tokens are stored separately under `refresh:\u003Calias>` with the associated access-token alias recorded in metadata.\n\n### MCP agent binding\n`HERMES_VAULT_MCP_ALLOWED_AGENTS` and `HERMES_VAULT_MCP_DEFAULT_AGENT` let operators bind a running MCP server to a known agent set. In bound mode, `agent_id` can be omitted only when the default agent is configured and allowed; otherwise the host must still supply `agent_id`.\n\n### Backup verification and drill\nv0.7.0 adds `hermes-vault backup-verify --input \u003Cbackup-file>` and a non-mutating restore drill (`hermes-vault restore --dry-run --input \u003Cbackup-file>`) so operators can prove recovery before they need it. `maintain` can fold backup-age warnings into the same scheduled run.\n\n### Systemd helper output\n`hermes-vault maintain --print-systemd` emits a safe service\u002Ftimer example for recurring maintenance without forcing the CLI to install units automatically.\n\n## What's New in 0.6.0 - OAuth PKCE and Token Auto-Refresh\n\n### OAuth PKCE login\n`hermes-vault oauth login \u003Cprovider>` initiates a browser-based PKCE login flow. Tokens are stored in the vault automatically. Supports `--no-browser`, custom `--scope`, and `--alias`. Built-in providers: `google`, `github`, `openai`. Custom providers can be added via YAML.\n\n### Token auto-refresh engine\n`hermes-vault oauth refresh \u003Cservice>` detects expired or nearly-expired access tokens (default 5-minute proactive margin) and refreshes them using stored refresh tokens. Supports `--all`, `--dry-run`, and configurable `--margin`. Exponential backoff with configurable `max_retries`.\n\n### MCP OAuth tools\n`oauth_login` and `oauth_refresh` are available as MCP tools when Hermes Vault is registered as an MCP server. Agents can initiate logins and trigger refresh without touching raw tokens.\n\n### Provider registry\nOAuth providers are configured in `~\u002F.hermes\u002Fhermes-vault-data\u002Foauth-providers.yaml`. The file seeds itself with baked-in defaults on first use. Add custom providers without code changes.\n\n### Security invariants preserved\nThe flow avoids raw token logging, keeps browser state local to the login process, uses timing-safe CSRF state comparison, stores refresh tokens separately from access tokens, and updates vault records through SQLite transactions.\n\n## What's New in 0.5.0 - Health, Governance, and Key Rotation\n\n### Vault health command\n`hermes-vault health` runs a read-only check across stale\u002Finvalid\u002Fexpired credentials\nand backup age. Exit codes: 0 = healthy, 1 = warnings found. JSON and markdown output.\n\n### Master-key rotation\n`hermes-vault rotate-master-key` re-encrypts every credential under a new passphrase\nwith atomic rollback. Creates an encrypted pre-rotation backup by default.\n\n### Skill sync with policy hashing\n`hermes-vault sync-skill --check` \u002F `--write` \u002F `--print` keeps the\n`hermes-vault-access` SKILL.md in sync with current policy. Generated skills embed\na SHA-256 policy hash so stale detection is deterministic.\n\n### Metadata-only backup and vault diff\n`hermes-vault backup --metadata-only` exports metadata without encrypted payloads.\n`hermes-vault diff --against \u003Cpath>` compares current vault against a backup.\n\n### Governance warnings\nExpiry and backup reminders appear in broker `get_ephemeral_env` decision metadata\nunder `warnings[]`. Configurable via `HERMES_VAULT_EXPIRY_WARNING_DAYS` and\n`HERMES_VAULT_BACKUP_REMINDER_DAYS`. Warnings contain metadata only, not raw secrets.\n\n## What's New in 0.4.0 - Credential Observability\n\n### Audit query CLI\nhermes-vault audit with --agent, --service, --action, --decision,\n--since\u002F--until (relative or ISO date), --format table|json, --limit.\n\n### Credential status CLI\nhermes-vault status with --stale Nd, --invalid, --expiring Nd,\n--format table|json. Credentials with no last_verified_at are always stale.\n\n### Expiry metadata commands\nhermes-vault set-expiry (--days N or --date YYYY-MM-DD) and\nhermes-vault clear-expiry. Both write audit entries. Expiry round-trips\nthrough backup and restore.\n\n### Verification report output\nhermes-vault verify --all now accepts --format table and --report PATH.\nDefault JSON-to-stdout behavior is unchanged.\n\n### Security invariants preserved\nNo secrets in audit, status, or verification output. No background\nprocesses. No auto-rotation. No cloud sync.\n\n## What's New in 0.2.0\n\n### Canonical Service IDs\n\nAll service names are normalized to canonical IDs automatically. `open_ai`, `open-ai` → `openai`; `gmail`, `google_docs` → `google`; `gh` → `github`. See [docs\u002Foperator-guide.md](docs\u002Foperator-guide.md) for the full alias table.\n\n### Deterministic Credential Selectors\n\nCommands that target a credential accept three forms:\n\n- **credential ID** (UUID): exact credential match\n- **service + `--alias`**: exact service and alias match\n- **service only**: works only when exactly one credential exists for that service\n\nIf you have multiple credentials for the same service (e.g. `github` with aliases `work` and `personal`), the CLI fails with an `Ambiguous` error and asks for `--alias` or the credential ID.\n\nCommands that use selectors: `verify`, `rotate`, `delete`, `show-metadata`.\n\n### Policy v2\n\nPolicy now supports per-service action permissions:\n\n```yaml\nagents:\n  dwight:\n    services:\n      openai:\n        actions: [get_credential, get_env, verify, metadata]\n        max_ttl_seconds: 900\n      github:\n        actions: [get_env, verify, metadata]\n    max_ttl_seconds: 900\n```\n\nLegacy flat-list format (`services: [openai, github]`) still works and grants all actions.\n\n### Agent Capabilities\n\nNon-service-scoped actions are gated by agent-level capabilities:\n\n| Capability | Controls |\n|---|---|\n| `list_credentials` | `broker list` |\n| `scan_secrets` | `scan` |\n| `export_backup` | `backup` |\n| `import_credentials` | `import` |\n\nIf `capabilities` is omitted from an agent's policy, all capabilities are implicitly granted (backward compatible).\n\n### Centralized Mutation Paths\n\nAll write\u002Fdestructive operations (add, rotate, delete, metadata) flow through `VaultMutations`, a centralized, policy-checked, audited mutation layer. The operator CLI path skips policy checks but still produces audit entries.\n\n## Configuration\n\n```bash\nexport HERMES_VAULT_HOME=~\u002F.hermes\u002Fhermes-vault-data\nexport HERMES_VAULT_POLICY=~\u002F.hermes\u002Fhermes-vault-data\u002Fpolicy.yaml\nexport HERMES_VAULT_NO_BANNER=1\n```\n\nIf you need a starting policy, copy `policy.example.yaml` into the runtime home and edit the agent allowlists there.\n\n## Notes\n\n- The master key is derived at runtime from `HERMES_VAULT_PASSPHRASE`\n- A separate local salt file is stored beside the vault database\n- If the database exists but the salt is missing, Hermes Vault fails closed instead of silently re-keying the vault\n- Generated skills are review artifacts unless you explicitly install them\n\n## More Detail\n\nSee [docs\u002Farchitecture.md](docs\u002Farchitecture.md), [docs\u002Fthreat-model.md](docs\u002Fthreat-model.md), [docs\u002Fcredential-lifecycle.md](docs\u002Fcredential-lifecycle.md), [docs\u002Foperator-guide.md](docs\u002Foperator-guide.md), [docs\u002Fmigration-0.1-to-0.2.md](docs\u002Fmigration-0.1-to-0.2.md), [docs\u002Fmigration-0.5-to-0.6.md](docs\u002Fmigration-0.5-to-0.6.md), [docs\u002Fmigration-0.6-to-0.7.md](docs\u002Fmigration-0.6-to-0.7.md), and [docs\u002Fupdate-workflow.md](docs\u002Fupdate-workflow.md).\n","Hermes Vault 是一个本地优先的凭证代理、扫描器和加密存储库，专为Hermes代理设计。它能够扫描文件中的明文秘密信息、重复项及不安全权限，并将凭证以加密形式存储于本地SQLite支持的保险库中。此外，该项目还提供基于每个代理策略的访问控制、临时环境构建、凭证验证以及OAuth凭证刷新等功能，同时生成`SKILL.md`文件来保持工作流程一致性和通过令牌保护的本地仪表板供操作员使用。适合需要对敏感信息进行严格管理和自动化处理的安全性要求较高的场景。",2,"2026-06-11 02:46:55","CREATED_QUERY"]