Sostituisci l'etichetta con un'attività delimitata
Una piattaforma descritta come agentica può proporre modifiche, eseguire flussi di lavoro o coordinare strumenti, ma l’etichetta non stabilisce cosa può fare in sicurezza. Una valutazione dovrebbe iniziare con un compito concreto, la sua portata consentita, l'approvazione richiesta e la prova del completamento. Una conversazione o una dimostrazione convincente non costituisce la prova che il sistema vincola un'approvazione all'esatto tenant e alla modifica di configurazione prevista dal revisore.
Questo articolo propone criteri difensivi di accettazione per una piattaforma di autenticazione. Non afferma che EmailAuth implementi esecuzione autonoma, integrazioni di strumenti o qualsiasi meccanismo di approvazione. Nessun agente è stato connesso alla produzione, le credenziali sono state create o la configurazione è stata modificata. La documentazione ufficiale qui citata illustra specifici meccanismi di controllo presenti in altri sistemi; la piattaforma sottoposta a valutazione deve fornire il proprio comportamento supportato e prove di test autorizzate.
Definire l'attività e il relativo confine di autorità
Specificare il risultato previsto in termini operativi, come preparare una raccomandazione politica, produrre un'esatta differenza DNS o eseguire una modifica già approvata in un ambiente di dispositivo isolato. Separare l'analisi di sola lettura da scritture, pubblicazioni, modifiche di accesso e comunicazioni esterne. Un sistema autorizzato a riassumere i rapporti non dovrebbe dedurre l'autorizzazione a modificare DNS perché ritiene che il cambiamento sarebbe d'aiuto.
Registra il tenant, il dominio, il tipo di risorsa, gli strumenti consentiti, le fonti di input e le azioni vietate. Includere l'identità con cui funzionerebbe qualsiasi strumento e l'ambito di applicazione effettivo di tale identità. Linee guida sull'identità multi-tenant di Azure supporta la separazione dell'identità e dell'autorizzazione delle risorse. La valutazione dovrebbe verificare che la piattaforma non possa sostituire un tenant diverso semplicemente modificando un parametro di richiesta o facendo affidamento su un nome visualizzato ambiguo.
Vincolare l'approvazione all'esatto differenziale previsto
Un'approvazione utile identifica l'obiettivo, la baseline attuale, il cambiamento previsto, le conseguenze e il piano di verifica. Non deve essere trattata come un'autorizzazione riutilizzabile per eventuali modifiche successive che sembrino simili. Il valutatore dovrebbe chiedere cosa fa il sistema se la differenza proposta cambia dopo l'approvazione, se un altro attore modifica la risorsa o se l'attività viene ripresa con un contesto incompleto. Questi sono requisiti proposti, non affermazioni su un particolare prodotto approvato.
Documentazione di revisione della distribuzione di GitHub descrive un meccanismo concreto di revisione dell'ambiente con comportamento di approvazione e rifiuto e controlli dipendenti dalla configurazione. Dimostra che i sistemi di approvazione hanno ambito e vincoli definiti. Non dimostra il legame tra approvazione e differenza DNS in una piattaforma di autenticazione. Richiedere che il prodotto valutato mostri esattamente ciò che il revisore approva e in che modo l'esecuzione rimane legata a quell'oggetto.
Rileva lo stato obsoleto anziché sovrascriverlo
Un piano può diventare pericoloso quando la configurazione sottostante cambia tra la revisione e l'esecuzione. Il test di accettazione dovrebbe modificare la linea di base dell'attrezzatura dopo l'approvazione e osservare se il sistema si ferma, rilegge e cerca una nuova decisione quando necessario. Un valore desiderato precedentemente approvato non autorizza l'eliminazione silenziosa di un'altra modifica legittima. Conservare l'identificatore di base o il digest utilizzato dal piano e le prove controllate immediatamente prima dell'esecuzione.
Documentazione sui record Azure DNS descrive gli Etag in grado di rilevare modifiche simultanee quando utilizzati nelle operazioni di aggiornamento supportate. Si tratta di un meccanismo specifico del provider, non di una proprietà universale degli strumenti di agenti o DNS . La piattaforma valutata dovrebbe identificare il suo effettivo controllo e comportamento della concorrenza quando si verifica un conflitto. Un avvertimento in una risposta narrativa non equivale a impedire una scrittura obsoleta.
Verifica i risultati indipendentemente dall'affidabilità dello strumento
Una risposta positiva dello strumento può mostrare che una richiesta è stata accettata senza dimostrare lo stato esterno previsto. Definire i controlli post-modifica necessari per l'attività e l'origine di tali osservazioni. Per un dispositivo correlato a DNS, ciò può comportare osservazioni autorevoli e ricorsive supportate con nomi, tipi e orari esatti. Per un flusso di lavoro di report, può comportare il mantenimento dell'ambito e della provenienza dell'output. Questo articolo non esegue nessuno dei due tipi di controllo.
La piattaforma dovrebbe segnalare onestamente i guasti parziali e le incertezze. Se la verifica fallisce, l'attività non dovrebbe essere etichettata come completata semplicemente perché la scrittura ha avuto esito positivo. Il recupero richiede un piano supportato e l’autorità necessaria; non dovrebbe introdurre automaticamente ulteriori modifiche o comunicazioni esterne al di fuori dell'ambito approvato. Conservare la differenza tra azioni tentate, accettate, verificate e irrisolte nel record di valutazione.
Testare il comportamento del tenant sbagliato e del target ambiguo
Utilizzare almeno due tenant sintetici con etichette simili ma identificatori e risorse stabili distinti. Chiedere al valutatore di confermare che un'azione approvata per uno non può essere applicata all'altro. Includere un caso in cui il dominio leggibile o il nome del cliente è ambiguo e un caso in cui uno strumento restituisce una risorsa al di fuori dell'ambito approvato. Il risultato atteso sicuro dovrebbe essere specificato prima del test, non razionalizzato dopo aver osservato il comportamento del sistema.
Non eseguire questi test sui dati di un altro cliente o su un ambiente di produzione senza esplicita autorizzazione. Gli incontri non dovrebbero contenere segreti vivi o destinazioni consequenziali. Un'attività di sola lettura può comunque esporre dati se l'associazione del tenant è errata, quindi il piano di test deve coprire sia le letture che le scritture. Questo manoscritto fornisce casi proposti, non risultati di una valutazione di un agente reale.
Un foglio di lavoro con attività osservabili
Crea un foglio di lavoro con la definizione dell'attività, l'ambito consentito, il locatario dell'attrezzatura, lo stato iniziale, la differenza proposta, il riferimento dell'approvazione, l'identità di esecuzione, le chiamate agli strumenti consentite e i criteri di verifica. Aggiungere il comportamento previsto per stato non aggiornato, tenant errato, azione negata, errore parziale e verifica non riuscita. Registrare le osservazioni effettive solo dopo una corsa autorizzata, inclusa qualsiasi incertezza sull'esecuzione di un'azione. Non sostituire le prove mancanti con la spiegazione del modello di ciò che intendeva fare.
Per motivi di ripetibilità, conservare la versione del prodotto, la configurazione, gli ingressi di test e i riferimenti non segreti alle uscite. Separare il superamento di un compito limitato da una rivendicazione di competenza generale autonoma. Un sistema che prepara correttamente una raccomandazione non ha quindi dimostrato un'esecuzione sicura della produzione. Allo stesso modo, un felice cambiamento di percorso non dimostra resistenza ad approvazioni obsolete o confusione da parte degli inquilini.
Diagnosi fittizia: l'approvazione sopravvive a un obiettivo modificato
Un valutatore immaginario approva una modifica alla politica di allestimento per un dominio. Prima dell'esecuzione, un altro attore autorizzato modifica la linea di base e il test cablaggio fornisce una risorsa con nome simile in un secondo tenant. La valutazione chiede se la piattaforma nota sia i cambiamenti che gli arresti piuttosto che applicare la vecchia approvazione al nuovo stato o obiettivo. La conclusione corretta dipende dal comportamento effettivamente osservato, non dalla fiducia dichiarata dall'agente.
Nessun test del genere è stato eseguito qui. Lo scenario non contiene alcuna azione reale su dominio, account o strumento di produzione e non è un'accusa su EmailAuth . Illustra perché la qualità dell'approvazione deve essere valutata attraverso la relazione tra la differenza approvata, lo stato attuale e l'obiettivo eseguito. Una spiegazione lucida non può sostituire quel legame.
Riportare l'ambito dimostrato e i limiti rimanenti
Una valutazione utile indica esattamente quali compiti sono stati testati, quali controlli sono stati osservati e quali casi rimangono aperti. Evita affermazioni generiche come completamente autonomo, sempre sicuro o che elimina la revisione umana basata su un set di dispositivi di piccole dimensioni. Documentare le responsabilità umane che rimangono, comprese l'autorizzazione, il giudizio aziendale e la risposta a risultati incerti.
Il catalogo richiede un'associazione testata tra approvazione e differenza con casi di stato obsoleto, tenant errato e verifica non riuscita. Quella prova originale rimane aperta. Rimangono aperti anche la revisione da parte di specialisti umani, l’applicabilità della fonte, i percorsi di produzione, l’accessibilità e il rilascio del proprietario. Questa bozza fornisce un progetto di accettazione e un esercizio fittizio, non la prestazione misurata dell'agente o il permesso per un'azione irreversibile.