UnENVerse Find a guide: importing, command line, nodes

Guides / LLM support

UnENVerse for LLMs and AI agents

An agent needs to use a credential, not read it. UnENVerse gives it a command line that does the first and refuses the second, in as few tokens as the job allows.

The command line is the interface

There is no separate agent protocol to install. An agent drives unv the way it drives git. The desktop app, the CLI and unv-server share one Rust core and one vault, so what the app shows is what the CLI returns. The app does not need a model in the loop; the CLI is where an agent works.

The project looked at an MCP server and chose not to build one. An MCP server adds a long-running process and a tool list that the model has to load into its context on every session. unv adds nothing to the context until the agent runs a command. If your agent only speaks MCP, wrap unv in a thin tool of your own; the contract below is stable enough for that.

Why it costs few tokens

  • One call describes everything. unv describe prints the whole command tree, every flag, the exit codes and the output envelope as JSON, generated from the same definition the binary runs on. The agent reads it once instead of guessing from error messages or paging through help.
  • Output is small and fixed. With --json every command answers with the same envelope. A stored value is printed as a fingerprint and a length (sha256:d4291adb444f, 40 characters), never as the value.
  • Equal fingerprints mean equal secrets. The agent can check for drift and duplicates without any value entering its context.
  • Exit codes carry the answer. Not found, ambiguous, denied, conflict and invalid input each have their own code, so a retry loop needs no parsing of prose.

Name a secret by its variable, not by an id

Every value an entry holds becomes an environment variable named PROVIDER_ROLE: X_KEY, X_COOKIE, X_USER, X_PASSWORD. The role says what the value is. That name is the handle:

unv get X_COOKIE --field api_key --reveal
unv exec --entry X_COOKIE -- ./scraper

Two entries for the same site that differ by role (a key and a cookie) need no key id to tell them apart. A key id, label or version is only for two credentials of the same role, such as a second API key. A bare provider name that matches several entries is refused with exit code 4 and the candidates, never guessed.

Use a secret without reading it

unv exec --entry GitHub -- gh api user      # run a program with the value in its environment
unv render nginx.conf.tpl --out nginx.conf  # build a file from ${Entry/field} references
unv get GitHub                              # fingerprint and length only

Only --reveal, --out, exec and render materialise a value. A vault-wide export to the terminal is refused, not masked. This protects the conversation with the agent, not the machine: a process started by unv exec can read its own environment.

Every AI feature

  • Redacted by default. Every stored value prints as a fingerprint and a length; --reveal is opt-in and meant for a human at a terminal. A ${ref} is never masked, so an agent can wire configs together blind.
  • Use without reading. unv exec runs a program with the value in its environment, unv render and unv get --out write it to a file, and env, emit, curl, cookie and file write do the same for other shapes. None of them print the value.
  • Secrets nobody sees. unv entry add NAME --generate and entry rotate NAME --generate create the value inside the process that stores it; the caller gets a fingerprint back. user token new checks the output policy before it mints.
  • Output shield. unv shield -- COMMAND runs a command and replaces known vault values in its stdout and stderr, so a tool that echoes a token does not put it in the transcript. It is explicit; normal output is untouched.
  • One contract, one call. unv describe prints every command, flag, exit code and the output envelope as JSON, generated from the same definition the binary runs on.
  • Machine-readable results. With --json every command answers {ok, command, data} or {ok:false, error:{code, message, details}}. Ten exit codes separate not found (3), ambiguous (4), denied (5), conflict (6), unavailable (7), needs confirmation (8), redacted (9) and invalid (10), so a retry loop never parses prose.
  • Never guesses, never assumes yes. An ambiguous name exits 4 with details.candidates; a destructive command with no --yes and no terminal exits 8; --dry-run is enforced inside the single write point, so a command that forgets to check it still cannot write.
  • Least privilege for the agent. unv user token new mints a scoped API token for a sub-user; classes and perm limit what that user can read or write, and strict-write can be switched on per user or class. The agent gets a token, not the master password.
  • Key pools. Several interchangeable keys for one service; unv pool next openai returns the next one that is not cooling and a rate-limited key can be marked cooling, so an agent rotates through keys without a human.
  • Web sessions. A cookie entry holds the jar and what it was minted against (User-Agent, origin, header recipes such as x-csrf-token copied from a cookie); unv curl and unv cookie use it without printing it.
  • Checks an agent can run. unv scan reports weak, expiring, duplicated and stale-reference secrets, unv doctor checks vault integrity, and unv audit verifies a hash-chained audit log. Each exits non-zero when something is wrong.
  • Project context. unv use pins a project and environment to the current directory, so an agent in that folder needs no flags.
  • The password stays out of argv. --password-command, --password-file, --env-file and UNV_PASSWORD keep the master password off the command line and out of the process list.
  • A human gate for production. A node can require a signed approval before the hub pushes a config to a host, so an agent can propose a change and only you can ship it.
  • Readable by models. This site publishes /llms.txt, /llms-full.txt and /agents.txt.