Das Identitätsproblem: wer handelt, wenn ein Agent handelt?
Bis vor Kurzem war die Frage einfach: Ein Mensch öffnet ein Dokument, prüft es und signiert. Mit KI-Agenten verschiebt sich das Bild. Software-Assistenten recherchieren Anbieter, entwerfen Vertragsentwürfe, füllen Formulare aus, schlagen Änderungen vor und lösen in manchen Konstellationen Folgeschritte selbst aus. Sobald ein Agent nicht nur vorbereitet, sondern im Namen einer Person oder Organisation handelt, stellt sich eine Frage, die das Vertragsrecht seit jeher beschäftigt: Wer ist hier eigentlich beteiligt, und wie lässt sich das belegen?
Dieser Beitrag ist ein Denkanstoß, kein Produktkatalog. Wir ordnen ein, warum kryptografische Identität im Zusammenhang mit Agenten zum Thema wird, welche Fragen offen sind und welche Überlegungen ISVs jetzt anstellen können, ohne vorschnell Technik oder Versprechen zu bauen. Wir sagen deshalb gleich zu Beginn: Es geht um Debatte und Orientierung. Sign2x liefert hier keine Produkte, die wir bewerben, und wir leiten aus diesem Text keine Zusagen ab.
Die Ausgangsbeobachtung ist einfach. Verträge beruhen auf Willenserklärungen von Personen, die sich als solche ausweisen können, oder von Organisationen, die durch Vertretungsberechtigte handeln. Ein Agent ist weder das eine noch das andere. Er ist ein Werkzeug, das im Auftrag handelt, mit Befugnissen, die ihm jemand gegeben hat. Rechtlich wird das Handeln im Regelfall dem zugerechnet, der das Werkzeug einsetzt. Praktisch stellt sich aber die Frage, wie ein Gegenüber erkennt, dass ein Agent handelt, in wessen Auftrag und mit welchem Umfang an Befugnis.
Die eine harte Unterscheidung dieses Beitrags lautet: Handeln im Auftrag ist nicht Handeln als Person. Ein Agent, der einen Vertrag vorbereitet, handelt anders als einer, der ihn bindend abschließt. Die Grenze zwischen Vorbereitung und Abschluss ist die Stelle, an der Identität, Autorisierung und Nachweis zusammenkommen müssen. Wer sie verwischt, erzeugt Zurechnungsprobleme: Der Vertragspartner behauptet, nie zugestimmt zu haben, und der Auftraggeber behauptet, der Agent habe seine Befugnisse überschritten.
Für die Praxis ergeben sich vier Teilfragen. Erstens die Identität des Auftraggebers: Wessen Wille wird ausgeführt? Zweitens die Identität des Agenten: Welches System hat gehandelt, in welcher Version, mit welcher Konfiguration? Drittens die Befugnis: Was durfte der Agent, bis zu welchem Wert, für welche Gegenpartei, mit welchem Verfallsdatum? Viertens der Nachweis: Wie lässt sich später belegen, dass Auftrag, Befugnis und Handlung zusammenpassen? Keine dieser Fragen ist neu, aber Agenten machen sie dringlich, weil sie schneller, häufiger und weniger sichtbar handeln als Menschen.
Auch regulatorisch wächst der Rahmen. Die KI-Verordnung (EU) 2024/1689 adressiert Transparenz- und Aufsichtspflichten für KI-Systeme, je nach Risikoklasse. Sie regelt nicht das Vertragsrecht, schafft aber Erwartungen daran, dass Menschen nachvollziehen können, wann sie mit einem KI-System zu tun haben. Für ISVs, die Agenten in Prozesse einbinden, ist das ein Hinweis, Transparenz früh mitzudenken, auch dort, wo noch keine Pflicht besteht.
MCP und Nachrichtenauthentifizierung als Forschungskontext
Ein Teil der Debatte findet rund um Protokolle statt, über die Agenten mit Werkzeugen und Datenquellen sprechen. Das Model Context Protocol (MCP, modelcontextprotocol.io) ist ein solches offenes Protokoll, mit dem KI-Anwendungen Werkzeuge und Kontexte anbinden. In diesem Umfeld gibt es Forschungs- und Standardisierungsdiskussionen darüber, wie sich die Authentizität von Nachrichten zwischen Agent und Werkzeug sichern lässt: Wer hat diese Anfrage gesendet, wurde sie unterwegs verändert, und ist der Absender für diese Aktion berechtigt?
Wir erwähnen das als Forschungskontext, nicht als Produkt. Die Diskussion ist im Fluss, und wir wollen weder einen Stand behaupten, den es nicht gibt, noch Ergebnisse vorwegnehmen. Aus Sicht von Signaturen ist der Zusammenhang naheliegend: Kryptografische Verfahren zur Nachrichtenauthentifizierung und zur Signatur von Dokumenten beruhen auf verwandten Grundlagen, nämlich der Bindung einer Aussage an einen Schlüssel, der unter Kontrolle eines identifizierbaren Akteurs steht. Die Anforderungen im Vertragsumfeld, insbesondere Rechtswirkung und Form, gehen aber deutlich darüber hinaus.
Ein zentraler Unterschied lohnt Beachtung. Nachrichtenauthentifizierung beantwortet die technische Frage „Stammt diese Nachricht von diesem Schlüssel?“. Eine Signatur im Sinne der eIDAS-Verordnung beantwortet eine rechtliche Frage: „Hat diese identifizierte Person dieses Dokument in dieser Form bestätigt?“ Beides kann zusammenwirken, aber es ist nicht dasselbe. Ein Agent, der Nachrichten authentisch sendet, handelt damit nicht automatisch rechtswirksam im Namen eines Menschen. Wer beides gleichsetzt, schafft Scheinsicherheit.
Auch die Frage der Delegation gehört hierher. In Sicherheitsarchitekturen ist bekannt, dass Befugnisse delegiert, eingeschränkt und widerrufen werden können, etwa durch zeitlich begrenzte Berechtigungen oder Berechtigungen für bestimmte Aktionen. Für Agenten im Vertragsumfeld bräuchte man vergleichbare Mechanismen mit rechtlicher Tragfähigkeit: Wer hat welche Befugnis erteilt, wie lässt sie sich begrenzen, wie widerruft man sie, und wie sieht der Beleg aus? Dazu gibt es heute Ideen und Experimente, aber keine allgemein akzeptierte Lösung, und die Rechtslage im Einzelnen ist offen.
Wir beobachten diese Entwicklung aufmerksam und verfolgen Veröffentlichungen aus Standardisierung und Forschung. Das bedeutet nicht, dass wir einen Funktionsumfang planen oder ankündigen. Es bedeutet, dass wir verstehen wollen, welche Anforderungen auf Signatur- und Identitätsschichten zukommen könnten, damit unsere Architektur keine Sackgassen baut. Eine nüchterne Haltung scheint uns hier die einzig verantwortbare: beobachten, lernen, einordnen und erst handeln, wenn Recht und Technik tragfähig sind.
Was eine Signatur-API theoretisch leisten könnte
Gedankenspiel statt Zusage: Welche Rolle könnte eine Signatur-API in einer Welt spielen, in der Agenten Verträge vorbereiten und Menschen sie freigeben? Wir sehen drei theoretische Funktionen, die sich aus Eigenschaften ableiten, die Signaturstrecken ohnehin haben. Die erste ist die Bindung an einen Menschen oder eine Organisation. Die entscheidende Handlung, die Zustimmung, bleibt einer identifizierten Person vorbehalten, und die Strecke belegt, wer wann was bestätigt hat. Das ist das Grundprinzip jeder Signatur und gilt unabhängig davon, wer das Dokument vorbereitet hat.
Die zweite Funktion wäre die Trennung von Vorbereitung und Freigabe. Ein Agent kann Vorgänge anlegen, Dokumente füllen und Unterzeichner vorschlagen, die Freigabe aber bleibt ein bewusster Schritt eines Menschen mit eigener Identifikation. Technisch lässt sich das als Zustandsmodell abbilden: Vorgang angelegt durch Anwendung X, im Auftrag von Nutzer Y, freigegeben durch Y nach Identifikation. Die Ereignisse, die dabei entstehen, liefern den Nachweis, wer was getan hat. Wie solche Zustandsmodelle gebaut werden, beschreibt der Beitrag Webhook State Management für E-Signatur-Events.
Die dritte Funktion wäre der Nachweis von Befugnissen im Protokoll: Bei jedem Vorgang wird festgehalten, welche Anwendung ihn angestoßen hat, mit welchem Auftrag und welchen Grenzen. Das erhöht nicht die Rechtswirkung einer Signatur, verbessert aber die Nachvollziehbarkeit, wenn später gefragt wird, wie ein Dokument entstanden ist. Es entspricht dem Evidence-Gedanken, den wir im Beitrag DORA Artikel 30 und der Signatur-Audit-Trail beschreiben: Zusage und Beleg trennen, den Beleg sicherstellen.
Dazu eine Einschränkung, die wir für wichtig halten: Das alles sind theoretische Möglichkeiten, abgeleitet aus Eigenschaften, die Signaturstrecken heute haben. Es sind keine angekündigten Funktionen. Ob und wie sie rechtlich tragfähig und praktisch sinnvoll wären, ist offen, und es hängt von Entwicklungen ab, die wir nicht kontrollieren: Rechtsprechung, Standards, Marktpraxis. Wer daraus ein Produktversprechen ableitet, überinterpretiert diesen Text.
Aus Sicht des Datenschutzes ist das Thema ebenfalls heikel. Agenten verarbeiten viele Daten, und wenn sie im Namen von Personen handeln, stellt sich die Frage nach Zweckbindung, Transparenz und Kontrolle. Die DSGVO gilt auch hier, und besonders die Anforderungen an automatisierte Entscheidungen verdienen Beachtung. Ein Prozess, der Menschen die Freigabe vorbehält und sie vorher verständlich informiert, ist nicht nur rechtlich robuster, sondern auch vertrauenswürdiger.
Was Sign2x nicht behauptet
Zur Klarheit halten wir fest, was dieser Text nicht aussagt. Sign2x bietet kein MCP-Produkt und keine Agenten-Schnittstelle an, die wir hier bewerben. Wir behaupten keine KI-gestützte Erkennung von Feldern oder Inhalten in Dokumenten. Wir behaupten nicht, dass Agenten heute rechtswirksam Verträge für Personen oder Organisationen abschließen können, und wir behaupten keine Zertifizierungen im Zusammenhang mit KI. Wir nennen keine Termine für Funktionen in diesem Feld.
Was wir behaupten, ist unser bestehender Rahmen: Sign2x ist eine API-Schicht für einfache, fortgeschrittene und qualifizierte Signaturen (SES, AES, QES). Wir sind kein qualifizierter Vertrauensdiensteanbieter, und QES läuft über einen Partner-QTSP wie Sign8. Die Plattform läuft auf der Open Sovereign Cloud (OSC) von T-Systems, einem europäischen Betrieb unter europäischem Recht. Das ist die Grundlage, auf der wir über Weiterentwicklungen nachdenken, ohne sie vorwegzunehmen.
Warum so viel Zurückhaltung? Weil das Thema anfällig für Übertreibung ist. In kurzer Zeit sind viele Aussagen über Agenten, Vertrauen und Verträge entstanden, die einer Prüfung nicht standhalten. Käufer in regulierten Märkten merken das und bestrafen es. Wer in diesem Feld glaubwürdig sein will, sagt, was er weiß, was er vermutet und was er nicht weiß. Wir halten das für den besseren Weg, auch kommerziell, weil Vertrauen sich nicht durch Lautstärke aufbauen lässt.
Ausblick für ISVs: was Sie jetzt prüfen können
Auch ohne fertige Lösungen können ISVs heute sinnvoll vorarbeiten. Erstens: Inventarisieren Sie, wo Agenten in Ihrem Produkt eine Rolle spielen, sei es als eingebauter Assistent, als Schnittstelle für Kundenagenten oder als interne Automatisierung. Zweitens: Ziehen Sie die Linie zwischen Vorbereiten und Auslösen und entscheiden Sie bewusst, wo ein Mensch zustimmen muss. Drittens: Protokollieren Sie die Herkunft von Vorgängen: Welche Anwendung oder welcher Agent hat angestoßen, im Auftrag von wem?
Viertens: Halten Sie die Freigabe an Identität gebunden. Wo rechtliche Wirkung entsteht, sollte eine identifizierte Person handeln, in der Signaturstufe, die der Vorgang verlangt. Eine Einordnung der Stufen bietet der Beitrag AES vs QES per API. Fünftens: Informieren Sie Nutzer transparent, wenn ein Agent beteiligt ist, und geben Sie ihnen Kontrolle über Umfang und Widerruf. Sechstens: Beobachten Sie die Entwicklung, rechtlich wie technisch, und planen Sie Quartalsrhythmen für Überprüfung ein.
Siebtens, und das ist uns wichtig: Bauen Sie auf stabilen Grundlagen. Mandantenfähigkeit, ein sauberes Ereignismodell, klare Referenzen und eine dokumentierte Lieferkette sind unabhängig von Agenten wertvoll und bilden die Basis für alles, was später kommt. Wie ISVs mit Partnern in der Kette umgehen, beschreibt der Beitrag QTSP-Partner für ISVs, und die Wirkung der Wallet auf Identität erläutert eIDAS 2.0 und die EUDI Wallet.
Wenn Sie über diese Fragen sprechen möchten, tun wir das gern, als Austausch auf Augenhöhe und ohne Verkaufsdruck. Den technischen Rahmen unserer heutigen Plattform finden Sie im Developer Hub, Begriffe im Help Center, Praxisfälle unter Use Cases und weitere Beiträge im Sign2x Blog. Zur eigenen Standortbestimmung dient das Sign2x Quiz. Eine Einordnung der Souveränitätsfrage bietet Cloud Act vs Datensouveränität, Hinweise zur Sicherheit das BSI.
Austausch zu KI-Agenten und Identität anfragen
Weiterführend: NIS-2 Nachweis über den Audit-Trail der Signatur und GwG-konforme Signatur-API für ISVs. Zur KI-Verordnung siehe den Verordnungstext.
Häufige Fragen
Können KI-Agenten heute rechtswirksam Verträge abschließen?
Das ist rechtlich im Einzelnen offen und hängt von Konstellation und Rechtsordnung ab. Handeln im Auftrag wird in der Regel dem Auftraggeber zugerechnet. Wir behaupten keine allgemeine Rechtswirksamkeit.
Bietet Sign2x ein MCP-Produkt oder KI-Funktionen an?
Nein. Der Beitrag ist eine Einordnung. Wir bewerben kein MCP-Produkt und keine KI-gestützte Dokumenten- oder Felderkennung.
Was ist der Unterschied zwischen Nachrichtenauthentifizierung und Signatur?
Nachrichtenauthentifizierung belegt technisch, dass eine Nachricht von einem Schlüssel stammt. Eine Signatur nach eIDAS belegt rechtlich, dass eine identifizierte Person ein Dokument in bestimmter Form bestätigt hat.
Was können ISVs jetzt konkret tun?
Rollen von Agenten inventarisieren, Vorbereitung und Freigabe trennen, Herkunft von Vorgängen protokollieren, Freigaben an Identität binden, Nutzer transparent informieren und die Entwicklung beobachten.
Wo wird Sign2x gehostet und ist es ein QTSP?
Auf der Open Sovereign Cloud (OSC) von T-Systems. Sign2x ist kein QTSP, für QES läuft die Qualifikation über einen Partner wie Sign8.
