Overview
A Verifiable Trust Agent (VTA) combines four capabilities you would otherwise assemble from separate tools: identity issuance, remote signing, 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. |
| Sign without exposing keys | Applications send unsigned payloads and receive signatures. The VTA signs on your behalf, and 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, apart from internal keys, 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 REST, DIDComm, and TSP, where the VTA enables those transports, with the same authorisation and audit path. Sealing a secret needs DIDComm. 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.
| Interface | When to use it |
|---|---|
| REST API (HTTPS + JWT) | Synchronous management calls from applications and the operator CLI. Available when the VTA is built and configured with REST enabled. |
| 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, and key inspection. Commands that change state stop working once the VTA is sealed. Self-hosted VTA only. |
Trust Spanning Protocol (TSP) is an additional transport on self-hosted VTAs, included in the VTA service’s default build. During setup, TSP is on by default, and setup checks that an existing 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.
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. 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. An Affinidi-hosted VTA reduces that dependency by running 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.
In normal operation, key material stays inside the enclave, out of reach of the host, unless an authorised caller explicitly exports it. See Trust boundary. You can also verify independently, from its attestation, which enclave image is running.
See Security model for the full explanation, including 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 |
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.