What a digital ID for AI agents is
A digital ID for AI agents is a signed credential that attests who operates the agent, what it can do and what it is forbidden to do. Here is how it works.
A digital ID for AI agents is a cryptographically signed credential that attests who operates an agent, what it is authorised to do and what it is forbidden to do, and that anyone can check for themselves on a public page. Its technical name is Verifiable Agentic Identity (VAI); at NEXTAI we call its visual representation the CORTEX Seal. The difference from a legal notice is simple: the notice is declared, the credential is verified.
Why an agent needs an identity of its own
An AI agent is not a document someone reads: it is a system that acts. It searches, drafts, queries databases, prepares actions and, depending on how it is configured, executes them. When a system acts on behalf of a company, the question stops being "which model does it use?" and becomes "who answers for this and how far does its hand reach?".
Today, the usual answer to those questions is a logo. Anyone can copy a logo. And the problem gets worse because an agent is not a stable product but a configuration: a prompt, a set of connected tools, some permissions and some limits. Change one line and you have a different agent with the same name. If that sounds confusing, it is worth reviewing the differences between a chatbot, a copilot, an agent and a superagent first.
The digital ID for AI agents exists to close that gap: it turns an agent's identity into something a third party can check, by testing the signed declaration and weighing their trust in its issuer.
What it contains exactly
An agent credential, in our implementation, includes six pieces:
- DID identifier: the agent's reference under the issuer's domain.
- Signature: protects the origin and integrity of the declared content.
- Issuer: Cosmolabs OÜ, registry code 17106582, operator of NEXTAI and CORTEX.
- Scope: authorised actions and prohibitions signed at issuance.
- Manifest hash: a reference to the registered version, which does not on its own prove what configuration is running in other systems.
- Status and validity: expiry and revocation you can query, subject to consumers' refresh behaviour and caches.
The credential contains no personal data about individuals. The responsible party is the company, with an accountable role and a legal contact address, not a named employee.
How it differs from a login, an API key or a legal notice
This is the comparison that helps most to place the concept, because each of those mechanisms solves a different problem and none of them solves this one.
| Mechanism | What it contributes | Limit |
|---|---|---|
| Login or API key | Authenticated access according to the service | Needs permission management and a lifecycle |
| AI notice | Direct information to the person you are talking to | Does not cryptographically verify the scope |
| HTTPS | A protected channel with the server | Does not on its own identify the sending agent |
| Agent credential | Signed declaration of identity and scope | Does not prove execution or possession of the identity |
| Connector controls | Enforcement of permissions on each action | Have to be integrated, tested and maintained |
The last column is what makes the real difference. A login stays valid even if you give the agent access to the customer database this afternoon. A credential bound to the manifest hash does not.
A useful credential lets you check a declaration and know when it stops being acceptable. Its value grows when it is connected to execution controls that can also be tested.
Why identity has to be bound to the configuration
This is the point that is hardest to explain and the one that adds the most value. In classic information security, identity describes a stable subject: a person, a server, a company. In agentic AI, the subject changes every time someone edits a prompt or connects a new tool.
Binding the credential to the SHA-256 hash of the manifest means a silent widening of powers is no longer possible. If we widen an agent's scope tomorrow, the public check fails and a new credential has to be issued, with a new date and a new scope. The history is there for anyone to see.
That same reasoning is what underpins an agent registry in AI governance: you cannot govern what you do not know exists, and you cannot trust an inventory that does not reflect each agent's real configuration.
Autonomy levels: the field that tells you the most
Inside the credential, the field that best sums up the risk is the autonomy level. Our scale is this one:
| Level | Name | What it allows |
|---|---|---|
| A0 | Observe | Read, search, measure |
| A1 | Analyse | Classify, summarise, estimate |
| A2 | Prepare | Drafts, proposals, plans |
| A3 | Execute internally | Reversible internal changes |
| A4 | Execute with approval | Persistent or external action only with valid human approval |
| A5 | — | Not a reachable level: it is the class of actions forbidden to any agent |
A5 deserves a note, because it breaks the ladder logic. It is not the level above A4: it is the boundary. Moving money autonomously, deleting audit trails or escalating privileges are actions no agent can perform, whatever its level.
What it attests and what it does not
This is worth stating plainly. An agent credential is a verifiable self-declaration, not an external assessment: it is asserted by the company that operates the agent, and what it adds is that anyone can check the signature, the validity and the scope without asking permission.
A signed identity does not guarantee quality or security. It declares the operator and the scope; the limits have to be enforced in the connectors. Article 50 of the AI Act sets out transparency obligations according to role and use, but it does not require this cryptographic ID. A timely notice that the user is interacting with AI and the credential itself are complementary measures.
The full cryptographic mechanics are explained in W3C verifiable credentials for agents, and the legal reading in Article 50 of the AI Act for SMEs.
How it is checked
With no sign-up and nothing to install. The public verifier for the agent Argos runs eight live checks: credential format, the key declared by the issuer in its DID document, signature, issuer consistency, validity, revocation, unchanged manifest and published DID document. If any one fails, the practical rule is not to trust it.
The detail of each check and the formats are in the technical documentation on agentic identity. The specific case, step by step, is in the Argos case study.
Frequently asked questions
Is a digital ID for AI agents the same as an electronic signature?
It is not an official identity document and it is not a regulated electronic signature under eIDAS. It is a software credential signed by its issuer. Comparing it to an "ID card" makes the explanation easier, but it does not give it legal equivalence.
What if someone copies the visual seal?
The image, the credential and its signature can all be copied, because they are public. The signature makes it possible to detect alterations to the signed content. Copying a valid QR does not prove that whoever presents it controls the agent's identity; that requires evidence bound to the interaction.
Does it work for agents that are not ours?
Yes. It is built on open W3C standards and the specification will be published under an open licence. Any company can issue credentials for its own agents with the same approach, without going through us.
Why does it expire after 90 days?
Because an identity that never expires ends up describing an agent that no longer exists. Ninety days force a review and a fresh signature on what the agent can do today, not what it could do two years ago.
What to do with this
- Inventory the agents operating on your behalf. Include the ones third parties use to talk to you or to your customers.
- For each one, write down what it is forbidden to do. The list of prohibitions tells you more than the list of capabilities.
- Check whether that list can be verified by someone outside. If it only exists in an internal document, that is not transparency: it is intent.
- Set an autonomy level per agent using an explicit scale, and review who approves external actions.
- Establish how it is cancelled. If you do not know how to revoke an agent in minutes, you do not have control, you have luck.
If you want to see how this applies to your processes and to the agents you already have running, start here: book your Digital Audit.
Editorial update of 17 September 2026, produced with the support of AI tools and cross-checked against public documentation. It is not presented as an external audit.
Identity and execution: the scope of this explainer
The public checks describe the credential and its relationship with the registered manifest. They do not prove the authentication of whoever presents it, the state of each external permission, or that actions are actually blocked. See the published evidence and limits.