Use cases

A VTA combines identity issuance, remote signing, secrets delivery, and agent memory into one system governed by a single access control list and audit trail. Signing and secret release both work the same way: your application sends an unsigned payload or a request for a secret, the VTA checks the caller’s role, and returns a signature or an encrypted secret. The signing key stays in the VTA. A released secret reaches your service encrypted to its own key, at runtime, rather than sitting in its configuration or your source control.

The scenarios below are where each capability actually earns its place in a real project.

Remote signing for backend services

Your service sends a payload and gets a signature back, while the signing key stays in the VTA.

A signing key embedded in a service’s config or environment variables has to be redeployed to rotate, has no central audit trail, and revoking it means redeploying every instance that holds it. A VTA holds the key instead: your service sends it an unsigned payload over REST or DIDComm and gets back a signature without the key leaving the VTA. Revoking a service’s access becomes an ACL change, not a redeploy.

See Sign application payloads without exposing your keys.

Centralise secrets across microservices

Services fetch each secret from the VTA at runtime instead of holding their own copy.

Each service holding its own copy of API keys, database credentials, or third-party tokens in environment variables means rotating one requires touching every service that has a copy, with no single point to audit who read what. Services can instead authenticate to the VTA and retrieve a secret, encrypted to their own key, at runtime, rather than holding a standing copy. Releases are recorded in the audit trail.

See Secrets vault for what it stores, then Keep API tokens out of your service config and Retrieve credentials from the VTA vault at runtime.

Give an AI agent persistent memory without a database

An agent stores its working state in its VTA’s agent memory store and reads it back after a restart.

A stateless agent runtime loses its working state, checkpoints, or user preferences every time the process restarts, and standing up a separate database just for that state is disproportionate. An agent can instead store key-value memory in its VTA’s context-scoped agent memory store and read it back on restart, governed by the same ACL as its signing keys, with no separate database to run.

See Persist AI agent state across sessions.

Isolate keys and access per application

Each application gets its own context, with its own keys and its own access control list.

A shared secrets store where every application authenticates the same way means a single compromised application can potentially reach every other application’s keys and secrets. Contexts avoid that: each application gets its own separate branch of derived keys and its own access control list, all under one VTA.

See Keys and contexts and Roles and access.

Drive a VTA directly from an AI coding assistant or MCP host

An MCP host calls the VTA’s signing, vault, and key operations as tools through the vta-mcp bridge.

Wiring a custom integration between an AI agent framework and a signing or secrets backend is real engineering effort, usually duplicated per project. A VTA ships with an MCP (Model Context Protocol) server, vta-mcp, that exposes its signing, vault, and key-listing operations as MCP tools. Any MCP-speaking host, including Claude Code and Claude Desktop, can then drive a VTA with no custom integration code. Every tool call still runs as an authenticated, policy-checked operation against the VTA. The bridge adds no authority of its own.

See Connect an MCP host to your VTA to set it up.

Related