Ein Agent meldet Ihr Ja. Der Entwurf verlangt eine Unterschrift vom Bestätigungsdienst.

Summary

• Nach dem AACP-Entwurf zeigt ein Bestätigungsdienst alle als bestätigungspflichtig markierten Parameter außerhalb der Sprachmodell-Inferenz an und signiert die selbst eingeholte Zustimmung oder Ablehnung.
• Die ausführende Stelle prüft den Beleg gegen den wirklichen Vorgang, den vorgesehenen Empfänger, eine frische Herausforderung und die Gültigkeitsdauer. Ein unterschriebenes Nein bleibt von einer unerreichbaren Person getrennt.

Ein Ja im Chat ist billig. Der Agent kann es einem zweiten Agenten weitererzählen, der es einer API vorlegt. Auf diesem Weg verschwindet leicht die Frage, welchen Betrag und welchen Empfänger der Mensch überhaupt gesehen hat. Der am 2. November veröffentlichte Entwurf zum Agent Action Confirmation Protocol stellt einen Bestätigungsdienst vor die Ausführung. Der handelnde Agent beschreibt die geplante Aktion als strukturierte Daten. Der Dienst zeigt die nötigen Felder, lässt ausdrücklich zu- oder ablehnen und signiert genau diese Entscheidung. Er kann Teil einer Nutzeranwendung, einer betrieblichen Autorisierungsumgebung oder einer eigenen App sein. Entscheidend ist der technische Weg: Die Bestätigung wird programmatisch erhoben, außerhalb der Inferenz des Sprachmodells.

Die Oberfläche ist dabei keine Dekoration. Ein Feld mit confirm=true verlangt eine lesbare Bezeichnung und muss vor dem Entscheid angezeigt werden. Der Dienst hat sämtliche so markierten Parameter zu zeigen. Er behandelt Bezeichnungen und Werte als Daten; eingeschleuste Links, Formatierungen oder Befehle dürfen nicht die Anzeige steuern. Der Agent darf die Buchung oder Überweisung vorschlagen. Er darf den Preis, das Ziel oder die Wirkung der Aktion nicht durch eine glatte Zusammenfassung ersetzen.

Das signierte Ergebnis enthält eine Bindung an die Aktion. Die prüfende Stelle berechnet den Fingerabdruck aus dem Vorgang, den sie tatsächlich ausführen soll, und vergleicht ihn mit dem Beleg. Dazu kommen die Prüfung des Dienstschlüssels nach eigener Vertrauensregel, die Bindung an den handelnden Agenten, eine frische Herausforderung, eine Frist und Schutz vor Wiederverwendung. Ein Beleg für einen Delegierten öffnet keine Tür für den nächsten. Bei schwer rückgängig zu machenden Aktionen empfiehlt der Entwurf zusätzlich einen Fingerabdruck der tatsächlich gezeigten Felder.

Der Klick allein ist damit erst die halbe Geschichte; die andere Hälfte ist der Inhalt des Bildschirms.

Auch beim Nein macht der Text keine Abkürzung. Denied ist eine signierte Ablehnung. Eine neue Anfrage darf nur vom Nutzer ausgehen. Unobtainable meldet, dass eine Entscheidung nicht eingeholt werden konnte, und ist kein signierter Nutzerentscheid. Abgelaufene, wiederholte, umgeleitete oder inhaltlich unpassende Belege führen jeweils zu eigenen Ergebnissen. Bei einem Fehler darf der Prüfer nicht einen gültigen Teil herauspicken und trotzdem ausführen. Für ein Zahlungssystem ist der Unterschied zwischen Ablehnung und Nichterreichbarkeit eine Betriebsregel mit Folgen.

Im IETF-Datatracker steht der Text als individuelle Einreichung. Ein belastbarer nächster Beleg wäre ein Interoperabilitätstest: Nach der Anzeige wird ein Aktionsfeld geändert, ein Pflichtfeld verborgen oder ein alter Beleg erneut eingereicht; unabhängige Implementierungen müssen den Vorgang stoppen. Dann ließe sich prüfen, ob die vorgeschlagene Trennung auch unter Druck hält.