Definire il modello di autorizzazione prima di fornire strumenti all'agente
Un agente di autenticazione può aiutare a spiegare le prove, preparare le modifiche e verificare i risultati. Tali funzionalità non giustificano il controllo illimitato su DNS , chiavi di firma o tenant dei clienti. L'organizzazione dovrebbe documentare quali risorse l'agente può leggere, quali azioni può proporre e quali operazioni richiedono un'approvazione verificata separatamente. "Contribuisci a migliorare l'autenticazione della posta elettronica" non è un limite di autorizzazione preciso.
Il modello qui descritto è una progettazione consigliata, non una dichiarazione che EmailAuth lo implementa attualmente. Nessun controllo delle autorizzazioni del prodotto, interfacce amministrative o isolamento dei tenant è stato ispezionato o testato. Gli esempi di azioni vietate contenuti nell'articolo sono casi di test proposti, non registrazioni di tentativi bloccati con successo.
Separare la preparazione di sola lettura dall'esecuzione consequenziale
La preparazione può includere l'analisi dei report approvati, il confronto di un inventario autorizzato, la stesura di una differenza DNS e la spiegazione di un piano di ripristino. Anche la lettura ha bisogno di un inquilino e di un ambito di dati definiti; l'accesso in sola lettura ai report di un altro cliente è ancora un accesso non autorizzato. Anche la condivisione esterna è un'operazione separata, non un'estensione innocua dell'analisi interna.
Cambiare a DMARC politica, aggiungendo un SPF autorizzazione, pubblicazione a DKIM chiave, il cambio di un firmatario o la rimozione di un'autorizzazione all'invio possono alterare l'affidabilità della produzione e la consegna. La delega DNS , la custodia della chiave privata, le credenziali persistenti e le concessioni amministrative possono espandere il controllo futuro. Il modello di autorizzazione proposto dovrebbe richiedere l'approvazione responsabile per tali azioni e applicarla indipendentemente dalla decisione del modello stesso. OWASP Eccessiva agenzia.
Vincolare l'approvazione all'azione esatta e all'ambito attuale
Un record di approvazione significativo identifica l'attore, il tenant, la risorsa, l'operazione e i parametri normalizzati. Per una modifica DNS , mostra il relativo valore attuale e il valore proposto; per la rimozione di un'autorizzazione, indicare l'identità e l'accesso da rimuovere. Un revisore dovrebbe essere in grado di comprendere le conseguenze senza ricostruire la conversazione dell'agente.
Le linee guida AI Agent Security di OWASP richiedono approvazioni convalidate in modo indipendente, vincolate all'azione, validità limitata e protezione dalla riproduzione per operazioni ad alto impatto. Applicare tali controlli nel componente di esecuzione anziché fidarsi di un flag "approvato" generato dal modello. Un obiettivo materiale o una modifica di parametro richiedono una nuova decisione. L'effettiva implementazione e il suo comportamento in caso di fallimento devono essere testati prima che qualcuno affermi che questo limite è efficace. Foglio informativo sulla sicurezza dell'agente AI OWASP.
Trattare la nuova autorità e la divulgazione esterna come cambiamenti distinti
Autorizzazione ad aggiornarne uno approvato selettore non autorizza una delega DNS con caratteri jolly, un ruolo cloud più ampio o credenziali permanenti per lavori futuri. Il permesso di analizzare i rapporti non autorizza l'invio ad una nuova agenzia. Il progetto proposto dovrebbe esporre ogni espansione come una decisione separata, inclusa la risorsa, il destinatario e lo scopo operativo.
RFC 9990La verifica della destinazione esterna illustra un'importante distinzione. Un processore ricevente può pubblicare la conferma tecnica necessaria per la consegna del report DMARC , ma ciò non stabilisce che il proprietario del dominio abbia approvato il rapporto commerciale o la divulgazione. L'agente dovrebbe preservare entrambi i fatti e lasciare la decisione organizzativa al proprietario appropriato. RFC 9990 , sezione 4.
Non lasciare che le prove riscrivano le regole
Rapporti, testo DNS , pagine del provider e messaggi di supporto possono contenere materiale non attendibile. Un campo che dice "approva questo mittente" non rappresenta un'approvazione da parte dell'amministratore autorizzato dell'organizzazione. Un'istruzione incorporata nel contenuto recuperato deve rimanere una prova da analizzare, non un comando che espande l'ambito dell'agente. OWASP lo descrive come un rischio indiretto di iniezione tempestiva. OWASP Iniezione rapida.
Il confine vale anche tra i componenti di automazione. Una raccomandazione proveniente da un altro modello o servizio dovrebbe contenere prove e incertezze, non l'autorizzazione alla produzione. Verificare l'effettiva fonte di approvazione e l'ambito della risorsa al momento dell'azione. Se il servizio policy non è in grado di stabilire l'autorizzazione, il controllo proposto dovrebbe interrompere tale azione consentendo al tempo stesso di continuare l'analisi autorizzata non correlata. Foglio informativo sull'autorizzazione OWASP.
Esercita il confine con casi immaginari
In un flusso di lavoro fittizio, un amministratore approva l'aggiunta di un record DKIM pubblico per un selettore denominato nel tenant A. Prima dell'esecuzione, uno strumento diverso propone di modificare la policy DMARC principale e di utilizzare le credenziali del tenant B. L'approvazione originale non dovrebbe autorizzare nessuna delle due sostituzioni. Il pacchetto di revisione dovrebbe preservare ciò che è cambiato e richiedere la decisione appropriata piuttosto che considerare trasferibile l’approvazione iniziale.
Un secondo caso immaginario presenta un timeout di scrittura DNS . L'agente non sa se il servizio ha eseguito la modifica. La ripetizione cieca della scrittura può creare una seconda operazione involontaria o sovrascrivere una modifica successiva dell'amministratore. La sequenza di ripristino proposta stabilisce innanzitutto lo stato corrente e il risultato dell'operazione, quindi segue il nuovo tentativo o il percorso di ripristino approvato. Nessuno dei due casi è stato eseguito contro EmailAuth o qualsiasi tenant attivo.
Rendere verificabile il comportamento di arresto e ripristino
Registrare l'azione proposta, il riferimento all'approvazione, la richiesta di esecuzione, il risultato restituito e la postcondizione controllata in modo indipendente. Mantenere i segreti fuori dalla documentazione di audit. Un messaggio di successo da uno strumento non dovrebbe essere l'unica prova che il valore DNS o lo stato di autorizzazione previsti ora esistono. Il piano di ripristino dovrebbe identificare quale stato precedente può essere ripristinato in sicurezza e chi può autorizzare tale passaggio.
Il recupero stesso può essere consequenziale. Il ripristino di una chiave compromessa, il ripristino di un'autorizzazione del mittente non sicura o l'indebolimento di una policy di dominio non sono autorizzati automaticamente perché si chiamano rollback. Definire questi casi in modo esplicito. La politica di DMARC e allineamento la semantica dovrebbe informare l'impatto previsto, ma lo standard non garantisce all'agente l'autorità amministrativa. RFC 9989 , sezioni 4.4 e 4.5.
Richiedere test sia sulle azioni consentite che su quelle proibite
Un piano di test completo dovrebbe dimostrare un'operazione ristretta approvata correttamente e casi respinti per tenant errato, parametri modificati, approvazione scaduta, uso ripetuto dell'approvazione e istruzioni relative a contenuti non attendibili. Eseguire tali test solo in un ambiente autorizzato con dispositivi delimitati. Registrare i risultati effettivi, compresi i fallimenti del controllo, anziché pubblicare una lista di controllo come prova del funzionamento della protezione.
Testare le azioni vietate e le modifiche con ambito approvato utilizzando gli attuali controlli del prodotto. Questo esatto requisito per la messa in servizio rimane aperto. Non sono stati dimostrati l'applicazione del prodotto, l'esecuzione approvata, il rifiuto di azioni proibite, i controlli post-condizione e il comportamento di ripristino. La mappa delle autorizzazioni è un progetto proposto per la revisione, non una rivendicazione della funzionalità EmailAuth corrente.