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 a sealed secret. The signing key never leaves the VTA. A released secret reaches your service only inside a sealed bundle, 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

A signing key embedded in a service’s config or environment variables has to be redeployed to rotate, has no central audit trail, and cannot be revoked without taking the service offline. A VTA holds the key instead: your service sends it an unsigned payload over REST or DIDComm and gets back a signature, and the key itself never leaves the VTA’s process. Rotating or revoking access becomes an ACL change, not a redeploy.

See Sign application payloads without exposing your keys.

Centralise secrets across microservices

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 in a sealed bundle at runtime, rather than holding a standing copy. Every release is 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

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 context-scoped VTA vault 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

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 isolated 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

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