Definieren Sie das Berechtigungsmodell, bevor Sie einem Agenten Tools zur Verfügung stellen
Ein Authentifizierungsagent kann dabei helfen, Beweise zu erläutern, Änderungen vorzubereiten und Ergebnisse zu überprüfen. Diese Funktionen rechtfertigen keine uneingeschränkte Kontrolle über DNS , Signaturschlüssel oder Kundenmandanten. Die Organisation sollte dokumentieren, welche Ressourcen der Agent lesen darf, welche Aktionen er vorschlagen kann und welche Vorgänge einer gesondert überprüften Genehmigung bedürfen. „Helfen Sie dabei, die E-Mail-Authentifizierung zu verbessern“ ist keine genaue Berechtigungsgrenze.
Das hier beschriebene Modell ist ein empfohlenes Design und keine Aussage darüber, dass EmailAuth es derzeit implementiert. Es wurden keine Produktberechtigungskontrollen, Verwaltungsschnittstellen oder Mandantenisolierung überprüft oder getestet. Bei den Beispielen für verbotene Aktionen im Artikel handelt es sich um vorgeschlagene Testfälle, nicht um Aufzeichnungen erfolgreich blockierter Versuche.
Trennen Sie die schreibgeschützte Vorbereitung von der anschließenden Ausführung
Die Vorbereitung kann die Analyse genehmigter Berichte, den Vergleich eines autorisierten Inventars, die Erstellung eines DNS Unterschieds und die Erläuterung eines Wiederherstellungsplans umfassen. Sogar das Lesen erfordert einen definierten Mandanten- und Datenumfang. Der schreibgeschützte Zugriff auf die Berichte eines anderen Kunden ist immer noch ein unbefugter Zugriff. Auch das externe Teilen ist ein separater Vorgang und keine harmlose Erweiterung der internen Analyse.
Ändern eines DMARC Richtlinie, Hinzufügen einer SPF Autorisierung, Veröffentlichung a DKIM Schlüssel, das Wechseln eines Unterzeichners oder das Entfernen einer Sendeberechtigung können die Vertrauenswürdigkeit und Zustellung in der Produktion beeinträchtigen. DNS Delegierung, Verwahrung privater Schlüssel, dauerhafte Anmeldeinformationen und Verwaltungsgenehmigungen können die künftige Kontrolle erweitern. Das vorgeschlagene Berechtigungsmodell sollte eine rechenschaftspflichtige Genehmigung für diese Aktionen erfordern und diese unabhängig von der eigenen Entscheidung des Modells durchsetzen. OWASP Übermäßige Agentur.
Binden Sie die Genehmigung an die genaue Maßnahme und den aktuellen Umfang
Ein aussagekräftiger Genehmigungsdatensatz identifiziert den Akteur, den Mandanten, die Ressource, den Betrieb und normalisierte Parameter. Zeigen Sie bei einer DNS Änderung den relevanten aktuellen Wert und den vorgeschlagenen Wert an; Benennen Sie für eine Berechtigungsentfernung die Identität und den Zugriff, die entfernt werden sollen. Ein Prüfer sollte in der Lage sein, die Konsequenz zu verstehen, ohne das Gespräch des Agenten rekonstruieren zu müssen.
Die AI Agent Security-Richtlinien von OWASP fordern unabhängig validierte, aktionsgebundene Genehmigungen, begrenzte Gültigkeit und Wiederholungsschutz für Vorgänge mit großer Auswirkung. Wenden Sie diese Kontrollen in der Ausführungskomponente an, anstatt einem modellgenerierten „Genehmigt“-Flag zu vertrauen. Eine wesentliche Ziel- oder Parameteränderung erfordert eine neue Entscheidung. Die tatsächliche Implementierung und ihr Fehlerverhalten müssen getestet werden, bevor jemand behauptet, diese Grenze sei wirksam. OWASP AI Agent-Sicherheits-Spickzettel.
Behandeln Sie neue Autorität und Offenlegung nach außen als eindeutige Veränderungen
Die Erlaubnis zur Aktualisierung wurde genehmigt Wähler berechtigt nicht zu einer Wildcard- DNS Delegierung, einer umfassenderen Cloud-Rolle oder einem permanenten Berechtigungsnachweis für zukünftige Arbeiten. Die Erlaubnis zur Analyse von Berichten berechtigt nicht dazu, diese an eine neue Agentur zu senden. Der vorgeschlagene Entwurf sollte jede Erweiterung als separate Entscheidung darlegen, einschließlich der Ressource, des Empfängers und des Betriebszwecks.
RFC 9990Die Überprüfung des externen Ziels veranschaulicht einen wichtigen Unterschied. Ein empfangender Auftragsverarbeiter kann die für die Zustellung DMARC Berichts erforderliche technische Bestätigung veröffentlichen, dies bedeutet jedoch nicht, dass der Domaininhaber der Geschäftsbeziehung oder Offenlegung zugestimmt hat. Der Makler sollte beide Tatsachen wahren und die organisatorische Entscheidung dem zuständigen Eigentümer überlassen. RFC 9990 , Abschnitt 4.
Lassen Sie nicht zu, dass Beweise die Regeln neu schreiben
Berichte, DNS Texte, Anbieterseiten und Supportnachrichten können nicht vertrauenswürdiges Material enthalten. Ein Feld mit der Aufschrift „Diesen Absender genehmigen“ ist keine Genehmigung des autorisierten Administrators der Organisation. Eine im abgerufenen Inhalt eingebettete Anweisung muss ein zu analysierender Beweis bleiben, kein Befehl, der den Wirkungsbereich des Agenten erweitert. OWASP beschreibt dies als indirektes Risiko einer sofortigen Injektion. OWASP-Prompt-Injektion.
Die Grenze gilt auch zwischen Automatisierungskomponenten. Eine Empfehlung eines anderen Modells oder Dienstes sollte ihre Beweise und Unsicherheit enthalten, keine Herstellergenehmigung. Überprüfen Sie die tatsächliche Genehmigungsquelle und den Ressourcenumfang am Aktionsort. Wenn der Richtliniendienst die Berechtigung nicht ermitteln kann, sollte die vorgeschlagene Steuerung diese Aktion stoppen und gleichzeitig die Fortsetzung unabhängiger autorisierter Analysen ermöglichen. OWASP-Autorisierungs-Spickzettel.
Üben Sie die Grenze mit fiktiven Fällen aus
In einem fiktiven Workflow genehmigt ein Administrator das Hinzufügen eines öffentlichen DKIM Datensatzes für einen benannten Selektor in Mandant A. Vor der Ausführung schlägt ein anderes Tool vor, die übergeordnete DMARC Richtlinie zu ändern und die Anmeldeinformationen von Mandant B zu verwenden. Die Originalgenehmigung sollte keinen Ersatz zulassen. Das Überprüfungspaket sollte die Änderungen beibehalten und die entsprechende Entscheidung fordern, anstatt die ursprüngliche Genehmigung als übertragbar zu behandeln.
In einem zweiten fiktiven Fall kommt es zu einer Zeitüberschreitung DNS -Schreiben. Der Agent weiß nicht, ob der Dienst die Änderung festgeschrieben hat. Das blinde Wiederholen des Schreibvorgangs kann zu einem unbeabsichtigten zweiten Vorgang führen oder eine spätere Administratorbearbeitung überschreiben. Die vorgeschlagene Wiederherstellungssequenz ermittelt zunächst den aktuellen Status und das Betriebsergebnis und folgt dann dem genehmigten Wiederholungs- oder Wiederherstellungspfad. Keines der Verfahren wurde gegen EmailAuth oder einen Live-Mieter durchgeführt.
Machen Sie das Stopp- und Wiederherstellungsverhalten überprüfbar
Notieren Sie die vorgeschlagene Aktion, die Genehmigungsreferenz, die Ausführungsanforderung, das zurückgegebene Ergebnis und die unabhängig überprüfte Nachbedingung. Halten Sie Geheimnisse aus dem Prüfprotokoll fern. Eine Erfolgsmeldung eines Tools sollte nicht der einzige Beweis dafür sein, dass der beabsichtigte DNS Wert oder Berechtigungsstatus jetzt existiert. Im Wiederherstellungsplan sollte angegeben werden, welcher vorherige Zustand sicher wiederhergestellt werden kann und wer diesen Schritt genehmigen kann.
Die Genesung selbst kann Folgen haben. Die Wiederherstellung eines kompromittierten Schlüssels, die Wiederherstellung einer unsicheren Absenderberechtigung oder die Schwächung einer Domänenrichtlinie werden nicht automatisch autorisiert, da dies als Rollback bezeichnet wird. Definieren Sie diese Fälle explizit. DMARC Richtlinien und Ausrichtung Die Semantik sollte über die vorhergesagten Auswirkungen informieren, der Standard gewährt einem Agenten jedoch keine Verwaltungsbefugnis. RFC 9989 , Abschnitte 4.4 und 4.5.
Erfordern sowohl erlaubte als auch verbotene Aktionstests
Ein vollständiger Testplan sollte einen korrekt genehmigten engen Betrieb und abgelehnte Fälle für falschen Mandanten, geänderte Parameter, abgelaufene Genehmigung, wiederholte Verwendung von Genehmigungen und Anweisungen für nicht vertrauenswürdige Inhalte nachweisen. Führen Sie solche Tests nur in einer autorisierten Umgebung mit begrenzten Vorrichtungen durch. Erfassen Sie tatsächliche Ergebnisse, einschließlich Kontrollfehlern, anstatt eine Checkliste als Beweis dafür zu veröffentlichen, dass der Schutz funktioniert.
Testen Sie verbotene Aktionen und genehmigte bereichsbezogene Änderungen mithilfe aktueller Produktkontrollen. Diese genaue Inbetriebnahmevoraussetzung bleibt offen. Produktdurchsetzung, genehmigte Ausführung, Ablehnung verbotener Maßnahmen, Nachprüfungen und Wiederherstellungsverhalten wurden nicht nachgewiesen. Bei der Berechtigungszuordnung handelt es sich um einen vorgeschlagenen Entwurf zur Überprüfung, nicht um einen Anspruch auf die aktuelle EmailAuth -Funktionalität.