Advanced AI Society Proof-of-Control eröffnet eine neue Front in der Sicherheit von Agenten
Advanced AI Society hat Proof-of-Control am 17. September zur öffentlichen Prüfung veröffentlicht, obwohl Fragen zu Version, Umfang und Reife des Entwurfs offenbleiben. Der vorgeschlagene Standard fordert KI-Agenten dazu auf, manipulationssichere Nachweise zu erzeugen, die belegen, dass jede kontrollierte Aktion innerhalb ihrer autorisierten Grenzen blieb. Außerdem verlagert er die Sicherheit von Agenten weg vom Vertrauen in private Logs eines Anbieters.
Dieser Wandel ist wichtig, weil Agenten über die Textgenerierung hinausgehen. Sie können Tools aufrufen, auf Datensätze zugreifen, Software ändern, mit externen Diensten kommunizieren und Transaktionen auslösen. Ein vierteljährliches Audit kann nicht jede Entscheidung in Echtzeit beobachten, während ein vom Betreiber des Agenten kontrolliertes Log nur begrenzte unabhängige Sicherheit bieten kann.
Advanced AI Society erklärt, dass mehr als 80 Sicherheitsverantwortliche an der Ausgestaltung des Ansatzes beteiligt waren. Die Gruppe verortet die Arbeit bei Linux Foundation Decentralized Trust, wodurch das Projekt einen neutralen Rahmen für technische Governance erhält. Neutrale Governance macht einen Entwurf jedoch nicht vollständig, und kryptografische Nachweise garantieren nicht, dass eine Organisation die richtigen Kontrollen ausgewählt hat.
Der Kongress nähert sich demselben Problem aus einer anderen Richtung. Ein parteiübergreifender Vorschlag im Repräsentantenhaus würde NIST anweisen, Sicherheitspraktiken für Agenten zu entwickeln, die kontinuierliche Verifikation, Sicherheitsbewertungen, Inventare und manipulationsresistente Aufzeichnungen abdecken. Das Aufeinandertreffen freiwilliger offener Standards und staatlich gestützter Anforderungen ist die eigentliche Geschichte.
Advanced AI Society Proof-of-Control ist mehr als eine Mitgliedschaftsankündigung
Die entscheidende Veränderung ist die Veröffentlichung eines überprüfbaren Vorschlags zur Verifikation von Agenten, nicht die damit verbundene Schlagzeile zur Mitgliedschaft.
Advanced AI Society beschrieb seine Ankündigung im September als Beitritt zur Linux Foundation und zu LF Decentralized Trust. Aufzeichnungen der Linux Foundation zeigen jedoch, dass die Organisation bereits am 21. April 2026 assoziiertes Mitglied von LF Decentralized Trust wurde. Die neuere Ankündigung verbindet daher eine frühere Entwicklung zur Mitgliedschaft mit der öffentlichen Vorstellung von Proof-of-Control und dem dazugehörigen Lab.
Diese Unterscheidung ist wichtig. Eine Mitgliedschaft positioniert eine Organisation innerhalb eines kollaborativen Netzwerks, bestätigt aber nicht jede Behauptung oder technische Ausgestaltung, die sie veröffentlicht. Die folgenreichere Maßnahme besteht darin, einen vorgeschlagenen Verifikationsstandard in ein Umfeld einer Foundation einzubringen, in dem externe Mitwirkende ihn prüfen, hinterfragen und erweitern können.
Der Mitgliedschaftseintrag vom April nennt Advanced AI Society als eines von zwei neuen assoziierten Mitgliedern. Die Ankündigung zum Start vom September stellt Proof-of-Control als Lab von LF Decentralized Trust vor und lädt zu öffentlichen Kommentaren ein.
Proof-of-Control ist auf eine direkte Frage ausgerichtet: Kann eine unabhängige Partei verifizieren, dass ein KI-Agent innerhalb seiner zugewiesenen Kontrollen geblieben ist? Eine Kontrolle könnte einen Agenten daran hindern, ohne Genehmigung Geld zu bewegen, einschränken, auf welche Kundendaten er zugreifen kann, oder die während einer Aufgabe verfügbaren Tools begrenzen.
Der Vorschlag konzentriert sich auf die Aktionsgrenze, also den Punkt, an dem ein Agent versucht, ein Tool aufzurufen oder eine externe Wirkung zu erzeugen. Seine Architektur platziert an dieser Grenze ein separates Interception-Gateway. Das Gateway bewertet die vorgeschlagene Aktion, blockiert Aktionen außerhalb der erklärten Richtlinie und erzeugt Nachweise über die Entscheidung.
Dieses Design ist spezifischer als herkömmliche Zusagen zu verantwortungsvoller KI. Es beschreibt, wo die Durchsetzung erfolgt, welche Nachweise erzeugt werden sollten und wie eine andere Partei diese Nachweise überprüfen könnte. Advanced AI Society nennt zudem sechs Verifikationsbereiche: Herkunft, Datenschutz, Portabilität, Autorisierung, Identität und Sicherheit.
Die zentrale Idee des Frameworks ist, dass das Laufzeitlog eines Agenten eine Behauptung bleibt, wenn derselbe Betreiber sowohl die Ausführung als auch die Protokollierung kontrolliert. Ein kompromittiertes System könnte eine Aktion auslassen, einen Datensatz umschreiben oder die Protokollierung umgehen. Ein hilfreicher Verifikationsmechanismus muss daher Veränderungen sichtbar machen und die Annahmen benennen, von denen seine Nachweise abhängen.
Das Projekt schlägt mehrere Stufen der Absicherung vor. Niedrigere Stufen beruhen auf Aussagen des Betreibers oder dem Zugriff eines Prüfers. Höhere Stufen streben unabhängig überprüfbare Aufzeichnungen oder Ausführungssperren an, die eine kontrollierte Aktion ohne entsprechenden Nachweis verhindern.
Dadurch entsteht ein bedeutender Unterschied zwischen der Beobachtung einer Aktion und ihrer Einschränkung. Ein manipulationssicherer Datensatz kann Ermittlern helfen, nach einem Vorfall festzustellen, was aufgezeichnet wurde. Eine korrekt implementierte Ausführungssperre kann eine abgedeckte Aktion verhindern, wenn ihre Autorisierungsbedingungen nicht erfüllt sind.
Proof-of-Control beansprucht nicht, festzustellen, ob das zugrunde liegende Modell sicher, präzise oder ausgerichtet ist. Es entscheidet auch nicht, ob ein Unternehmen einem Agenten zu viel Befugnis eingeräumt hat. Es versucht festzustellen, ob erklärte Kontrollen die Aktionen innerhalb eines definierten Geltungsbereichs geregelt haben.
Dieses engere Ziel ist eine Stärke, weil es Implementierenden etwas Testbares bietet. Zugleich ist es die größte Einschränkung des Projekts. Ein Nachweis, dass ein Agent eine schwache Richtlinie befolgt hat, belegt nur die Einhaltung dieser schwachen Richtlinie.
Der Kongress macht die Verifikation von Agenten zu einer Beschaffungsfrage
Die Sicherheit von Agenten entwickelt sich von einer technischen Präferenz zu einer Voraussetzung für Geschäfte mit regulierten Käufern und der Bundesregierung.
Der vorgeschlagene Stop Rogue AI Act würde das National Institute of Standards and Technology anweisen, Standards, Leitlinien und Best Practices für den sicheren Einsatz von Agenten zu veröffentlichen. Laut berichteten Details zum Gesetzentwurf würde die Arbeit kontinuierliche Agenteninventare, Sicherheitsbewertungen, manipulationsresistente Logs und die Verifikation von Agentenaktionen abdecken.
Der Vorschlag stammt von den Abgeordneten Josh Gottheimer, einem Demokraten aus New Jersey, und Mike Lawler, einem Republikaner aus New York. Die meisten Organisationen würden die daraus resultierenden NIST-Praktiken freiwillig anwenden. Bundesauftragnehmer, die um neue Aufträge konkurrieren, stünden unter stärkerem Druck, sie zu erfüllen.
Dieser Mechanismus ist wichtiger als eine weit gefasste regulatorische Erklärung. Beschaffungsanforderungen können Technologiemärkte beeinflussen, ohne jeder privaten Organisation eine verpflichtende Architektur vorzuschreiben. Anbieter übernehmen staatlich ausgerichtete Kontrollen häufig in ihre gesamten Produkte, da die Pflege separater Sicherheitssysteme Kosten und Komplexität erhöht.
NIST arbeitete bereits an diesem Bereich, bevor der Vorschlag aus dem Repräsentantenhaus aufkam. Im Februar kündigte die Behörde eine Initiative zu Agentenstandards an, die Interoperabilität, Identität, Autorisierung und Sicherheit abdeckt. Sie bat zudem um Beiträge von Betreibern, Entwicklern, Forschern und Infrastrukturprovidern.
Die Überschneidung mit Proof-of-Control ist deutlich. Beide Bemühungen konzentrieren sich auf dauerhafte Identität, definierte Befugnisse, beobachtbare Aktionen und Nachweise, die außerhalb der eigenen Darstellung des Agenten bestehen bleiben. Beide erkennen außerdem an, dass Agenten über Tools, Anmeldedaten und Serviceschnittstellen mit bestehenden Systemen interagieren.
Ihre Rollen bleiben unterschiedlich. NIST entwickelt Leitlinien über einen föderalen Standardisierungsprozess und kann Beschaffungserwartungen beeinflussen. Advanced AI Society schlägt über eine offene Community einen umsetzungsorientierten Standard vor und möchte, dass sich unabhängige Verifikationswerkzeuge darum entwickeln.
Der Vorschlag des Repräsentantenhauses setzt drei Gruppen unter Druck. Anbieter von Agenten müssen erklären, wie ihre Systeme jeden Agenten identifizieren und dessen Berechtigungen begrenzen. Unternehmen, die Agenten einsetzen, müssen Inventare führen und bestimmen, welche Systeme folgenreiche Aktionen vornehmen können. Sicherheitsanbieter müssen Nachweise erzeugen, die externe Prüfer untersuchen können.
Bundesauftragnehmer sehen sich mit dem deutlichsten potenziellen Durchsetzungsmechanismus konfrontiert. Ein Anbieter könnte offene Verifikation beim Verkauf in gewöhnliche kommerzielle Märkte als optional behandeln. Diese Position wird schwerer aufrechtzuerhalten, wenn ein großer Käufer maschinenlesbare Inventare, kontinuierliche Aufzeichnungen und unabhängig testbare Kontrollen verlangt.
Versicherer und Prüfer schaffen eine weitere Quelle des Drucks. Ein Versicherer, der einen Agenten bewertet, der Zahlungen auslösen kann, benötigt mehr als ein Richtliniendokument. Er braucht Nachweise dafür, welche Identität handelte, welche Befugnis bestand, welche Kontrolle die Anfrage bewertete und ob der daraus resultierende Datensatz intakt blieb.
Dasselbe Problem tritt im Gesundheitswesen auf. Ein Agent kann Krankenakten abrufen, einen Fall zusammenfassen oder eine Anordnung vorbereiten. Ein Krankenhaus muss zwischen der Bestätigung der Integrität der Akte und der Bestätigung, dass die klinische Entscheidung angemessen war, unterscheiden. Proof-of-Control behandelt Ersteres, während Governance und fachliche Prüfung weiterhin Letzteres bestimmen.
Entwickler werden die Veränderung an Integrationspunkten spüren. Sicherheit kann nicht länger mit dem Schutz eines Modellendpunkts enden. Teams müssen Anmeldedaten, Tool-Berechtigungen, Delegationsketten, Datenzugriff und Nebenwirkungen über jeden Dienst hinweg berücksichtigen, den ein Agent erreichen kann.
Deshalb wird die Sicherheit von Agenten eher zu einer Beschaffungsfrage als zu einem Funktionsvergleich. Käufer benötigen Nachweise, die über verschiedene Anbieter hinweg aussagekräftig bleiben. Proprietäre Dashboards helfen Betreibern bei der Verwaltung ihrer eigenen Systeme, schaffen jedoch nicht automatisch eine gemeinsame Sprache für Absicherung bei Prüfern, Versicherern, Regulierungsbehörden und Kunden.
Offene Verifikation fordert von Anbietern kontrollierte Logs heraus
Der zentrale Wettbewerb besteht zwischen portablen Nachweisen Dritter und Sicherheitsaufzeichnungen, die weiterhin vom bewerteten Anbieter kontrolliert werden.
Herkömmliche Unternehmenslogs sind nicht nutzlos. Sie unterstützen die Reaktion auf Vorfälle, Überwachung, Fehlersuche und Compliance. Das Problem besteht darin, dass der Wert eines Logs davon abhängt, wer es erzeugt hat, ob es jeden relevanten Pfad erfasste und ob jemand es nachträglich ändern konnte.
KI-Agenten erschweren diese Fragen. Ihre Aktionen können von sich veränderndem Kontext, abgerufenen Daten, Modellausgaben, Tool-Antworten und delegierten Berechtigungen abhängen. Ein System kann den endgültigen Tool-Aufruf aufzeichnen, ohne genug Kontext zu bewahren, um festzustellen, warum der Aufruf autorisiert war.
Proof-of-Control schlägt Nachweise vor, die während der Ausführung erzeugt und nicht erst nach einem Vorfall rekonstruiert werden. Zudem strebt es portable Aufzeichnungen an, die verschiedene Parteien interpretieren können, ohne privilegierten Zugriff auf die gesamte Umgebung des Betreibers zu erhalten.
Die veröffentlichte Standardübersicht des Projekts beschreibt Nachweise als binär, zeitgleich, manipulationssicher und transparent bezüglich verbleibender Vertrauensannahmen. Binär bedeutet, dass die kontrollierte Aktion entweder innerhalb der erklärten Grenze blieb oder nicht. Es bedeutet nicht, dass das umfassendere Ergebnis korrekt war.
Betrachten wir einen Einkaufsagenten, der berechtigt ist, Bestellungen unterhalb eines vom Unternehmen festgelegten Limits aufzugeben. Die Verifikationsebene könnte die Identität des Agenten, die delegierte Befugnis, den bewerteten Betrag und das Ergebnis der Richtlinienprüfung aufzeichnen. Sie könnte auch eine Bestellung ablehnen, die dieses Limit überschreitet.
Die Nachweise würden jedoch nicht belegen, dass der Einkauf notwendig war, dass der Lieferant vertrauenswürdig war oder dass der Preis ein gutes Preis-Leistungs-Verhältnis bot. Dies sind separate geschäftliche Beurteilungen. Verifikation zeigt, ob eine explizite Kontrolle eingehalten wurde, nicht ob die Organisation eine sinnvolle Kontrolle entworfen hat.
Diese Trennung ist entscheidend, weil Sicherheitssprache häufig mehrere unterschiedliche Behauptungen zusammenfasst. Ein Anbieter kann einen Agenten als sicher beschreiben, weil er Berechtigungen, Audit-Protokolle und Optionen für menschliche Freigaben bietet. Diese Funktionen beweisen nicht, dass es keinen Umgehungsweg gibt oder dass jede folgenschwere Aktion den Kontrollpunkt durchläuft.
Das vorgeschlagene Gateway zur Aktionsabfangung von Proof-of-Control versucht, dieses Problem zu lösen. Es befindet sich außerhalb des Agentenprozesses und vermittelt kontrollierte Tool-Aufrufe. Damit die Architektur funktioniert, darf der Agent über keinen alternativen Berechtigungs- oder Netzwerkpfad verfügen, der das Gateway umgeht.
Diese Bedingung ohne Umgehungsmöglichkeit ist schwer zu erfüllen. Moderne Softwareumgebungen enthalten Dienstkonten, zwischengespeicherte Zugangsdaten, Hintergrundprozesse, Plug-ins und direkte Netzwerkverbindungen. Eine Prüfung muss das umgebende System testen und darf nicht nur die Ausgabe des Gateways untersuchen.
Der Vorschlag bringt zudem Zielkonflikte beim Datenschutz mit sich. Verifizierungsnachweise müssen genug aussagen, um eine belastbare Schlussfolgerung zu ermöglichen, ohne Prompts, persönliche Datensätze, Modellgewichte oder geschäftskritische Daten offenzulegen. Kryptografische Verfahren können die Offenlegung verringern, doch ihr Nutzen hängt von der Qualität der zugrunde liegenden Messung und Implementierung ab.
Auch die Portabilität stellt eine Herausforderung dar. Zwei Anbieter können unterschiedliche Richtliniensprachen, Identitätssysteme, Laufzeitumgebungen und Protokollformate verwenden. Ein gemeinsames Evidenzschema kann einen Teil dieser Unterschiede normalisieren. Es kann jedoch nicht alle Unterschiede darin beseitigen, wie die ursprünglichen Kontrollen definiert oder durchgesetzt wurden.
Offene Governance bietet eine glaubwürdige Antwort auf diese Fragmentierung. Öffentliche Spezifikationen, Testvektoren, Referenzcode und dokumentierte Bedrohungsmodelle geben Käufern und Forschenden Material, das sie prüfen können. Ein vom Anbieter kontrolliertes Assurance-Programm kann weniger offenlegen und sich ohne externe Zustimmung verändern.
Die Linux Foundation stellt die institutionelle Infrastruktur für diese Arbeit bereit. Sie kann Community-Governance, Regeln zum geistigen Eigentum, Beitragsprozesse und langfristige Betreuung unterstützen. Sie zertifiziert jedoch nicht, dass das Design die Eindämmung von Agenten oder die Einführung in Unternehmen gelöst hat.
Diese Grenze sollte sichtbar bleiben. Die Trägerschaft durch eine Foundation ist ein Hinweis darauf, dass ein Projekt einen Rahmen für Zusammenarbeit hat. Sie ist kein Beweis dafür, dass jede Bereitstellung konform ist, jeder Nachweis vollständig ist oder Kunden die daraus entstehenden Aufzeichnungen akzeptieren werden.
Der Entwurf zeigt bereits, warum unabhängige Prüfung wichtig ist
Die frühen Inkonsistenzen von Proof-of-Control verdeutlichen den Unterschied zwischen der Einführung eines Standards und seiner Etablierung.
Die September-Ankündigung der Advanced AI Society bezeichnet die Veröffentlichung als „v1.0 working draft“ und erklärt, dass öffentliche Kommentare noch bis zum 30. Oktober 2026 möglich sind. Die ausführlichere Standardseite bezeichnet das Dokument als „Working Draft v0.1“ und nennt den 7. Oktober als Frist für Kommentare.
Auch die Veranstaltungsbeschreibung der Linux Foundation nennt es Proof-of-Control v0.1. Diese Unterschiede können auf nicht synchronisierte Veröffentlichungen, einen geänderten Veröffentlichungsplan oder getrennte Bezeichnungen für verwandte Artefakte zurückgehen. Unabhängig vom Grund sind Unklarheiten bei Version und Frist für Mitwirkende relevant, die entscheiden müssen, was sie prüfen.
Ein Standard hängt von stabilen Kennungen ab. Implementierende müssen wissen, welche normativen Anforderungen gelten, ob ein Testvektor zum aktuellen Text passt und wann eine inkompatible Änderung erfolgt ist. Auditoren können Konformität nicht anhand einer sich verändernden Bezeichnung bewerten.
Das entwertet nicht das Ziel des Projekts. Es zeigt, warum neutrale Repositories, Release-Tags, Änderungsaufzeichnungen und öffentliche Issue-Verfolgung wichtig sind. Ein offener Standard muss seine eigene Herkunft überprüfbar machen, bevor er Agentenanbieter dazu auffordert, dasselbe zu tun.
Das geplante öffentliche Briefing ist für den 23. September angesetzt. Es bringt Führungskräfte der Linux Foundation, Vertreter der Advanced AI Society, Sicherheitsinvestoren, Identitätsanbieter, Versicherer und die Agentic AI Foundation zusammen.
Diese Veranstaltung kann Governance-Fragen klären, doch öffentliche Diskussion allein wird technische Unsicherheit nicht auflösen. Mitwirkende benötigen eine normative Spezifikation, ein explizites Bedrohungsmodell, Konformitätstests und reproduzierbare Implementierungen. Sie benötigen außerdem ein Verfahren, um zu entscheiden, welche Mechanismen jede Anforderung erfüllen.
Das Projekt erklärt, sein Repository umfasse eine Referenzimplementierung, maschinenlesbare Claim-Definitionen, Angriffsszenarien und signierte Testvektoren. Die Implementierung wird als Referenz und nicht als Produktionsprodukt beschrieben. Dieser Hinweis ist wichtig, weil früher Code Machbarkeit demonstrieren kann, ohne die Anforderungen an operative Sicherheit zu erfüllen.
Ein Referenz-Gateway kann zeigen, wie eine Richtlinie ausgewertet und signierte Nachweise erstellt werden. Ein Produktions-Gateway muss zudem Zugangsdiebstahl, Race Conditions, Replay-Versuche, unvollständige Telemetrie, Schlüsselkompromittierung, Infrastrukturausfälle und feindselige Betreiber überstehen.
Vollständigkeit schafft ein weiteres schwieriges Problem. Manipulationssichere Aufzeichnungen können zeigen, dass erfasste Einträge nicht verändert wurden. Sie können jedoch nicht für sich allein beweisen, dass jede relevante Aktion in die Aufzeichnung einging. Ein Agent mit einem unüberwachten Pfad könnte außerhalb der Aufzeichnungen handeln, während die sichtbare Nachweiskette intern konsistent bleibt.
Die von Advanced AI Society vorgeschlagene stärkere Stufe begegnet diesem Problem durch Ausführungsgating. In diesem Modell kann eine erfasste Aktion nicht stattfinden, sofern sie nicht die Kontrolle durchläuft und Nachweise erzeugt. Die verbleibende Frage lautet, ob tatsächlich jede folgenschwere Aktion erfasst wird.
Auch externe Auswirkungen verkomplizieren das Bild. Ein Gateway kann verifizieren, dass ein Agent eine autorisierte Zahlungsanfrage gesendet hat. Es kann nicht automatisch beweisen, dass eine Bank die Zahlung exakt wie erwartet abgewickelt hat. Assurance muss Agentenseitige Nachweise mit Bestätigungen aus externen Systemen verbinden.
Identitätsketten bergen ähnliche Risiken. Ein Agent kann Arbeit an einen anderen delegieren, der anschließend einen Drittanbieterdienst aufruft. Jede Übergabe kann Befugnisse, Kontext oder Datenfreigaben verändern. Ein glaubwürdiger Standard muss die Zurechenbarkeit bewahren, ohne anzunehmen, dass ein einzelnes Identitätstoken die gesamte Kette erklärt.
Die Qualität der Kontrollen bleibt die größte konzeptionelle Einschränkung. Proof-of-Control verzichtet ausdrücklich darauf zu beurteilen, ob eine gewählte Regel sinnvoll war. Diese Trennung macht technische Konformität handhabbar, doch Organisationen könnten Konformität als weitergehenden Sicherheitsnachweis vermarkten.
Käufer sollten dieser Abkürzung widerstehen. Ein verifizierter Agent kann eine unsichere Richtlinie zuverlässig befolgen. Er kann auch autorisierte Aktionen auf Grundlage fehlerhafter Modellschlussfolgerungen ausführen. Laufzeitverifizierung ergänzt Tests, menschliche Aufsicht, Risikoanalyse und Incident Response. Sie ersetzt diese nicht.
Die verantwortungsvollste Behauptung des Projekts ist daher die eng gefasste. Es will die Nachweise darüber verbessern, ob deklarierte Kontrollen erfasste Aktionen gesteuert haben. Behauptungen über vollständige Agentensicherheit, regulatorische Konformität oder eliminierte Haftung würden über das hinausgehen, was diese Nachweise belegen.
Der Standard muss beweisen, dass er über reale Agenten-Stacks hinweg funktioniert
Die Akzeptanz wird davon abhängen, ob Proof-of-Control über gehostete Modelle, lokale Systeme und Multi-Vendor-Workflows hinweg funktionieren kann, ohne eine weitere isolierte Compliance-Schicht zu schaffen.
Agenten-Stacks in Unternehmen stammen selten von nur einem Anbieter. Ein Unternehmen kann ein gehostetes Modell, ein internes Orchestrierungsframework, einen externen Identitätsanbieter, Cloud-Datenbanken und Spezialtools verschiedener Anbieter einsetzen. Jede Ebene stellt unterschiedliche Kontrollen und Telemetriedaten bereit.
Proof-of-Control behauptet, dass sein Modell der Aktionsgrenze in offenen und geschlossenen Konfigurationen funktionieren kann. Der Modellanbieter muss nicht zwingend seine Gewichte oder Trainingsdaten offenlegen. Die Verifizierungsebene beobachtet stattdessen kontrollierte Aktionen, bei denen das Orchestrierungssystem externe Fähigkeiten aufruft.
Dieser Ansatz begünstigt Organisationen, die ihren eigenen Agenten-Loop kontrollieren. Sie können ein Gateway einfügen, Zugangsdaten beschränken und Tool-Aufrufe über eine definierte Grenze leiten. Ein verwalteter Agentendienst ist schwieriger, weil der Anbieter die Orchestrierungsumgebung kontrolliert und entscheidet, welche Nachweise offengelegt werden.
Dieser Unterschied macht die Architektur zu einem Beschaffungskriterium. Kunden, die einen verwalteten Agenten bewerten, müssen fragen, ob er unabhängig überprüfbare Nachweise ausgibt, ob die Nachweise jeden relevanten Tool-Aufruf abdecken und ob ein Betreiber den deklarierten Pfad umgehen kann.
Ein Finanzteam liefert einen konkreten Testfall. Angenommen, ein Agent erstellt Rechnungen, aktualisiert Buchhaltungsunterlagen und löst Banküberweisungen aus. Das Verifizierungssystem muss zwischen dem Lesen eines Hauptbuchs, dem Vorschlagen einer Zahlung, dem Einholen einer Freigabe und dem Übermitteln der endgültigen Anweisung unterscheiden.
Jede Aktion benötigt eine Identität, eine Autoritätsquelle, eine anwendbare Richtlinie, eine Zeitreferenz und ein Ergebnis. Das System muss diese Kette über Tools hinweg bewahren, ohne Kontodaten in einen öffentlichen Verifizierungsdatensatz zu leaken. Es muss zudem eine widerrufene Freigabe oder eine Richtlinienänderung während der Ausführung handhaben.
Ein Agent für Softwareentwicklung schafft einen anderen Testfall. Er kann privaten Code prüfen, Dateien ändern, Tests ausführen und eine Bereitstellung anfordern. Proof-of-Control könnte verifizieren, auf welches Repository der Agent zugegriffen hat und ob die Bereitstellung eine namentlich benannte Freigabe erforderte.
Der Standard müsste dennoch indirekte Auswirkungen berücksichtigen. Code, der eine Autorisierungsschranke passiert, kann später Daten offenlegen oder das Produktionsverhalten verändern. Laufzeitnachweise zeigen, wie der Agent eine Grenze überschritten hat, während Software-Review und Sicherheitstests das von ihm erzeugte Artefakt bewerten.
Das Gesundheitswesen testet Datenschutz und berufliche Befugnisse. Ein Agent könnte im Auftrag eines Klinikers eine Patientenakte abrufen und einen Entwurf für eine Anordnung zur Freigabe senden. Nachweise müssen belegen, dass der Zugriff innerhalb der gewährten Befugnis blieb, ohne die zugrunde liegenden medizinischen Informationen offenzulegen.
Diese Szenarien erfordern mehr als ein generisches signiertes Protokoll. Sie benötigen gemeinsame Semantik für Identitäten, Berechtigungen, Richtlinienauswertung, Nachweisaufbewahrung und Fehlerverhalten. Ein Datensatz, den ein Prüfer anders interpretiert als ein anderer, schafft keine Interoperabilität.
Konformitätstests werden daher über die Glaubwürdigkeit des Projekts entscheiden. Unabhängige Teams sollten dieselbe Testsuite gegen getrennte Implementierungen ausführen und konsistente Ergebnisse erhalten können. Negative Tests sollten zeigen, wie Systeme versagen, wenn Aufzeichnungen verändert werden, Aktionen das Gateway umgehen oder Befugnisse ablaufen.
Auch die Leistung wird wichtig sein. Agenten führen während einer Aufgabe oft mehrere Tool-Aufrufe aus. Kontinuierliche Evidenzgenerierung fügt Aufwand für Signierung, Speicherung, Verifizierung und Richtlinienauswertung hinzu. Unternehmen benötigen Latenz- und Betriebsdaten aus repräsentativen Bereitstellungen.
Die öffentlichen Materialien von Proof-of-Control betonen die Verifizierung mit Maschinengeschwindigkeit, weil menschliche Prüfung nicht mit der Ausführungsgeschwindigkeit von Agenten mithalten kann. Diese Annahme ist plausibel, doch Automatisierung kann auch eine fehlerhafte Regel mit Maschinengeschwindigkeit wiederholen. Änderungen an Kontrollen müssen daher ebenso sorgfältig gesteuert werden wie Codeänderungen.
Die operative Verantwortung ist eine weitere offene Frage. Sicherheitsteams können grundlegende Richtlinien definieren, Anwendungsteams Gateways integrieren, Identitätsteams Delegationen verwalten und Compliance-Teams Nachweise aufbewahren. Ein Standard, der von einem einheitlichen Verantwortlichen ausgeht, wird sich in großen Organisationen schwertun.
Das Projekt kann dennoch erfolgreich sein, ohne zum einzigen Sicherheitsstandard für Agenten zu werden. Sein Evidenzmodell könnte NIST-Leitlinien, Anbieter-APIs, Versicherungsfragebögen oder Beschaffungsvorlagen beeinflussen. Gemeinsame Konzepte können den Markt prägen, auch wenn Implementierungen variieren.
Das größere Risiko ist zeremonielle Akzeptanz. Anbieter könnten Konformität behaupten, obwohl sie nur ausgewählte Aktionen abdecken, oder die Sprache offener Verifizierung verwenden, ohne unabhängige Tests bereitzustellen. Klare Konformitätsstufen und maschinenprüfbare Anforderungen können dieses Verhalten verringern.
Drei Signale werden entscheiden, ob offene Verifizierung zur Infrastruktur wird
Die nächsten drei Prüfungen sind Spezifikationskohärenz, unabhängige Implementierung und regulatorische Akzeptanz.
Das erste Signal ist, ob Advanced AI Society die Konflikte im Entwurf hinsichtlich Versionierung und Frist für Kommentare auflöst. Ein öffentliches Release-Tag sollte den normativen Text, Schemas, Testvektoren, die Referenzimplementierung und die Änderungshistorie miteinander verknüpfen.
Dieser Schritt würde das zentrale Argument des Projekts stärken. Überprüfbare Herkunft sollte beim Standard selbst beginnen. Bleiben die Artefakte uneinheitlich gekennzeichnet, werden Unternehmen zögern, darauf Kontrollen oder Verträge aufzubauen.
Das zweite Signal ist die unabhängige Implementierung. Der Referenzcode der Gründungsorganisation kann belegen, dass seine Autoren umgesetzt haben, was sie beschrieben. Ein separates Team muss zeigen, dass die Spezifikation genügend Details vermittelt, um kompatible Nachweise und Verifizierungsergebnisse zu erzeugen.
Aussagekräftige Implementierungsberichte sollten neben Erfolgen auch Fehler dokumentieren. Sie sollten Latenzzeiten, Integrationsaufwand, nicht unterstützte Agenten-Frameworks, Datenschutzbeschränkungen und während der Tests gefundene Umgehungsmöglichkeiten benennen. Behauptungen zur Produktionstauglichkeit benötigen Belege aus Umgebungen außerhalb der direkten Kontrolle der Autoren.
Das dritte Signal ist, wie NIST und der Kongress Anforderungen an die Verifizierung von Agenten definieren. Wenn bundesweite Leitlinien kontinuierliche Bestandsaufnahmen, manipulationsresistente Aufzeichnungen, zuordenbare Identitäten und unabhängig testbare Kontrollen verlangen, wird Proof-of-Control einen erkennbaren Beschaffungsbedarf adressieren.
Das Projekt würde zusätzlich an Dynamik gewinnen, wenn Bundesauftragnehmer oder regulierte Käufer portable Nachweise statt Anbieter-Screenshots verlangen. Diese Anforderung würde Interoperabilität belohnen und Raum für mehrere Verifizierungsanbieter schaffen.
Das gegenteilige Ergebnis würde das Argument für ein gemeinsames Ökosystem schwächen. Behörden könnten konventionelle Logs und regelmäßige Audits akzeptieren, oder der Kongress könnte die zugrunde liegende Gesetzgebung nicht voranbringen. Unternehmen könnten offene Verifizierung dann als optionales Sicherheitsexperiment behandeln.
Die breitere KI-Debatte in Washington bleibt ungelöst. Führende Kongressmitglieder haben über Leitplanken gesprochen und zugleich einen zurückhaltenden Regulierungsansatz sowie den Wettbewerb mit China betont. Diese Spannung macht gezielte technische Standards plausibler als ein umfassendes KI-Gesetz.
Die Unterscheidung zwischen Gesetzgebung und Inkrafttreten muss klar bleiben. Der Sicherheitsvorschlag des Repräsentantenhauses für Agenten ist keine etablierte Bundespolitik. Die bestehende Initiative von NIST ist aktiv, doch ihre endgültigen Leitlinien und Marktauswirkungen entwickeln sich noch.
Advanced AI Society hat daher ein enges Zeitfenster, um das entstehende Vokabular zu beeinflussen. Wenn sie vor einer Verfestigung der Beschaffungsregeln umsetzbare Kontrollen demonstrieren kann, könnten ihre Definitionen prägen, wie Käufer Runtime Assurance beschreiben.
Entwickler sollten beobachten, ob gängige Agenten-Frameworks native Unterstützung für portable Nachweise ergänzen. Unternehmenskäufer sollten Anbieter auffordern, jede kontrollierte Aktion und jeden Weg zu benennen, der die Durchsetzung umgeht. Sicherheitsteams sollten die Integrität der Nachweise mit ihrer Vollständigkeit vergleichen.
Auch Wissensarbeiter haben ein Interesse daran. Ein Agent, der auf die E-Mails, Dokumente, Kalender oder Finanzkonten einer Person zugreift, kann Folgen auslösen, bevor der Nutzer sie prüft. Nutzer benötigen eine verständliche Aufzeichnung darüber, welche Befugnisse sie erteilt haben und was der Agent damit getan hat.
Die Proof-of-Control-Initiative von Advanced AI Society bietet eine ernsthafte Antwort auf diesen Bedarf, bleibt jedoch ein früher Entwurf. Ihr Wert wird aus erprobter Interoperabilität, präzisem Umfang und Nachweisen entstehen, die einer Prüfung durch andere Parteien als ihre Schöpfer standhalten.
Der richtige nächste Schritt besteht nicht darin, anzunehmen, dass der Standard die Sicherheit von Agenten löst. Käufer und Entwickler sollten den Entwurf prüfen, die No-Bypass-Anforderung testen und während der öffentlichen Überprüfung konkrete Implementierungsfehler einreichen. Offene Verifizierung wird erst dann zur Infrastruktur, wenn unabhängige Teilnehmer ihre Behauptungen reproduzieren und ihre Grenzen benennen können.
