Overview
A Verifiable Trust Agent (VTA) sits between your applications and the key material they would otherwise hold themselves. They ask it to sign a payload, release a secret, or store state, and it does that on their behalf under an access policy you control. This page covers what it can do, how you reach it, and which use case to start from. Deploy an Affinidi-hosted VTA →
What is a Verifiable Trust Agent?
A VTA is not a vault, a wallet, or a certificate authority in the classical sense. It combines four capabilities you would otherwise assemble from separate tools: identity issuance, remote signing, secrets delivery, and agent memory. Each registered application and AI agent gets its own verifiable Decentralised Identifier (DID), and one context-scoped access control list and audit trail governs everything any of them does.
VTA’s identity, context, and authority model is based on the Trust Over IP Foundation’s Verifiable Trust Infrastructure (VTI) specification, an open, community-developed specification for exactly this kind of system.
The table below covers what that looks like in practice.
What you can do with a VTA
| Capability | What it means in practice |
|---|---|
| Own a verifiable digital identity | The VTA generates a DID for you. Any third party can resolve it to verify your signatures without relying on a centralised intermediary. |
| Sign without exposing keys | Applications send unsigned payloads and receive signatures. Keys are derived in memory and never exported unless you explicitly request key material. |
| Retrieve secrets at runtime | Services authenticate to the VTA and retrieve credentials, API keys, or tokens in a sealed bundle. The plaintext value is released into the service’s memory and never stored in configuration or environment variables. |
| Persist AI agent state | Store an AI agent’s working memory in the VTA vault. The agent retrieves its state on restart without a separate database, with access governed by the same context-scoped ACL as its signing keys. |
| Scope access per application | Contexts give each application its own isolated set of derived keys and access rules, all derived from the same master seed. |
| Audit every privileged action | Every operation is written to an append-only log: who acted, which key, which transport, and the outcome. Query the log at any time for operational review. |
| Export and migrate your data | Export an encrypted backup of your keys, identities, and access configuration at any time, and restore it to a fresh VTA instance or the same VTA, hosted or self-managed. Vault secrets, DID templates, and issued holder credentials are excluded, so keep a separate copy of those. |
How you interact with a VTA
Every operation is defined once and reachable identically through any of these interfaces. See Request model for why that’s true and how DID-based authentication replaces a shared API key.
| Interface | When to use it |
|---|---|
| REST API (HTTPS + JWT) | Synchronous management calls from applications and the operator CLI. Available on all VTA deployments. |
| DIDComm v2.1 | End-to-end-encrypted messaging for services that communicate through a DIDComm mediator. Requires a configured DIDComm v2.1 mediator, either Affinidi-hosted or self-hosted. On the Affinidi-hosted VTA, select the mediator when creating the VTA configuration in the portal. On self-hosted VTAs, set the mediator DID in the VTA config. |
Local VTA CLI (vta binary) | Offline operations on the on-disk store: initial setup, sealed-transfer bootstrap, ACL management, key inspection. Self-hosted VTA only. |
Trust Spanning Protocol (TSP) exists as an experimental, opt-in transport on self-hosted VTAs, gated behind a build feature and off by default. DIDComm v2.1 through a mediator remains the default, and the only mediator-based option Affinidi enables on any VTA appliance today.
The Personal Network Manager (PNM) CLI is the standard operator client. It wraps the full VTA service API surface into a single terminal-friendly tool. On the Affinidi-hosted VTA, PNM uses DIDComm when a mediator is configured, and falls back to REST when it is not.
Why trust an Affinidi-hosted VTA
Self-hosting puts you in full control, but it also makes the VTA only as trustworthy as the machine you run it on. Affinidi-hosted VTA removes that dependency. It runs inside a Trusted Execution Environment (TEE), specifically an AWS Nitro Enclave: a hardware-isolated environment with no persistent storage, no interactive access, and no network interface of its own.
This gives you confidentiality even from Affinidi as the operator, and lets you verify independently that the enclave runs the exact build you expect rather than trusting a description of it.
See Security model for the full explanation, including what PCR0 pinning protects against and what the anti-rollback guarantee does and does not cover.
Find your use case
| If you need to… | Start here |
|---|---|
| Sign data with a key your service never holds | Remote signing for backend services |
| Stop copying API keys and credentials into every service’s environment variables | Centralise secrets across microservices |
| Give a stateless AI agent memory across restarts, with no separate database | AI agent memory |
| Drive a VTA from Claude Code, Claude Desktop, or any Model Context Protocol (MCP) host | MCP integration |
See Use cases for the full list, each mapped to the guide that implements it.
Get started
Deploy on Affinidi Portal to get a hardware-isolated VTA with no host to prepare, or self-host if you need to run the infrastructure yourself:
Glad to hear it! Please tell us how we can improve more.
Sorry to hear that. Please tell us how we can improve.
Thank you for sharing your feedback so we can improve your experience.