AI agents already act for the people who use them. They book meetings, compare offers, fill in forms and call APIs. Soon they will open accounts and place orders too. For the service on the other end, every one of those requests raises the same problem: it cannot tell an agent acting for a real customer from one acting for nobody.
Today the usual answer is an API key or a shared login. That proves the request came from an account. It does not prove who stands behind the agent, whether that person agreed to this action, or whether the agent is still allowed to act at all.
A service that accepts agents needs answers to three questions. The tools to answer them already exist, because they are the same tools Europe is building for people.
Who is this agent?
A person proves who they are with a credential from a trusted issuer. An agent can do the same. It gets a decentralized identifier (a DID): a unique name tied to a cryptographic key that only the agent holds. The agent signs each request, and the service checks the signature against the key published for that DID.
No central registry has to vouch for the agent, and nobody can pose as it without stealing its key. Impersonation stops being a question of trusting a platform and becomes a question of checking a signature.
Who sent it?
Knowing the agent is not enough. The service also needs to know which person or organization it acts for, and what they agreed to.
That is a delegation, and a delegation fits naturally into a credential. The person, or their employer, issues the agent a credential signed with their own wallet key. It states what the agent may do and until when: book travel up to a set amount, for example, until the end of the month. The agent presents the credential with its request, and the service checks the signatures back to the person who granted it.
This works across organizations. The service does not need an account with the agent’s provider, and it does not need to call the issuer. It is the same check a verifier makes on a visitor pass or an age proof: an issuer signs, a holder keeps the credential, and the verifier checks it when it needs to.
What may it do right now?
The last question is about the request itself. The service compares the credential’s terms with the action in front of it: the amount, the type of action, the expiry date. If the request falls outside them, it is refused, whatever the agent says.
Selective disclosure keeps this private. A credential can show that an action is within the limits without handing over the whole policy behind it. A company does not want every supplier to see its agents’ budget rules, and it should not have to show them.
Why this matters now
Agents will reach regulated services before most of those services are ready for them. A bank, an insurer or a public service cannot accept a request it cannot trace to a responsible person. The EU AI Act also asks for transparency when people deal with AI systems (Article 50). Being able to prove who stands behind an agent is the machine-readable side of the same question.
The infrastructure is arriving on its own schedule. Every EU member state must offer a digital identity wallet by December 2026, built on open standards such as SD-JWT VC and OpenID4VP. A person who already holds a wallet can use it to sign a delegation. The agent does not need a new identity system. It needs a credential from the identity system its owner already has.
Where Partisia fits
We build the issuing and verification side of that picture. The Credential APIs issue and verify credentials of your own design on the same standards as the EUDI wallets, and a delegation is one more credential of that kind. Our products, VisitorPass, SitePass and AgeVerify, run the same check for people today: an issuer signs, the holder keeps the credential, and the service checks only what it needs.
The technology behind it is described on our decentralized identity page, and the developer documentation shows how a credential is issued.
Is your service about to meet its first agents?
