Overview
A Verifiable Trust Agent (VTA) combines five capabilities you would otherwise assemble from separate tools: identity issuance, remote signing, credential issuance, secrets delivery, and agent memory. Rather than adding a vault, a wallet, and a certificate authority side by side, a VTA brings these into one system. Deploy an Affinidi-hosted VTA →
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.
What you can do with a VTA
| Capability | What it means in practice |
|---|---|
| Own a verifiable digital identity | The VTA generates a Decentralised Identifier (DID) for you. Any third party that can resolve the DID can use it to verify your signatures independently. |
| Issue and hold verifiable credentials | The VTA signs W3C Verifiable Credentials with its own DID, and stores the credentials it receives after checking each issuer’s proof. See Issue, hold, and present verifiable credentials. |
| Sign without exposing keys | Applications send unsigned payloads and receive signatures. The VTA signs on your behalf, and in normal operation key material leaves it only when an authorised caller explicitly requests it, such as through sealed transfer, a key export, or a backup. |
| Retrieve secrets at runtime | Services authenticate to the VTA and retrieve credentials, API keys, or tokens at runtime. The VTA releases each value encrypted to the calling service, which opens it in memory, so the service can keep it out of configuration and environment variables. |
| Persist AI agent state | Store an AI agent’s working memory in the VTA’s agent memory store. 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 separate set of derived keys and access rules, all derived from the same master seed. |
| Audit privileged actions | Most privileged operations, such as ACL, key, vault, and backup changes, are written on a best-effort basis to a hash-chained, append-only audit log recording who acted, on which resource, over which transport, and the outcome. Query the log for operational review within its retention period. |
| Export and migrate your data | A super admin can export a password-encrypted backup of the VTA’s master seed, keys, identities, access configuration, vault, and credentials, and restore it to the same VTA or another one. See Back up and restore VTA state. |
How you interact with a VTA
Most operations are defined once as Trust Tasks and served over TSP, DIDComm, and REST, where the VTA enables those transports, with the same authorisation and audit path. Sealing a secret needs DIDComm, and exporting a key or a backup, or importing a backup, needs DIDComm or TSP. The local CLI covers a smaller set of offline administration tasks. See Request model for why that’s true and how DID-based authentication replaces a shared API key.
Prefer TSP or DIDComm where the VTA offers them, and treat REST as optional: a self-hosted VTA enables REST by default, and a super admin can turn it off. Affinidi-hosted VTAs offer DIDComm when you add a mediator. A VTA reached through its mediator connects out to that mediator rather than waiting for inbound calls, and callers address it by its DID rather than a network address. With REST turned off, the VTA binds no HTTP listener, so it exposes no endpoint to call remotely, and you can move it to another host or region without changing how callers reach it.
| Interface | When to use it |
|---|---|
| DIDComm v2.1 | The default on an Affinidi-hosted VTA with a mediator. End-to-end-encrypted messaging through a DIDComm v2.1 mediator, either Affinidi-hosted or self-hosted. On an Affinidi-hosted VTA, select the mediator when you create the VTA configuration in Affinidi Portal. On a self-hosted VTA, set the mediator DID in the VTA’s configuration. |
| Trust Spanning Protocol (TSP) | The preferred transport on a self-hosted VTA, carried over the same mediator connection. It is included in the VTA service’s default build and on by default during setup, which checks that the mediator advertises TSP: interactive setup turns TSP off if it finds no TSP service, and vta setup --from stops with an error instead. Affinidi-hosted VTAs and Affinidi-hosted mediators use DIDComm v2.1. |
Local VTA CLI (vta binary) | Offline operations on the on-disk store: initial setup, sealed-transfer bootstrap, ACL management, and key inspection. Commands that change state stop working once the VTA is sealed. Self-hosted VTA only. |
| REST API (HTTPS + JWT) | Optional. Synchronous calls for a caller that cannot use a mediator. On an Affinidi-hosted VTA, it serves the VTA URL. The first bootstrap of a VTA in Isolated mode also goes to that URL. On a self-hosted VTA, it is on by default: a super admin turns it off with pnm services rest disable, which removes it from the VTA’s DID document and stops the HTTP listener from the next restart, and turns it back on with pnm services rest enable --url <url>. The VTA refuses to turn it off when that would leave it with no transport. |
The Personal Network Manager (PNM) CLI is the standard operator client. It wraps the VTA service’s management operations into a single terminal-friendly tool. PNM prefers TSP, then DIDComm, then REST, depending on what the VTA advertises, and --transport forces one. When you create an Affinidi-hosted VTA, add a mediator so PNM and your services connect over DIDComm. Without one, PNM uses REST.
Isolated and Shared modes
Self-hosting puts you in full control, but it also makes the VTA only as trustworthy as the machine you run it on. An Affinidi-hosted VTA runs in one of two modes, which you choose when you create the configuration:
- Isolated: runs in an AWS Nitro Enclave, a Trusted Execution Environment (TEE). Hardware-rooted attestation, keys and data.
- Shared: runs on a shared network. Evaluation and development purposes only.
In Isolated mode, the AWS Nitro Enclave is a hardware-isolated environment with no persistent storage, no interactive access, and no network interface of its own. In normal operation, key material stays inside the enclave, out of reach of the host, unless an authorised caller explicitly exports it. You can also verify independently, from its attestation, which enclave image is running.
Shared mode is available on every plan, including the free Essential and Community plans. Isolated mode needs the Standard or Enterprise plan, which are custom plans shown in Affinidi Portal as coming soon.
See Isolated and Shared modes for which mode suits which workload and which sizes each plan includes, and Security model for what PCR0 pinning protects against and when the anti-rollback anchor applies.
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 |
| Issue verifiable credentials from your VTA’s DID, and keep the credentials it receives | Issue, hold, and present verifiable credentials |
See Use cases for the full list, each mapped to the guide that implements it.
Get started
Deploy on Affinidi Portal, in Isolated or Shared mode, with no host to prepare, or self-host if you need to run the infrastructure yourself:
Glad to hear it. Thanks for letting us know.
Sorry to hear that. Thanks for letting us know.