Ersetzen Sie die Bezeichnung durch eine begrenzte Aufgabe
Eine als Agent bezeichnete Plattform kann Änderungen vorschlagen, Arbeitsabläufe ausführen oder Tools koordinieren, aber die Bezeichnung legt nicht fest, was sie sicher tun kann. Eine Evaluierung sollte mit einer konkreten Aufgabe, ihrem zulässigen Umfang, der erforderlichen Genehmigung und dem Nachweis der Erledigung beginnen. Ein überzeugendes Gespräch oder eine überzeugende Demonstration ist kein Beweis dafür, dass das System eine Genehmigung an den genauen Mieter und die Konfigurationsänderung bindet, die der Prüfer beabsichtigt hat.
In diesem Artikel werden defensive Akzeptanzkriterien für eine Authentifizierungsplattform vorgeschlagen. Es wird nicht behauptet, dass EmailAuth eine autonome Ausführung, Tool-Integrationen oder einen Genehmigungsmechanismus implementiert. Es wurde kein Agent mit der Produktion verbunden, keine Anmeldeinformationen erstellt oder die Konfiguration geändert. Die hier zitierte offizielle Dokumentation veranschaulicht spezifische Kontrollmechanismen in anderen Systemen; Die zu evaluierende Plattform muss ihr eigenes unterstütztes Verhalten und autorisierte Testnachweise liefern.
Definieren Sie die Aufgabe und ihre Autoritätsgrenze
Geben Sie das beabsichtigte Ergebnis in betrieblicher Hinsicht an, z. B. die Vorbereitung einer Richtlinienempfehlung, die Erstellung eines genauen DNS Diffs oder die Ausführung einer bereits genehmigten Änderung in einer isolierten Geräteumgebung. Trennen Sie die schreibgeschützte Analyse von Schreibvorgängen, Veröffentlichungen, Zugriffsänderungen und externer Kommunikation. Ein System, das zum Zusammenfassen von Berichten berechtigt ist, sollte nicht auf die Berechtigung zum Ändern DNS schließen, weil es glaubt, dass die Änderung hilfreich wäre.
Erfassen Sie Mandant, Domäne, Ressourcentyp, zulässige Tools, Eingabequellen und verbotene Aktionen. Geben Sie die Identität an, unter der jedes Tool betrieben werden würde, und den Umfang, den diese Identität tatsächlich hat. Leitfaden zur mehrinstanzenfähigen Identität von Azure unterstützt die Trennung von Identität und Ressourcenautorisierung. Bei der Evaluierung sollte sichergestellt werden, dass die Plattform nicht einfach einen anderen Mandanten ersetzen kann, indem sie einen Anforderungsparameter ändert oder sich auf einen mehrdeutigen Anzeigenamen verlässt.
Binden Sie die Genehmigung an den genau vorgesehenen Unterschied
Eine nützliche Genehmigung identifiziert das Ziel, die aktuelle Baseline, die beabsichtigte Änderung, die Konsequenzen und den Überprüfungsplan. Es sollte nicht als wiederverwendbare Berechtigung für spätere Änderungen behandelt werden, die ähnlich erscheinen. Der Bewerter sollte fragen, was das System tut, wenn sich der vorgeschlagene Unterschied nach der Genehmigung ändert, wenn ein anderer Akteur die Ressource bearbeitet oder wenn die Aufgabe mit unvollständigem Kontext fortgesetzt wird. Hierbei handelt es sich um vorgeschlagene Anforderungen, nicht um Behauptungen über ein bestimmtes Zulassungsprodukt.
GitHubs Dokumentation zur Bereitstellungsüberprüfung beschreibt einen konkreten Umgebungsüberprüfungsmechanismus mit Genehmigungs- und Ablehnungsverhalten und konfigurationsabhängigen Kontrollen. Es zeigt, dass Genehmigungssysteme definierte Bereiche und Einschränkungen haben. Es beweist nicht die Genehmigung-zu-DNS-Diff-Bindung in einer Authentifizierungsplattform. Fordern Sie auf, dass das bewertete Produkt genau zeigt, was der Prüfer genehmigt und wie die Ausführung an dieses Objekt gebunden bleibt.
Erkennen Sie veralteten Zustand, anstatt ihn zu überschreiben
Ein Plan kann unsicher werden, wenn sich die zugrunde liegende Konfiguration zwischen Überprüfung und Ausführung ändert. Der Abnahmetest sollte die Grundlinie der Vorrichtung nach der Genehmigung ändern und beobachten, ob das System stoppt, erneut liest und bei Bedarf eine neue Entscheidung anstrebt. Ein zuvor genehmigter gewünschter Wert berechtigt nicht dazu, stillschweigend eine andere legitime Änderung zu verwerfen. Behalten Sie die vom Plan verwendete Baseline-ID oder Digest und die unmittelbar vor der Ausführung überprüften Beweise bei.
Dokumentation zu Azure DNS Einträgen beschreibt Etags, die gleichzeitige Änderungen erkennen können, wenn sie in unterstützten Aktualisierungsvorgängen verwendet werden. Dabei handelt es sich um einen anbieterspezifischen Mechanismus und nicht um eine universelle Eigenschaft von Agententools oder DNS . Die bewertete Plattform sollte ihre tatsächliche Parallelitätskontrolle und ihr Verhalten bei Auftreten eines Konflikts ermitteln. Eine Warnung in einer narrativen Antwort ist nicht gleichbedeutend mit der Verhinderung eines veralteten Schreibvorgangs.
Überprüfen Sie die Ergebnisse unabhängig von der Zuverlässigkeit des Tools
Eine erfolgreiche Tool-Antwort kann zeigen, dass eine Anfrage angenommen wurde, ohne den beabsichtigten externen Zustand nachzuweisen. Definieren Sie die für die Aufgabe erforderlichen Post-Change-Prüfungen und die Quelle dieser Beobachtungen. Bei einem DNS-bezogenen Gerät kann dies unterstützte autorisierende und rekursive Beobachtungen mit genauen Namen, Typen und Zeiten umfassen. Bei einem Berichtsworkflow kann es sein, dass der Ausgabeumfang und die Herkunft beibehalten werden. Dieser Artikel führt keine der beiden Arten von Prüfungen durch.
Die Plattform sollte Teilausfälle und Unsicherheiten ehrlich melden. Wenn die Überprüfung fehlschlägt, sollte die Aufgabe nicht als abgeschlossen gekennzeichnet werden, nur weil der Schreibvorgang erfolgreich war. Die Wiederherstellung erfordert einen unterstützten Plan und die erforderliche Autorität. Es sollte nicht automatisch zusätzliche Änderungen oder externe Mitteilungen außerhalb des genehmigten Umfangs einführen. Behalten Sie die Differenz zwischen versuchten, akzeptierten, überprüften und ungelösten Aktionen im Bewertungsdatensatz bei.
Testen Sie das Verhalten falscher Mandanten und mehrdeutiger Ziele
Verwenden Sie mindestens zwei synthetische Mandanten mit ähnlichen Bezeichnungen, aber unterschiedlichen stabilen Bezeichnern und Ressourcen. Bitten Sie den Gutachter, zu bestätigen, dass eine genehmigte Maßnahme für das eine nicht auf das andere angewendet werden kann. Schließen Sie einen Fall ein, in dem die für Menschen lesbare Domäne oder der Kundenname nicht eindeutig ist, und einen Fall, in dem ein Tool eine Ressource außerhalb des genehmigten Bereichs zurückgibt. Das sichere erwartete Ergebnis sollte vor dem Test spezifiziert und nicht nach Beobachtung des Systemverhaltens rationalisiert werden.
Führen Sie diese Tests nicht ohne ausdrückliche Genehmigung mit den Daten eines anderen Kunden oder einer Produktionsumgebung durch. Die Spiele sollten keine Live-Geheimnisse oder Folgeziele enthalten. Eine schreibgeschützte Aufgabe kann weiterhin Daten offenlegen, wenn die Mandantenbindung falsch ist. Daher muss der Testplan sowohl Lese- als auch Schreibvorgänge abdecken. Dieses Manuskript liefert vorgeschlagene Fälle, keine Ergebnisse einer echten Agentenbewertung.
Ein Arbeitsblatt für beobachtbare Aufgaben
Erstellen Sie ein Arbeitsblatt mit Aufgabendefinition, zulässigem Umfang, Gerätemieter, Startstatus, vorgeschlagenem Unterschied, Genehmigungsreferenz, Ausführungsidentität, zulässigen Toolaufrufen und Überprüfungskriterien. Fügen Sie erwartetes Verhalten für veralteten Status, falschen Mandanten, verweigerte Aktion, teilweisen Fehler und fehlgeschlagene Überprüfung hinzu. Erfassen Sie tatsächliche Beobachtungen erst nach einem autorisierten Lauf, einschließlich etwaiger Unsicherheiten darüber, ob eine Aktion ausgeführt wurde. Ersetzen Sie fehlende Beweise nicht durch die Erklärung eines Modells, was es tun wollte.
Behalten Sie aus Gründen der Wiederholbarkeit die Produktversion, Konfiguration, Testeingaben und nicht geheime Ausgabereferenzen bei. Trennen Sie die Weitergabe einer begrenzten Aufgabe von einem Anspruch auf allgemeine autonome Kompetenz. Ein System, das eine Empfehlung korrekt erstellt, hat somit keine sichere Produktionsausführung nachgewiesen. Ebenso beweist ein erfolgreicher Happy-Path-Wechsel keinen Widerstand gegen veraltete Genehmigungen oder Verwirrung der Mieter.
Fiktive Diagnose: Zustimmung überlebt ein verändertes Ziel
Ein fiktiver Gutachter genehmigt eine Änderung der Einrichtungsrichtlinie für eine Domain. Vor der Ausführung ändert ein anderer autorisierter Akteur die Baseline und die Testumgebung stellt eine ähnlich benannte Ressource in einem zweiten Mandanten bereit. Bei der Bewertung wird gefragt, ob die Plattform sowohl Änderungen bemerkt als auch stoppt, anstatt die alte Genehmigung auf den neuen Staat oder das neue Ziel anzuwenden. Die richtige Schlussfolgerung hängt vom tatsächlich beobachteten Verhalten ab, nicht vom erklärten Vertrauen des Agenten.
Hier wurde kein solcher Test durchgeführt. Das Szenario enthält keine echte Domänen-, Konto- oder Produktionstool-Aktion und es handelt sich nicht um eine Behauptung bezüglich EmailAuth . Es veranschaulicht, warum die Genehmigungsqualität anhand der Beziehung zwischen dem genehmigten Diff, dem aktuellen Status und dem ausgeführten Ziel bewertet werden muss. Eine ausgefeilte Erklärung kann diese Bindung nicht ersetzen.
Melden Sie den nachgewiesenen Umfang und die verbleibenden Grenzen
Eine sinnvolle Auswertung gibt genau an, welche Aufgaben getestet wurden, welche Kontrollen eingehalten wurden und welche Fälle noch offen sind. Vermeiden Sie allgemeine Behauptungen wie „völlig autonom“, „immer sicher“ oder „keine menschliche Überprüfung“ basierend auf einem kleinen Gerätesatz. Dokumentieren Sie die verbleibenden menschlichen Verantwortlichkeiten, einschließlich Autorisierung, geschäftlichem Urteilsvermögen und Reaktion auf ungewisse Ergebnisse.
Der Katalog erfordert eine getestete Genehmigung-zu-Diff-Bindung mit Fällen mit veraltetem Zustand, falschem Mandanten und fehlgeschlagener Überprüfung. Der ursprüngliche Beweis bleibt offen. Auch die Prüfung durch menschliche Spezialisten, die Anwendbarkeit der Quelle, die Produktionswege, die Zugänglichkeit und die Freigabe durch den Eigentümer bleiben offen. Dieser Entwurf liefert einen Akzeptanzentwurf und eine fiktive Übung, nicht die gemessene Leistung des Agenten oder die Erlaubnis zu irreversiblem Handeln.