This is a concept-level post. Implementation details will be published after the patent filing.
An API key is not an identity
When an agent calls an external service, what it usually carries is an API key. The key says "this call is permitted". It does not say "who is accountable for this transaction".
Those are different questions. The first is authorization, the second is identity. In systems used directly by people the distinction rarely shows, because the person who logged in was the accountable party. Put an agent in between and the two come apart.
Where it becomes a problem
Keys get copied. They get delegated, left in environment variables, handed to other agents. The transaction record only says "key A made the call". After a few levels of delegation, even the trail back to whoever the key was first issued to is broken.
What anti-money-laundering regimes require is identification of the real party to a transaction. To satisfy that in an environment where agents initiate transactions, you have to be able to know the person or legal entity behind the agent. A key cannot do that.
The EU AI Act (Regulation (EU) 2024/1689) points the same way. For high-risk AI systems it requires that the operator be identifiable and that behaviour be logged. Who operates this is the regulator's question.
Approach: do not build a new trust framework
One option is a separate identity framework just for agents. We did not take that direction. A new trust framework has to solve "who trusts this framework" all over again from the start.
Instead, we extend the identity framework that already works for people and legal entities to agents. There is an operator identity verified under eIDAS 2.0, there is an agent identifier, and the two are bound together. When the agent initiates a transaction, the counterparty receives the agent identifier along with the fact that "this agent's operator is verified party X".
Nothing changes for the verifier. It verifies the same way it verified a person's credential. The subject just happens to be an agent.
Open questions
This direction does not solve everything. Some questions honestly remain.
- How to express the scope of delegation. Whether the operator granted the agent "read only" or "up to and including transfers" is a different layer from identity.
- How to keep the chain when an agent calls another agent. The problem of accountability not diluting across multi-level delegation.
- The lifetime of an agent identifier. When the model is replaced or the instance is recreated, keep the same identifier or issue a new one.
These are the parts we are designing now, and we will be able to write about them more concretely after filing.
What to confirm now
If your organization is about to adopt agents, there is a question to answer before any technology choice. When a transaction made by an agent goes wrong, can we identify the accountable party from our own records alone? If the answer today is "we would have to look up the key issuance ledger", then that ledger is standing in for an identity framework.