Integration guides

How-to guides for building on top of VTA: sign application payloads using VTA-held keys, persist agent state across sessions using context-scoped memory, access external APIs without exposing credentials, and drive a VTA directly from an MCP host.

Signing keys, API tokens, and agent state tend to end up copied into every service instance that needs them, where rotating one means redeploying all of them and nothing records who used what. A VTA holds that material instead and acts on the application’s behalf, with every call addressed by the application’s own DID and bounded by its role and context. Rotating or revoking access becomes a change on the VTA rather than a release, and every operation lands in one audit trail. Sign application payloads without exposing your keys →

Choose the guide that matches what you are building.

Shared setup: most guides in this section start with the same one-time bootstrap:

  • Create a context.
  • Provision an app identity with the application role.
  • Authenticate at runtime with the credential.

New to VTA? Start with Sign application payloads without exposing your keys, which also covers minting a signing key.

Sign application payloads without exposing your keys→

Sign application payloads using a key the VTA holds, instead of distributing signing keys to every service instance. The private key never leaves the server.

Give your AI agent persistent memory→

Store, retrieve, and delete AI agent state using the VTA’s per-context key/value memory store. Access is governed by the same DID-based ACL as signing and vault, and every read and write is audited.

Connect an MCP host to your VTA→

Run vta-mcp so an MCP-speaking host like Claude Code or Claude Desktop can sign, read the vault, and manage a VTA directly as tools, with no custom integration code.

Keep API tokens out of your service config→

Store an API token in the VTA vault and release it to services at runtime, using a GitHub PAT as the example.