Use cases

A VTA combines identity issuance, remote signing, credential issuance, 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. The VTA repository includes an MCP (Model Context Protocol) server, vta-mcp. You run it next to your MCP host, and it exposes the VTA’s 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 that reaches the VTA runs as an authenticated, policy-checked operation, so the bridge adds no authority of its own over the VTA. The issue_vp tool signs locally, with a holder key you configure on the bridge.

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

Issue, hold, and present verifiable credentials

Your VTA signs credentials as an issuer and keeps the credentials it receives as a holder, with the signing keys staying in the VTA.

Issuing a credential usually means running a signing service with its own issuer key, and holding one means a separate wallet. A VTA takes both roles under the same access control list and audit trail, in both Isolated and Shared mode:

• Issuer: a super admin, in a session stepped up to AAL2, calls the vta/credentials/issue Trust Task through the VTA SDK’s issue_credential method, naming the holder DID, the claims, and how long the credential is valid. The VTA returns a W3C Verifiable Credentials Data Model 2.0 credential issued by the VTA’s own DID and signed with an eddsa-jcs-2022 Data Integrity proof, and records it so it can later be revoked.
• Holder: pnm cred-vault receive checks a received credential’s proof and validity period, then stores it in the VTA’s credential vault. pnm cred-vault query and pnm cred-vault get find it again.
• Presenting: the SDK’s vp module builds a signed Verifiable Presentation from held credentials, with a holder key you supply. The vta-mcp bridge offers the same as its issue_vp tool.
• Verifier: the proof is a standard Data Integrity proof, so a verifier that supports the eddsa-jcs-2022 cryptosuite checks it by resolving the issuer’s DID. Revocation is recorded on the issuing VTA, and the credential itself carries no status list entry.

Related