W3C verifiable credentials for AI agents, explained
VC 2.0, DIDs, status lists, KMS and the manifest hash: how the identity of an AI agent works under the bonnet, with plain analogies and clear limits.
A verifiable credential for an AI agent is a signed statement about its identity and scope. A verifier can check the signature, the validity and the status using the corresponding keys and resources. The credential does not automatically observe what configuration each tool is running, and it does not remove every dependency on the issuer.
This article takes apart the technical side of the digital ID for AI agents without asking you to know any cryptography. For the business version, start with what a digital ID for AI agents is.
The five pieces and what each one is for
1. The identifier: DID
A DID is a digital identifier that does not depend on a central registration authority. We use the did:web method, which anchors the identifier to a domain: the issuer is did:web:digitalcortex.tech and each agent has its own, in the form did:web:digitalcortex.tech:agents:<slug>.
The analogy is a registered company address. You do not make it up on the spot, it hangs off a site someone controls, and a third party can go and check it. Here, the issuer's DID document is published at a standard path and declares which public key is used to sign.
2. The credential: W3C Verifiable Credentials 2.0
The content — who the issuer is, who the subject is, what is asserted, from when and until when — is expressed in the W3C Verifiable Credentials 2.0 data model. We serialise it in vc+jwt format, that is, packaged as a signed token.
The format being a standard matters for one practical reason: a verifier that knows nothing about us can still read it. If the format were proprietary, verification would depend on a tool of ours, and we would be back where we started: trusting the issuer.
3. The signature: ES256 with the key in a KMS
The credential is signed with ES256, which is ECDSA over the P-256 curve. The key identifier (kid) carried in the credential is the JWK thumbprint of the public key, so the verifier knows exactly which one to check against.
The relevant part is not the algorithm but where the private key lives: in Google Cloud KMS, never on the web server. The analogy is a safe. Someone breaking into the website does not gain the ability to sign new credentials, because the key is not in the drawer behind the counter.
4. The configuration fingerprint: the manifest hash
Each agent has a registered manifest with a version and a SHA-256 hash. The scope and the prohibitions are signed at issuance. You should not assume that every prompt, tool and effective permission is part of that manifest.
The useful analogy is a reference to a documented version. Comparing hashes lets you detect a difference in the manifest being checked. It does not on its own detect changes in loaded prompts, models or permissions on external services.
5. Revocation: Bitstring Status List v1.0
The credential expires after 90 days and is renewed. It can also be cancelled earlier through a signed status list, following the W3C Bitstring Status List v1.0 standard.
Expiry and revocation limit acceptance of the credential. The status you see depends on data freshness and caches. Withdrawing permissions and stopping sessions require additional measures, as the revocation guide explains.
How it all fits: the eight checks
The public verifier runs eight live checks, with no sign-up. This table matches each one to the piece that makes it possible.
| Check | What it lets you test |
|---|---|
| Format | The credential's supported structure |
| Issuer key | The public reference for the key |
| Signature | Cryptographic integrity and origin |
| Issuer consistency | Whether the identifiers match |
| Validity | Acceptance dates |
| Revocation | The status as of its last refresh |
| Manifest | Match with the registered hash |
| DID document | Publication and linkage of the document |
These checks do not replace authenticating whoever presents the credential, or enforcing permissions in the tools.
The practical rule for whoever is checking is simple: if any of the eight fails, do not trust it. And it is worth remembering that check number 7 is what separates this approach from a classic one-off attestation. Without it, the credential would describe an agent that could have changed yesterday afternoon.
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.
The visual seal and why it is not the proof
From the manifest hash and the DID, a unique image is deterministically generated for each agent and each version: the CORTEX Seal. The outer ring has 256 marks representing the bits of the hash; the light diamonds are the permitted actions; the red diamonds, the forbidden ones; a bar indicates the autonomy level; and a QR code opens the public verification.
The seal links to a check. The image, the credential and the signature can all be copied: the signature lets you detect alterations to the content, not authenticate whoever shares the QR. Its visual state depends on the service's refresh behaviour and caches.
What a verifiable credential does NOT guarantee
This is the most important section and the one almost always missing from the sector's material.
- Quality: a signature does not guarantee correct answers.
- Independence: this is a verifiable self-declaration, not a third-party audit.
- Security: declaring a prohibition does not block a tool.
- Cut-off: revoking and stopping are different operations that have to be rehearsed.
- Configuration: the hash of the registered manifest does not on its own observe external changes.
- Privacy: the reference credential identifies the agent and the company; you have to review which fields are published at each issuance.
Open standards, not lock-in
Everything above rests on public W3C specifications: Verifiable Credentials 2.0, DID with the did:web method, and Bitstring Status List v1.0. The specification of our profile will be published under an open licence, and the documentation of fields and endpoints is already available in the technical documentation on agentic identity alongside the public policy.
Any company can issue credentials for its own agents with this approach without going through us. As far as we have been able to check, we are not aware of another AI consultancy for SMEs in our market that publishes verifiable credentials for its agents; if one exists, we will be glad to cite it. A less technical reading of the same subject is in why every AI agent should carry an ID, and how it fits an internal inventory is in the agent registry.
Frequently asked questions
What is a W3C verifiable credential?
It is a standard data model for digitally signed statements that a third party can validate on their own. It defines who issues, who the subject is, what is asserted and for how long, in a format any compatible verifier can read.
Why did:web and not another DID method?
Because it anchors identity to a domain that is already checkable and requires no extra infrastructure. The DID document is published on the issuer's domain and declares the public signing key, so the chain of trust is short and auditable.
Why is the private key kept in a KMS?
To separate the ability to sign from the server that serves the website. If the server is compromised, the attacker does not obtain the key, because signing operations happen inside the key management module and the private key never leaves it.
What happens if the issuer disappears?
The DID document would stop being published and check number 8 would fail. That is deliberate: an identity whose issuer no longer answers should not carry on validating as if nothing had happened.
Can it be verified without an internet connection?
The signature and the format, yes, if you have the public key. Validity, revocation and the DID document require online sources, because they describe a state that changes over time.
What to do with this
- Ask for the format, not the promise. If a provider says its agents are verifiable, ask which standard it uses and where the key is published.
- Check the integrity check. Having a signature is the minimum; testing the effective configuration against the signed declaration is what adds value.
- Ask where the private key lives. On the web server is a bad sign.
- Require explicit revocation and expiry, with a specific period.
- Validate it yourself once. Open the public verifier, run the checks and see what information you get without asking anyone's permission.
Want to apply this to the agents already running in your company? Talk to us.
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.