Then the process stops. Someone writes an email, someone calls back, and an exception that both sides could have settled in minutes takes days instead.
This is our design for the layer that keeps those cases moving. Each agent works from a mandate set by its own company, and that mandate says what the agent may settle by itself. Within those limits it decides and commits without checking back with anyone. The rare case that falls outside the mandate goes to a person authorised to decide it.
We have built and measured the core of it. Two agents identify each other and negotiate inside a mandate. The agent acting for a person stops short of the binding step, because it was never issued the credential for that step. That prototype runs between a person and a company. What follows describes the same design between two companies, and says where the two differ.
No shared platform, no consortium. Two companies with an agreement are enough.
There is no setting for "prepare, but do not commit"
A token or a login hands the agent everything the person behind it may do, and afterwards nobody can tell which of the two acted. Ask the model to stay under a limit and it will stay under it most of the time, which is fine for a draft but not for an order you have to honour.
So the mandate answers this in advance. It is not an instruction the model could talk itself out of. What the agent may agree to is written into a credential it carries, and it never receives a key for anything beyond that. At the limit the agent does not refuse. It has nothing to present.
A rule can be argued with. A signing key the agent was never given cannot.
It belongs to a company you have an agreement with, and it can show how far that company authorised it to go. You check both cryptographically, where today you would phone someone to confirm it.
Commit the company. The confirmation carries the figures it approves: quantity, price, delivery date. What goes on record is this order, not a session.
Call-offs against a framework agreement
Prices, volume tiers and delivery windows are already agreed. What happens per order repeats itself, and whatever does not repeat is exactly the part that needs a decision. Here is one call-off as the two agents run it.
Purchasing agent
“3,000 units of article 4711, delivery week 12.”
Supplier agent
Asks for identification. Both agents present a mandate, and both mandates are checked.
Supplier agent
“Available. 2,400 units in week 12, the remainder in week 14. Alternatively all 3,000 in week 13.”
Purchasing agent
“All 3,000 in week 13.” It decides that on its own, because quantity, price and date stay inside the agreed corridor.
Supplier agent
Order confirmation, without a person involved.
Where a person comes in
A surcharge for the split delivery, a date outside the corridor, a quantity above the tier: each of those crosses the threshold, and an authorised signatory confirms. The confirmation is bound to those figures and happens on the signatory's own device.
Nights and weekends included. A scheduling change can come in at three in the morning, and today nobody acts on it until someone reads the mail. The agent needs a valid mandate and a reachable counterparty, and both hold at three in the morning.
What costs an approval loop per order today is settled once, in the agreement. The speed comes from exercising control in advance rather than from having less of it.
Who acted, under whose authority, and who approved what. Every entry carries a signature that names a key, where today you would find a log line attributed to “system”.
The same pattern fits claims handling between an insurer and a repair shop, freight scheduling between a shipper and a carrier, and service call-outs against a maintenance contract. The four conditions are the same every time: the work repeats, the terms are negotiable, there is a threshold, and the partners know each other.
What holds it together
Check one
Is the signature valid?
Answered by cryptography. Says the message belongs to some key.
Not enough
Check two
Is it the key we agreed on?
Answered by the framework agreement, where the keys were exchanged.
Two checks, and the second is the one that counts
Anyone can sign their own message, so a valid signature on its own proves very little. It counts only once the key is the one the other company handed over when the agreement was set up. Skip the second check and the first is decoration.
Shown to the other side
Which company it acts for
Which kind of business
How long the mandate lasts
Same document
Stays at home
What it is willing to pay
Your own ceiling is an instruction to your agent, not a claim the other side needs to check.
What a mandate carries
Both companies agree on the threshold once and write it into the framework agreement, so the mandate can prove what the agent may settle. What a company is privately willing to pay stays with its own agent, because the supplier does not need it to check the mandate.
The agent
Reaches for a signature
nothing to present
Case stays open
The other side
Asks for a person
Past the threshold, the supplier asks for a credential only a signatory holds.
The agent has no key to give
It was never issued one, so there is nothing for it to hand over, however good the argument on the other side. Nothing has failed here. The case stays open and the agent forwards the request to a signatory, which is what separates a handover from the manual fallback you have today.
The signatory sees
Approval required
3,000 units · Art. 4711
€21,000 · delivery week 13
The signature covers these figures alone, which makes it useless for any other order.
Signed
The other side checks
Is this the right person?
The mandate named a key when the agent first identified itself. The approval has to match it.
Approval of a case, not a session
The signatory gets a notification wherever they are and never has to sit in front of a dashboard. Without the last check, a valid approval and a valid mandate would sit side by side, each true on its own, and anyone holding a company credential could release someone else's business.
A prototype, and what it settles
Everything above is a design. We have built and run its core: two agents from separate codebases, sharing nothing but the protocol, taking a contract change to the point of signature. The setting is a person and a company rather than two companies. That difference matters, and the next section covers it. What the prototype settles holds either way.
At the closing step the counterparty asks for a credential the agent was never issued, and its wallet returns nothing. The alternatives (an agent that judges when to escalate, or a threshold configured by the counterparty) both hang on something that can be set wrong or talked around. This hangs on who holds which key.
The mandate names the key of the person who granted it, and at closing the verifier checks that the approval came from that key. We tested the failure case: when a different key approves, the transaction is refused.
Cross-device approval flows can be attacked by getting a victim to approve a request from the attacker's session. Two mechanisms built for other purposes block this between them: the attacker's key does not match the mandate, and a person scanning the wrong request sees figures that do not match what they expect. We did not design for this attack; the protection is a side effect of the two mechanisms.
The mandate carries a credential type distinct from an identity credential, so a verifier can tell a represented transaction from a direct one without asking. It can also decline representation. This follows from the credential format itself, and does not depend on either side exercising care.
What changes
In the prototype the person the agent acts for is the person who approves the transaction, and tying the two together is one key against one key. Between two companies the chain has an extra link: the company authorises a signatory, and the signatory authorises the agent. An approval then has to show three things: that the same person signed, that this person could commit the company, and that their authority covers the figures in front of them.
The same chain has to hold one step earlier, when the mandate is issued rather than used. Somebody inside the company authorises it, and nobody can hand an agent more authority than they hold themselves. Our prototype does not close this step, even in the simple case. The person identifies themselves before the mandate is issued, which establishes that they were present. It does not establish that they agreed to this scope for this agent.
The European framework models a person representing another person. Wallets for legal persons sit on a separate track, and nothing describes a company delegating to software. The schema at that layer is therefore ours, and two independently built verifiers have no guarantee that they read the same mandate the same way.
This is also why we stay bilateral. The hard question in any identity scheme is who everyone trusts. A registry needs an operator the participants accept, and a ledger moves the question into governance rather than answering it. Between two companies with a framework agreement, the contract answers it, and the keys were exchanged when the integration was set up. That is where this works today, using only what the two parties already have.
Nobody sits in the middle
In this design each company runs its own identity infrastructure: it issues the mandate for its own agent and verifies what arrives from outside. Both stacks stand alone, with no third party between them and no vendor in your trust chain, ourselves included. What the two sides share is an agreement: the schema, the public keys, and where the threshold sits.
Company A operates
Company B operates
The people
Authorised signatories keep their credential in a wallet on their own device, where the private key never leaves the secure element. That wallet answers to its holder alone, which is why an agent cannot sign in their place.
Each side runs the same three roles for itself. A verifier never calls the other side's issuer.
The verifier checks a credential without contacting whoever issued it, because the signature carries the statement. That removes the need for a shared service, so two companies can start on their own instead of waiting for an industry consortium.
Verifiable credentials as SD-JWT VC, issued and presented over OpenID4VCI and OpenID4VP. Agent communication over the Agent2Agent protocol, governed by the Linux Foundation. Every format in the path is published, up to the point where delegation of authority to software begins. Beyond that boundary nothing is published, and the schema is ours.
The same ones the EU Digital Identity Wallet builds on. Where the European framework already models representation, we follow its structure instead of inventing our own. The framework does not extend to delegation from a company to software, and no published schema covers it. At that layer we use our own schema, and keep it replaceable.
Self-hosted, on premise or in your own cloud. The language models can run locally too. For negotiation data such as prices, volumes and supplier relations, that is often what makes approval possible at all.
Automate without having to trust the agent
Calling an agent trustworthy is an assumption about how it will behave. The properties below hold whether it behaves or not.
The code knows the limits; the model does not. Compliance is computed outside the model twice: before every reply, and again on the final result, because the other side can close a transaction without asking. Anything the model can read, the other side can extract with a well-phrased question.
The wallet ties quantity, price and date to the signature and shows them before anyone confirms. A stolen session has none of that to show.
There are two ways, and the European framework treats them as equivalent: keep the mandate short-lived, or run a revocation service. Where a revocation service is used, we fail closed. An unreachable status service means the mandate counts as withdrawn. The price is that a network fault stops the automation. Which of the two fits belongs in the agreement.
What the agreement fixes is visible to both sides. What protects your position (negotiating room, target prices, alternatives) stays inside your systems, out of every credential and out of the model's context. Behaviour still leaks it, and we return to that below.
Cryptography does not settle everything here. The limits below are the ones we know about.
A properly identified agent can still promise something its organisation is not bound by. That is why the framework agreement has to state what an agent's commitment is worth, and it is a question for lawyers rather than for cryptography.
You can prove which key signed and what it signed for. You cannot prove that a person stood at the device, and online banking lives with the same limit.
An agent that escalates at one price and not at another lets the counterparty narrow down where the line sits over a few offers. No signature scheme prevents this, because it is inference rather than disclosure. The countermeasures are matters of negotiation practice: ask broadly, do not react to the first offer. They are weaker than we would like.
The agent's keys sit in a container. There is no attestation of the execution environment, and no certification scheme covers software as a holder. The agent side stays structurally different from a certified wallet, closer to an authorised service holding credentials. This is a property of the design, and the transaction rules above account for it.
An agent does not have to be an AI agent
Mandate, key binding and the separation of roles all rest on signatures and schemas, so the identity layer works the same way whether or not a language model sits behind the agent. The same design secures a rule-based agent handling call-offs.
Checking a call-off against the agreed corridor
Rules are enough
Weighing a counter-offer: split delivery earlier against complete later
A model earns its place
Understanding free text where no fixed structure was agreed
A model earns its place
Putting a recommendation in front of a person, with reasons
A model earns its place
Holding a limit
Enforced in code
The identity layer sits at the protocol boundary where the two organisations meet, which leaves it indifferent to the agent framework behind it. Enforcement has to stay outside the model, because a check that the model can skip is only a suggestion. Integrating it means giving your agent something it can prove, and the domain logic stays as it is.
For read access to a single known counterparty that is the right answer, and it is cheaper. With agents, three differences matter. A token makes no statement of its own. It points at a record held by whoever issued it, so a third party has no way to check what it means. Second, a bearer token works for anyone who has it, and a credential bound to a key does not work for anyone who lacks the key. That is the difference for software that runs unattended and keeps its secrets somewhere on disk. Third, a token says nothing about a specific transaction. You can build that part next to it, and then you are back to who signs.
No. A distributed ledger answers the question of who maintains the list of trustworthy parties when nobody trusts a central one. Between two companies with a framework agreement that question is already answered. The contract does that job, and the keys were exchanged when the integration was set up. A ledger would add operational and governance overhead and settle nothing that is still open. The calculation changes one step further out, when two partners turn into a network of thirty and revocation has to reach all of them. Even then a signed trust list is usually the better fit. We choose the technology once we know the problem.
Each side runs an issuer, a verifier and a wallet for its own agent. The services are small and you host them yourself, inside your own estate. Each company operates its own set, so nobody has to settle who holds admin rights. If you would rather not host them, that is a hosting decision like any other and it still stays per company. It never becomes a shared service, and least of all one of ours.
Two ways, and they are not ranked. A short validity period needs nothing operated at all: the mandate expires by the clock, and the window until then is exposure you accept. A revocation service acts sooner and has to be run: your side notifies the counterparties you have agreements with, with a signed status list underneath. We fail closed there, because a check that passes when it cannot reach the service is not a check. The cost is that a network fault stops the automation. Our prototype uses short lifetimes; the revocation path exists in the stack, and we have not operated it.
No. The transaction stays open and the agent does not block. The authorised signatory gets a notification on their device with quantity, price and date. One tap opens the wallet, they confirm with biometrics, and the answer goes straight to the counterparty's verifier. This is the same pattern as a banking push-TAN, and nobody watches a dashboard for those either. A request can also go to a role rather than one named person, so a deputy signs while someone is away.
Only what the agreement fixes, and that is text you negotiated together. A shared threshold is an advantage there. The other side can tell in advance whether a step needs a signature, rather than finding out when your agent backs off. Everything that protects you from your own agent stays local, and we keep it out of the credential deliberately. Behaviour still leaks information. An agent that escalates at one price and not at another narrows down where the line sits after a few offers. Nothing in the signature scheme prevents that, because it is a question of negotiation strategy.
Yes. The identity layer is separate from the agent: it sits at the protocol boundary where the two organisations meet, not inside your agent's reasoning. It must not become something the model can skip, because a check the agent may or may not call is a rule again, and the argument here rests on it being an impossibility. Connecting an existing agent is integration work, and the domain logic stays yours.
No, and in many cases they should not. Prices, volumes and supplier relations all pass through these negotiations, and keeping that on your own hardware is often what purchasing and compliance need before they will approve anything. Which model size fits depends on how much weighing the process needs, and we would work that out with you. Either way, we recommend the same split: hard criteria in code, judgement in the model.
This is a contractual question rather than a cryptographic one, and it is the harder half. The construction gives you the factual basis: you can prove who acted, under whose authority, within which limits, and who approved what. It cannot decide what an agent's commitment is worth. That has to come from the framework agreement, the way signature rules and authority limits do for employees today. Companies have drawn this boundary for a long time. The new part is writing it down so software can check it.
The pieces underneath are published and in production use: verifiable credentials, selective disclosure, key binding, issuance and presentation flows. The open layer is the one above them: authority. Who may act for whom, in what scope, up to what limit, for how long, and how it is taken back. For people those questions are answered. For software none of them is, and there is no schema a verifier can rely on. Standardisation is underway and nothing is adopted. We keep that layer isolated and replaceable, so a standard can be adopted when one arrives rather than retrofitted afterwards. We can be early because the bilateral case works today without an industry-wide registry.
With one process and one counterparty. Pick something repetitive that already runs against a framework agreement, and decide where the threshold sits. That conversation is usually the valuable part, and it happens with purchasing and legal rather than with developers. In the bilateral case the technical setup for two agents is small next to it. It stops being small when the same mandate has to work against partners you have no agreement with. Do not start with a platform for all suppliers at once. The bilateral case is where this works and where it stays affordable.
Tell us which process keeps coming back, and who has to sign it off.