The identity problem: who acts when an agent acts?
Until recently the question was simple: a human opens a document, reviews it and signs. With AI agents the picture shifts. Software assistants research vendors, draft contract proposals, fill in forms, suggest changes and in some setups trigger follow-up steps themselves. As soon as an agent does not merely prepare but acts on behalf of a person or organisation, a question arises that contract law has always dealt with: who is actually involved here, and how can it be evidenced?
This article is food for thought, not a product catalogue. We classify why cryptographic identity becomes a topic in connection with agents, which questions are open and which considerations ISVs can make now without prematurely building technology or promises. We therefore say at the start: this is about debate and orientation. Sign2x delivers no products here that we advertise, and we derive no commitments from this text.
The starting observation is simple. Contracts rest on declarations of intent by persons who can identify themselves as such, or by organisations acting through authorised representatives. An agent is neither. It is a tool acting on behalf, with powers someone has given it. Legally, acts are as a rule attributed to whoever deploys the tool. Practically, though, the question arises how a counterparty recognises that an agent is acting, on whose behalf and with what scope of authority.
The one hard distinction of this article: acting on behalf is not acting as a person. An agent preparing a contract acts differently from one concluding it bindingly. The line between preparation and conclusion is where identity, authorisation and evidence must come together. Blurring it creates attribution problems: the counterparty claims never to have agreed, and the principal claims the agent exceeded its powers.
Four sub-questions arise in practice. First, the identity of the principal: whose will is executed? Second, the identity of the agent: which system acted, in which version, with which configuration? Third, authority: what was the agent allowed to do, up to what value, for which counterparty, with what expiry? Fourth, evidence: how can it later be shown that mandate, authority and action fit together? None of these questions is new, but agents make them urgent because they act faster, more often and less visibly than humans.
The regulatory framework is growing too. The AI Act (Regulation (EU) 2024/1689) addresses transparency and oversight duties for AI systems, depending on risk class. It does not regulate contract law but creates expectations that people can tell when they are dealing with an AI system. For ISVs integrating agents into processes that is a hint to think about transparency early, even where no duty exists yet.
MCP and message authentication as research context
Part of the debate takes place around protocols through which agents talk to tools and data sources. The Model Context Protocol (MCP, modelcontextprotocol.io) is such an open protocol through which AI applications connect tools and context. In this environment there are research and standardisation discussions on how the authenticity of messages between agent and tool can be secured: who sent this request, was it altered on the way, and is the sender authorised for this action?
We mention this as research context, not as a product. The discussion is in flux, and we want neither to claim a state that does not exist nor to anticipate results. From a signature perspective the connection is obvious: cryptographic methods for message authentication and for signing documents rest on related foundations, namely binding a statement to a key under the control of an identifiable actor. Requirements in the contract setting, especially legal effect and form, go well beyond that.
A central difference deserves attention. Message authentication answers the technical question “does this message come from this key?”. A signature under the eIDAS Regulation answers a legal question: “did this identified person confirm this document in this form?” Both can work together, but they are not the same. An agent sending messages authentically does not thereby act with legal effect on behalf of a human. Equating the two creates false security.
The question of delegation belongs here too. In security architectures it is well known that authority can be delegated, limited and revoked, for instance through time-limited permissions or permissions for particular actions. For agents in the contract setting comparable mechanisms with legal viability would be needed: who granted which authority, how can it be limited, how is it revoked, and what does the proof look like? There are ideas and experiments today but no generally accepted solution, and the legal position in detail is open.
We follow this development attentively and track publications from standardisation and research. That does not mean we plan or announce a feature set. It means we want to understand which requirements might come to signature and identity layers so our architecture builds no dead ends. A sober stance seems the only responsible one: observe, learn, classify and act only when law and technology are viable.
What a signature API could theoretically do
A thought experiment, not a commitment: what role could a signature API play in a world where agents prepare contracts and humans approve them? We see three theoretical functions derived from properties signing flows have anyway. The first is binding to a person or organisation. The decisive act, consent, stays reserved for an identified person, and the flow proves who confirmed what when. That is the basic principle of any signature and holds regardless of who prepared the document.
The second function would be separation of preparation and approval. An agent can create transactions, fill documents and suggest signers, but approval remains a conscious step by a human with their own identification. Technically this maps as a state model: transaction created by application X, on behalf of user Y, approved by Y after identification. The events arising provide the evidence of who did what. How such state models are built is described in webhook state management for e-signature events.
The third function would be evidence of authority in the log: for each transaction it is recorded which application triggered it, with which mandate and which limits. That does not raise the legal effect of a signature but improves traceability when asked later how a document came about. It matches the evidence idea we describe in DORA Article 30 and the signature audit trail: separate promise and proof, secure the proof.
One restriction we consider important: all of this is theoretical possibility, derived from properties signing flows have today. These are not announced features. Whether and how they would be legally viable and practically sensible is open, and depends on developments we do not control: case law, standards, market practice. Anyone deriving a product promise from this overinterprets this text.
From a data protection view the topic is delicate too. Agents process much data, and when they act on behalf of persons, questions of purpose limitation, transparency and control arise. The GDPR applies here as well, and the requirements on automated decisions especially deserve attention. A process that reserves approval for humans and informs them understandably beforehand is not only legally more robust but also more trustworthy.
What Sign2x does not claim
For clarity we state what this text does not say. Sign2x offers no MCP product and no agent interface we advertise here. We claim no AI-based detection of fields or content in documents. We do not claim agents can today conclude contracts with legal effect for persons or organisations, and we claim no certifications in connection with AI. We name no dates for functions in this field.
What we do claim is our existing frame: Sign2x is an API layer for simple, advanced and qualified signatures (SES, AES, QES). We are not a qualified trust service provider, and QES runs through a partner QTSP such as Sign8. The platform runs on the Open Sovereign Cloud (OSC) from T-Systems, a European operation under European law. That is the basis on which we think about further development without anticipating it.
Why so much restraint? Because the topic is prone to exaggeration. In a short time many statements about agents, trust and contracts have arisen that do not withstand scrutiny. Buyers in regulated markets notice and punish it. Whoever wants to be credible in this field says what they know, what they suspect and what they do not know. We consider that the better path, commercially too, because trust cannot be built through volume.
Outlook for ISVs: what you can examine now
Even without finished solutions ISVs can usefully prepare today. First: inventory where agents play a role in your product, whether as built-in assistant, as an interface for customer agents or as internal automation. Second: draw the line between preparing and triggering and decide consciously where a human must consent. Third: log the origin of transactions: which application or agent triggered it, on behalf of whom?
Fourth: keep approval bound to identity. Where legal effect arises, an identified person should act, in the signature level the transaction requires. A classification of the levels is in AES vs QES via API. Fifth: inform users transparently when an agent is involved and give them control over scope and revocation. Sixth: watch developments, legal and technical, and plan quarterly rhythms for review.
Seventh, and this matters to us: build on stable foundations. Tenancy, a clean event model, clear references and a documented supply chain are valuable regardless of agents and form the basis for whatever comes later. How ISVs deal with partners in the chain is described in QTSP partners for ISVs, and the effect of the wallet on identity is explained in eIDAS 2.0 and the EUDI wallet.
If you want to discuss these questions we gladly do so, as an exchange on equal terms and without sales pressure. The technical frame of our platform today is in the developer hub, terms in the help centre, practical cases under use cases and more articles in the Sign2x blog. The Sign2x quiz serves your own positioning. A classification of the sovereignty question is in Cloud Act vs data sovereignty, security guidance at the BSI.
Ask for an exchange on AI agents and identity
Further reading: NIS-2 evidence through the signature audit trail and AML-ready signature API for ISVs. On the AI Act see the regulation text.
Frequently asked questions
Can AI agents conclude contracts with legal effect today?
That is legally open in detail and depends on constellation and jurisdiction. Acting on behalf is generally attributed to the principal. We claim no general legal effectiveness.
Does Sign2x offer an MCP product or AI features?
No. This article is a classification. We advertise no MCP product and no AI-based document or field detection.
What is the difference between message authentication and signature?
Message authentication shows technically that a message comes from a key. A signature under eIDAS shows legally that an identified person confirmed a document in a particular form.
What can ISVs do concretely now?
Inventory agent roles, separate preparation and approval, log the origin of transactions, bind approvals to identity, inform users transparently and watch developments.
Where is Sign2x hosted and is it a QTSP?
On the Open Sovereign Cloud (OSC) from T-Systems. Sign2x is not a QTSP, for QES the qualification runs through a partner such as Sign8.
