The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Veeam AIops listing page.
Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by Veeam Software. "Veeam" is a trademark of its owner. MIT licensed.
AI-powered Veeam Backup & Replication operations with a built-in governance
harness — unified audit log, policy engine, token/runaway budget guard,
undo-token recording, and descriptive risk tiers. Self-contained: no
external dependencies beyond httpx and the MCP SDK. Coverage is not yet full
coverage of every Veeam operation.
Verification status: the test suite is mock-based; this package has not yet been validated against a live Veeam B&R server. See docs/VERIFICATION.md.
veeam-aiops ...): init, overview, job list/get/start/stop/retry/enable/disable, restore list-points/start, repository list/get/state, session list/get/log/stop, backup list/objects/usage/ranking, diagnose job-failures/repo-capacity, infra servers/proxies, secret set/list/rm/migrate/rotate-password, doctor, mcp.veeam-aiops mcp or veeam-aiops-mcp): 27 tools (19 read, 8 write), every one wrapped with the bundled @governed_tool harness.diagnose job-failures triages recent job sessions — flags every Failed/Warning run and categorizes the likely cause (repository full, source/guest unreachable, credential/VSS failure, retry exhaustion), citing the session result + matched error substring; diagnose repo-capacity flags repositories under the free-space thresholds (<15% warn, <10% critical). Both cite the measured number that tripped each finding, worst-first.~/.veeam-aiops/secrets.enc (Fernet + scrypt) — never plaintext on disk. Unlock with a master password from VEEAM_AIOPS_MASTER_PASSWORD (MCP/CI) or an interactive prompt (CLI).high risk.session list / session get / session log (the runaway budget guard prevents poll loops from running away).It delivers Veeam Backup & Replication operations — reads and writes — accurately and efficiently, and records every one of them. It does not decide whether a write is allowed to happen. That is the agent's judgement, or the permission of the Veeam account you connect it with: give that account a read-only or restricted role on the VBR server and the writes fail at the server — the place that actually owns the permission.
So there is no read-only switch, no policy file, no approval gate to configure.
The one thing the tool guarantees is that nothing is silent: every call, over
MCP and over the CLI alike, lands an audit row in ~/.veeam-aiops/audit.db,
and reversible writes still capture their before-state and record an inverse.
Each tool declares a
risk_level, kept in agreement with its[READ]/[WRITE]documentation tag by a test, and carried into the audit row as a descriptive tier — so a reviewer can see at a glance that a row was a high-risk restore. It is a label, not a gate.
Running a smaller / local model? See agent-guardrails.md — it lists the guardrails this tool now enforces for you (so you don't spend prompt budget restating them) and gives a ready-made system prompt for what's left.
One install gives an agent both the skill and the MCP server:
The MCP server is fetched with uv and pinned to the
package version this plugin declares, so an audit row can be traced back to the
code that wrote it. Credentials are still configured with veeam-aiops init — see below.
The same bundle is published on ClawHub, where one install delivers the skill and its MCP server together:
Restart the OpenClaw gateway afterwards so it loads the plugin. The MCP server is
fetched with uv, pinned to this exact release, so
uvx has to be on PATH — without it the skill still installs but reports
Visible to model: no. Credentials are configured exactly as below.
init writes ~/.veeam-aiops/config.yaml (non-secret connection details) and
stores the login password encrypted in ~/.veeam-aiops/secrets.enc. Example
config it produces:
On a large VBR installation the
/jobsand/sessionsendpoints can take far longer than the rest of the API — a live 13.1 environment did not answer a single-record/jobsquery inside 120 s while repositories answered in under 3 s.timeoutlets you give those endpoints longer. It does not make a slow endpoint fast: if a raised budget also expires, the endpoint is the bottleneck, not this client. The same holds for/backups/{id}/backupFiles, whichbackup rankingreads once per backup: a 123-backup 13.1 estate neededtimeout: 300for a complete ranking, and a backup that times out is flagged (timedOut) with this advice rather than silently left out. Scope the ranking (--backup,--repository) when you need part of the estate quickly.
For non-interactive use (MCP server, CI, cron) export the master password so the store can be unlocked without a prompt:
Where that password then lives: an exported variable is readable by every process this shell starts and is recorded by shell history. On a shared or long-lived host, prefer the interactive prompt, or inject it from a secret manager for the life of the one command that needs it.
Migrating from an old ~/.veeam-aiops/.env (legacy VEEAM_<TARGET>_PASSWORD
vars)? Run veeam-aiops secret migrate; the old .env is renamed to
.env.migrated. The plaintext env var is still honoured as a fallback (with a
deprecation warning) for a smooth transition.
All operations are logged to a local SQLite audit DB under ~/.veeam-aiops/
(relocatable via VEEAM_AIOPS_HOME) — the harness records, it does not
authorize. Every call, over MCP and the CLI alike, lands an audit row; the
token/runaway budget guard is a safety backstop (not an authorization gate) that
stops a stuck agent from burning unbounded calls, and each row carries a
descriptive risk tier that gates nothing. Destructive CLI commands (job stop,
restore start) require double confirmation and support --dry-run.
API-returned text is run through a prompt-injection sanitizer.
Coverage is intentionally focused. Missing a device, action, or feature you need? Open an issue or pull request at github.com/AIops-tools/Veeam-AIops — feature requests, contributions, and comments are all welcome.
License: MIT.