# Roles and access

> Why a VTA has five distinct roles instead of one shared credential, what each one can and cannot do, and how role and context together bound what a DID can reach.

A VTA holds signing keys and secrets for every application you register with it. If every DID that authenticates to it had the same level of access, a single leaked credential, from any one of those applications, would be enough to reach every key and every secret the VTA holds. Roles exist so that is not true. Every DID in the VTA’s access control list (ACL) is assigned exactly one role. That role sets a hard ceiling on what the DID can do, independent of every other DID’s role.

## Least privilege by design

What an attacker can do with a leaked credential should match what that credential actually needs to do, not what the VTA is capable of doing:

- A backend service that only signs payloads has no legitimate reason to also mint new keys or rewrite the ACL.

- A monitoring dashboard has no legitimate reason to read key material at all.

The VTA enforces this by classifying every operation into one of five capability levels and assigning each DID the role that matches its job, rather than defaulting everything to admin-equivalent access.

## Roles

Every DID in the VTA access control list is assigned one of five roles, from most to least privileged. This role model is based on the Trust Over IP Foundation’s [Verifiable Trust Infrastructure (VTI) specification’s role registry](https://trustoverip.github.io/dtgwg-vti-spec/#c.1-roles).

| Role | What it can do |
| Admin | Full access to keys, contexts, ACL, config, and backup. An Admin with an empty allowed_contexts list has unrestricted access across the entire VTA. The CLI displays this case as “super admin.” |
| Initiator | Sign data, read and write the vault, and grant or revoke non-admin ACL entries, within their allowed contexts. Cannot mint keys, promote anyone to Admin, or touch an existing Admin entry. |
| Application | Sign data, read keys and contexts, read and release vault secrets, and perform proxy-login within their allowed contexts. Cannot write to the vault, mint keys, or manage ACL entries. |
| Reader | Read-only access to list keys, contexts, and DIDs, and to read the vault, within their allowed contexts. |
| Monitor | Infrastructure-only: metrics and health endpoints. No access to keys, contexts, DIDs, or the vault at all. |

Vault access is finer-grained than the table suggests: reading, writing, and releasing a secret are separate capabilities, and an entry can hold fewer than its role allows. See [Secrets vault](/products/affinidi-elements/vta/concepts/vault.md).

This is why [Sign application payloads without exposing your keys](/products/affinidi-elements/vta/integration-guides/provisioning-app-signing.md) provisions its credential with --role application rather than --role admin. A credential at that role can call the signing endpoint, but not mint keys, change the ACL, or issue credentials to new identities. Those bounds hold even if the credential leaks, so an attacker gains the ability to sign in that context rather than control of the VTA.

## Role and context together

Role sets what a DID can do. Context scoping sets where. A DID’s ACL entry carries an allowed_contexts list alongside its role, and every check applies both: an Initiator scoped to one context can grant or revoke non-admin ACL entries in that context, and nowhere else. See [Contexts](/products/affinidi-elements/vta/concepts/keys-and-contexts.md#contexts) for how context isolation works across a VTA.
Note

An empty allowed_contexts list means different things depending on role:

- Admin: every context. This is the unrestricted “super admin” case.

- Every other role: no context at all. The entry is provisioned but inert.

This asymmetry is deliberate. Only Admin is trusted with an unscoped grant.

This mirrors the [VTI specification’s distinction between super-administrators and context administrators](https://trustoverip.github.io/dtgwg-vti-spec/#act-scope%3A-super-administrators-and-context-administrators): an unrestricted entry acts everywhere, and a scoped entry acts only within the contexts it names.

The restriction lives on the admin entry, not on the VTA itself. The same three contexts exist for everyone; what differs is which of them a given admin entry can see:

## Related

  [Grant and revoke access](/products/affinidi-elements/vta/vta-management/acl-management.md)

  [Sign application payloads without exposing your keys](/products/affinidi-elements/vta/integration-guides/provisioning-app-signing.md)