Erstat etiketten med en afgrænset opgave
En platform beskrevet som agent kan foreslå ændringer, udføre arbejdsgange eller koordinere værktøjer, men etiketten fastslår ikke, hvad den sikkert kan gøre. En evaluering bør begynde med en konkret opgave, dens tilladte omfang, den påkrævede godkendelse og beviset for fuldførelse. En overbevisende samtale eller demonstration er ikke et bevis på, at systemet binder en godkendelse til den nøjagtige lejer og den konfigurationsændring, som anmelderen havde til hensigt.
Denne artikel foreslår defensive acceptkriterier for en godkendelsesplatform. Det hævder ikke, at EmailAuth implementerer autonom eksekvering, værktøjsintegrationer eller nogen godkendelsesmekanisme. Ingen agent var forbundet til produktion, legitimationsoplysninger oprettet eller konfiguration ændret. Officiel dokumentation citeret her illustrerer specifikke kontrolmekanismer i andre systemer; platformen under evaluering skal levere sin egen understøttede adfærd og autoriseret testbevis.
Definer opgaven og dens myndighedsgrænse
Angiv det tilsigtede resultat i operationelle termer, såsom at udarbejde en politikanbefaling, producere en nøjagtig DNS diff eller udføre en allerede godkendt ændring i et isoleret armaturmiljø. Adskil skrivebeskyttet analyse fra skrivninger, publicering, adgangsændringer og ekstern kommunikation. Et system, der har tilladelse til at opsummere rapporter, bør ikke udlede tilladelse til at ændre DNS fordi det mener, at ændringen vil hjælpe.
Registrer lejer, domæne, ressourcetype, tilladte værktøjer, inputkilder og forbudte handlinger. Inkluder den identitet, som ethvert værktøj vil fungere under, og det omfang, denne identitet faktisk har. Azures identitetsvejledning til flere lejere understøtter adskillelse af identitet og ressourceautorisation. Evalueringen skal verificere, at platformen ikke kan erstatte en anden lejer blot ved at ændre en anmodningsparameter eller stole på et tvetydigt visningsnavn.
Bind godkendelse til den nøjagtige påtænkte diff
En nyttig godkendelse identificerer målet, den aktuelle baseline, påtænkte ændring, konsekvenser og verifikationsplan. Det bør ikke behandles som en genbrugelig tilladelse til senere ændringer, der ligner hinanden. Evaluatoren bør spørge, hvad systemet gør, hvis den foreslåede forskel ændres efter godkendelse, hvis en anden aktør redigerer ressourcen, eller hvis opgaven genoptages med ufuldstændig kontekst. Disse er foreslåede krav, ikke påstande om et bestemt godkendelsesprodukt.
GitHubs installations-gennemgang dokumentation beskriver en konkret miljøvurderingsmekanisme med godkendelses- og afvisningsadfærd og konfigurationsafhængige kontroller. Det illustrerer, at godkendelsessystemer har defineret omfang og begrænsninger. Det beviser ikke godkendelse-til-DNS-diff-binding i en godkendelsesplatform. Kræv, at det evaluerede produkt viser præcis, hvad anmelderen godkender, og hvordan udførelsen forbliver knyttet til det pågældende objekt.
Registrer gammel tilstand i stedet for at overskrive den
En plan kan blive usikker, når den underliggende konfiguration ændres mellem gennemgang og udførelse. Godkendelsestesten skal ændre armaturets baseline efter godkendelse og observere, om systemet stopper, genlæser og søger en ny beslutning, når det er nødvendigt. En tidligere godkendt ønsket værdi giver ikke tilladelse til at kassere en anden legitim ændring. Behold basislinjeidentifikationen eller sammenfatningen, der bruges af planen, og beviserne kontrolleres umiddelbart før udførelse.
Azure DNS -registreringsdokumentation beskriver Etags, der kan registrere samtidige ændringer, når de bruges i understøttede opdateringsoperationer. Det er en udbyderspecifik mekanisme, ikke en universel egenskab for agentværktøjer eller DNS . Den evaluerede platform bør identificere sin faktiske samtidighedskontrol og adfærd, når der opstår en konflikt. En advarsel i et fortællende svar svarer ikke til at forhindre en forældet skrivning.
Bekræft resultater uafhængigt af værktøjets tillid
Et vellykket værktøjssvar kan vise, at en anmodning blev accepteret uden at bevise den tilsigtede eksterne tilstand. Definer de nødvendige kontroller efter ændring af opgaven og kilden til disse observationer. For en DNS-relateret armatur kan det involvere understøttede autoritative og rekursive observationer med nøjagtige navne, typer og tidspunkter. For et rapportworkflow kan det involvere bibeholdt outputomfang og herkomst. Denne artikel udfører ikke nogen form for kontrol.
Platformen bør rapportere delvist svigt og usikkerhed ærligt. Hvis verifikationen mislykkes, bør opgaven ikke betegnes som fuldført, blot fordi skrivningen returnerede succes. Genopretning kræver en understøttet plan og den nødvendige autoritet; den bør ikke automatisk indføre yderligere ændringer eller ekstern kommunikation uden for det godkendte anvendelsesområde. Bevar forskellen mellem forsøgte, accepterede, verificerede og uløste handlinger i evalueringsposten.
Test forkert lejer og tvetydigt mål adfærd
Brug mindst to syntetiske lejere med lignende etiketter, men forskellige stabile identifikatorer og ressourcer. Bed evaluatoren om at bekræfte, at en godkendt handling for den ene ikke kan anvendes på den anden. Medtag et tilfælde, hvor det menneskeligt læsbare domæne eller kundenavn er tvetydigt, og et tilfælde, hvor et værktøj returnerer en ressource uden for det godkendte omfang. Det sikre forventede resultat bør specificeres før testen, ikke rationaliseres efter observation af systemets adfærd.
Kør ikke disse tests mod en anden kundes data eller et produktionsmiljø uden udtrykkelig tilladelse. Kampene bør ikke indeholde levende hemmeligheder eller følgedestinationer. En skrivebeskyttet opgave kan stadig afsløre data, hvis lejerbinding er forkert, så testplanen skal dække både læsning og skrivning. Dette manuskript giver foreslåede tilfælde, ikke resultater fra en reel agentevaluering.
Et arbejdsark med observerbar opgave
Opret et regneark med opgavedefinition, tilladt omfang, opspændingslejer, starttilstand, foreslået diff, godkendelsesreference, udførelsesidentitet, tilladte værktøjskald og verifikationskriterier. Tilføj forventet adfærd for gammel tilstand, forkert lejer, afvist handling, delvis fejl og mislykket verifikation. Registrer kun faktiske observationer efter en autoriseret kørsel, inklusive enhver usikkerhed om, hvorvidt en handling blev udført. Udskift ikke manglende beviser med en models forklaring på, hvad den havde til hensigt at gøre.
For repeterbarhed skal du beholde produktversionen, konfigurationen, testinput og ikke-hemmelige outputreferencer. Adskil en videregivelse af en afgrænset opgave fra et krav om generel autonom kompetence. Et system, der korrekt udarbejder en anbefaling, har derved ikke påvist sikker produktionsudførelse. Ligeledes beviser en vellykket ændring af den lykkelige vej ikke modstand mod forældede godkendelser eller lejerforvirring.
Fiktiv diagnose: godkendelse overlever et ændret mål
En fiktiv evaluator godkender en ændring af programpolitikken for ét domæne. Inden udførelse ændrer en anden autoriseret aktør basislinjen, og testselen leverer en tilsvarende navngiven ressource i en anden lejer. Evalueringen spørger, om platformen bemærker både ændringer og stopper i stedet for at anvende den gamle godkendelse på den nye tilstand eller målet. Den korrekte konklusion afhænger af faktisk observeret adfærd, ikke af agentens erklærede tillid.
Der blev ikke kørt en sådan test her. Scenariet indeholder ingen reel domæne-, konto- eller produktionsværktøjshandling, og det er ikke en påstand om EmailAuth . Det illustrerer, hvorfor godkendelseskvaliteten skal evalueres gennem forholdet mellem den godkendte diff, nuværende tilstand og eksekverede mål. En poleret forklaring kan ikke erstatte denne binding.
Rapporter det påviste omfang og resterende grænser
En nyttig evaluering angiver præcis, hvilke opgaver der blev testet, hvilke kontroller der blev observeret, og hvilke sager der forbliver åbne. Undgå brede påstande såsom fuldstændig autonom, altid sikker eller eliminerer menneskelig gennemgang baseret på et lille armatursæt. Dokumenter det menneskelige ansvar, der er tilbage, herunder autorisation, forretningsmæssig vurdering og reaktion på usikre resultater.
Kataloget kræver testet godkendelse-til-forskel-binding med uaktuelle tilstande, forkert lejer og fejlbekræftede tilfælde. Det originale bevis forbliver åbent. Gennemgang af menneskelig specialist, kildeanvendelighed, produktionsruter, tilgængelighed og ejerfrigivelse forbliver også åbne. Dette udkast giver et acceptdesign og fiktiv øvelse, ikke målt agentpræstation eller tilladelse til irreversibel handling.