Die US-Senatoren Josh Hawley und Chris Murphy kuendigten den AI Agent Accountability Act am 1. Oktober 2026 an. Er soll Betreiber und Entwickler von KI-Agenten nach dem Computer Fraud and Abuse Act zivil- und strafrechtlich haftbar machen, wenn Agenten Systeme unrechtmaessig beschaedigen oder darauf zugreifen.
Der Vorschlag ist kein Gesetz. Die oeffentliche Berichterstattung zeigt auch, dass er Teil eines politischen Streits ist: Einige Abgeordnete wollen spezifische KI-Haftungsregeln, waehrend die Trump-Regierung argumentiert, bestehende Verbraucher-, Produkthaftungs- und Durchsetzungsinstrumente reichten aus. Trotzdem ist der Entwurf ein wichtiges Governance-Signal, weil er autonomes Agentenverhalten auf verantwortliche Betreiber, Entwickler und Safeguard-Entscheidungen zurueckfuehrbar machen will.
Was der Entwurf tun wuerde
Die Hawley-Mitteilung sagt, der Entwurf wuerde Betreiber haftbar machen, die wissentlich einen Agenten betreiben, der ruecksichtslos Hacking-Schaden oder Verlust verursacht. Er wuerde auch Entwickler haftbar machen, wenn sie angemessene Safeguards nicht umsetzen, obwohl sie von Hacking-Faehigkeiten des Agenten wussten oder wissen mussten. Zudem koennten der US Attorney General und State Attorneys General klagen, um Agenten-Hacking zu unterbinden.
Das sind Aussagen aus der Sponsorenmitteilung, keine geltenden Pflichten. Zum Review-Zeitpunkt lag eine Pressemitteilung vor, nicht finaler Gesetzestext. Teams sollten dies daher als regulatorische Risiko-Intelligenz behandeln, nicht als neue Compliance-Deadline.
Warum es jetzt wichtig ist
Das Signal ist wichtig, weil es eine Luecke trifft, die viele Agentenprogramme bereits haben. Klassische Software-Governance nimmt oft an, dass ein Mensch die Aktion angewiesen hat, ein System sie ausfuehrte und Logs beides identifizieren koennen. Tool-nutzende Agenten verwischen diese Grenze. Sie koennen ein Ziel ueber Websites, APIs, Terminals und Identitaetssysteme verfolgen und dabei eine Grenze erreichen, die der Betreiber nicht erwartet hat.
Wenn Gesetzgeber diesen Weg weitergehen, wird Evidenz zur praktischen Frage. Kann der Entwickler zeigen, dass er bekannte Agenten-Hacking-Verhalten getestet hat? Kann der Betreiber zeigen, welcher Agent deployt war, welche Tools er erreichen durfte, welche Prompts oder Aufgaben autorisiert waren und welche Kontrollen externe Aktionen begrenzten? Kann ein Incident-Team autorisierten Sicherheitstest, unbeabsichtigte autonome Probe und boeswillige Nutzung unterscheiden?
Maetras Leitfaden zu KI-Audit-Evidenz folgt derselben Disziplin. Evidenz muss Systemidentitaet, menschliche Autoritaet, Policy, Runtime-Ereignis und Ergebnis verbinden. Bei Agenten gehoeren Tool-Grenzen und Task Scope dazu.
Was Teams vor einer Gesetzesaenderung tun sollten
Zuerst sollten sie Agenten inventarisieren, die externe Systeme beruehren koennen. Dazu gehoeren Produktagenten, interne Copiloten, Coding Agents, MCP-Tools, Research Agents und geplante Automationen. Entscheidend ist nicht, ob etwas Chatbot-Interface hat. Entscheidend ist, ob es Requests senden, Daten aendern, Dateien schreiben, Code deployen, Credentials nutzen oder fremde Systeme beruehren kann.
Zweitens sollten sie Autoritaet dokumentieren. Jeder Agent braucht Owner, erlaubte Aufgaben, erlaubte Tools, Datengrenzen, Eskalationsweg und Shutdown- oder Revocation-Route. Wenn ein Agent durch die Autoritaet eines Menschen handelt, sollten Logs diese Beziehung zeigen und nicht hinter einem Shared Service Account verstecken.
Drittens sollten sie Safeguard-Evidenz bewahren. Dazu gehoeren Testergebnisse, Policy-Versionen, Tool-Allowlists, Reviewer-Entscheidungen, Incident Reports und Versionsaenderungen. Ein kuenftiger Haftungsstandard mag darueber streiten, was angemessene Safeguards sind. Ohne Nachweis, welche Safeguards bestanden, wird jede Antwort schwerer.
Was unklar bleibt
Die Zukunft des Entwurfs ist offen. Er kann sich im Ausschuss aendern, scheitern, in ein anderes KI-Paket wandern oder durch Bundes- oder Landesvorschlaege ersetzt werden. Die Zusammenfassung beantwortet auch nicht, wie Haftung zwischen Modellanbietern, App-Entwicklern, Kunden, Nutzern, Tool-Anbietern und Cloud-Hosts verteilt wuerde.
Sie beweist auch nicht, dass ein bestimmter aktueller Agenten-Incident die vorgeschlagenen Rechtstests erfuellt. Berichte ueber unerwartete Agentenaktivitaet sind als Hinweis auf Policy-Aufmerksamkeit zu behandeln, nicht als geklaerte Haftungsfeststellungen.
Maetra-Analyse
Die Governance-Lehre gilt sofort, auch wenn das Gesetz nie kommt. Agentenprogramme muessen von allgemeiner Acceptable-Use-Sprache zu Aktions-Evidenz wechseln. Was durfte der Agent tun, wer autorisierte es, welche Safeguards begrenzten es, was geschah an einer externen Grenze und wer pruefte die Ausnahme?
Das ist nicht nur rechtliche Haltung. Es ist Betriebsdisziplin. Teams mit Inventar, Task-Grenzen, Runtime Policy, Human-Review-Triggern und Audit-Evidenz sind besser fuer Regulatoren, Kunden und Incident Response vorbereitet. Teams ohne diese Records muessen nachtraeglich ueber Absicht streiten, wenn der Agent schon gehandelt hat.
Die enge Lesart lautet: Der AI Agent Accountability Act ist ein vorgeschlagenes Haftungsregime, kein geltendes Recht. Das breite Signal ist schwerer zu ignorieren. Policymaker fragen, ob autonome Agenten eine direkte Accountability-Kette von Modelldesign ueber Deployment bis Incident-Evidenz brauchen.
Sources
Primary source: Ankuendigung von Hawley und Murphy.
Corroboration: Axios-Bericht zu Entwurf und Policy-Kontext.