Erstatt etiketten med en avgrenset oppgave
En plattform beskrevet som agent kan foreslå endringer, utføre arbeidsflyter eller koordinere verktøy, men etiketten fastslår ikke hva den trygt kan gjøre. En evaluering bør begynne med en konkret oppgave, dens tillatte omfang, godkjenningen som kreves og bevis for fullføring. En overbevisende samtale eller demonstrasjon er ikke et bevis på at systemet binder en godkjenning til den eksakte leietakeren og konfigurasjonsendringen anmelderen hadde til hensikt.
Denne artikkelen foreslår defensive akseptkriterier for en autentiseringsplattform. Den hevder ikke at EmailAuth implementerer autonom kjøring, verktøyintegrasjoner eller noen godkjenningsmekanisme. Ingen agent ble koblet til produksjon, legitimasjon opprettet eller konfigurasjon endret. Offisiell dokumentasjon som er sitert her, illustrerer spesifikke kontrollmekanismer i andre systemer; plattformen under evaluering må levere sin egen støttede oppførsel og autorisert testbevis.
Definer oppgaven og dens myndighetsgrense
Spesifiser det tiltenkte resultatet i operasjonelle termer, som å utarbeide en policyanbefaling, produsere en eksakt DNS diff eller utføre en allerede godkjent endring i et isolert armaturmiljø. Separat skrivebeskyttet analyse fra skriving, publisering, tilgangsendringer og ekstern kommunikasjon. Et system som har tillatelse til å oppsummere rapporter bør ikke utlede tillatelse til å endre DNS fordi det mener endringen vil hjelpe.
Registrer leietaker, domene, ressurstype, tillatte verktøy, inndatakilder og forbudte handlinger. Ta med identiteten som ethvert verktøy vil fungere under og omfanget som identiteten faktisk har. Azures multitenant-identitetsveiledning støtter å skille identitet og ressursautorisasjon. Evalueringen bør bekrefte at plattformen ikke kan erstatte en annen leietaker bare ved å endre en forespørselsparameter eller stole på et tvetydig visningsnavn.
Bind godkjenning til nøyaktig tiltenkt diff
En nyttig godkjenning identifiserer målet, gjeldende grunnlinje, tiltenkt endring, konsekvenser og verifiseringsplan. Den bør ikke behandles som en gjenbrukbar tillatelse for senere endringer som virker like. Evaluatoren bør spørre hva systemet gjør hvis den foreslåtte diff endres etter godkjenning, hvis en annen aktør redigerer ressursen eller hvis oppgaven gjenopptas med ufullstendig kontekst. Dette er foreslåtte krav, ikke påstander om et bestemt godkjenningsprodukt.
GitHubs dokumentasjon for implementering og gjennomgang beskriver en konkret miljøvurderingsmekanisme med godkjennings- og avvisningsatferd og konfigurasjonsavhengige kontroller. Det illustrerer at godkjenningssystemer har definert omfang og begrensninger. Det beviser ikke godkjenning-til-DNS-diff-binding i en autentiseringsplattform. Krev at det evaluerte produktet viser nøyaktig hva anmelderen godkjenner og hvordan utførelse forblir knyttet til det objektet.
Oppdag foreldet tilstand i stedet for å overskrive den
En plan kan bli usikker når den underliggende konfigurasjonen endres mellom gjennomgang og utførelse. Aksepttesten bør endre oppstillingslinjen etter godkjenning og observere om systemet stopper, leser på nytt og søker en ny beslutning når det er nødvendig. En tidligere godkjent ønsket verdi gir ikke tillatelse til å forkaste en annen legitim endring i stillhet. Ta vare på grunnlinjeidentifikatoren eller sammendraget som brukes av planen og beviset sjekket umiddelbart før utførelse.
Dokumentasjon for Azure DNS poster beskriver Etags som kan oppdage samtidige endringer når de brukes i støttede oppdateringsoperasjoner. Det er en leverandørspesifikk mekanisme, ikke en universell egenskap til agentverktøy eller DNS . Den evaluerte plattformen bør identifisere sin faktiske samtidighetskontroll og atferd når en konflikt oppstår. En advarsel i et narrativt svar tilsvarer ikke å forhindre en utdatert skriving.
Verifiser resultater uavhengig av verktøysikkerhet
Et vellykket verktøysvar kan vise at en forespørsel ble akseptert uten å bevise den tiltenkte eksterne tilstanden. Definer kontrollene etter endringen som trengs for oppgaven og kilden til disse observasjonene. For en DNS-relatert armatur kan det innebære støttede autoritative og rekursive observasjoner med nøyaktige navn, typer og tider. For en rapportarbeidsflyt kan det innebære beholdt utdataomfang og opprinnelse. Denne artikkelen utfører ingen av typene kontroller.
Plattformen bør rapportere delvis feil og usikkerhet ærlig. Hvis verifiseringen mislykkes, bør ikke oppgaven merkes som fullført bare fordi skrivingen returnerte suksess. Gjenoppretting krever en støttet plan og nødvendig autoritet; det bør ikke automatisk innføre ytterligere endringer eller ekstern kommunikasjon utenfor det godkjente omfanget. Behold forskjellen mellom forsøkte, aksepterte, bekreftede og uløste handlinger i evalueringsposten.
Test feil-leietaker og tvetydig-mål-atferd
Bruk minst to syntetiske leietakere med lignende etiketter, men distinkte stabile identifikatorer og ressurser. Be evaluatoren bekrefte at en godkjent handling for den ene ikke kan brukes på den andre. Inkluder et tilfelle der det menneskelesbare domenet eller kundenavnet er tvetydig, og et tilfelle der et verktøy returnerer en ressurs utenfor det godkjente omfanget. Det sikre forventede resultatet bør spesifiseres før testen, ikke rasjonaliseres etter å ha observert systemets oppførsel.
Ikke kjør disse testene mot en annen kundes data eller et produksjonsmiljø uten eksplisitt autorisasjon. Kampene skal ikke inneholde noen levende hemmeligheter eller følgedestinasjoner. En skrivebeskyttet oppgave kan fortsatt avsløre data hvis leietakerbinding er feil, så testplanen må dekke lesing så vel som skriving. Dette manuskriptet gir foreslåtte tilfeller, ikke resultater fra en ekte agentevaluering.
Et arbeidsark med observerbar oppgave
Lag et regneark med oppgavedefinisjon, tillatt omfang, festeleie, startstatus, foreslått diff, godkjenningsreferanse, utførelsesidentitet, verktøykall tillatt og verifikasjonskriterier. Legg til forventet oppførsel for gammel tilstand, feil leietaker, nektet handling, delvis feil og mislykket verifisering. Registrer faktiske observasjoner bare etter en autorisert kjøring, inkludert eventuell usikkerhet om hvorvidt en handling ble utført. Ikke erstatt manglende bevis med en modells forklaring på hva den hadde til hensikt å gjøre.
For repeterbarhet, behold produktversjonen, konfigurasjonen, testinngangene og ikke-hemmelige utgangsreferanser. Skille en pass på en avgrenset oppgave fra et krav om generell autonom kompetanse. Et system som korrekt utarbeider en anbefaling har dermed ikke vist sikker produksjonsutførelse. På samme måte beviser ikke en vellykket endring av lykkelig vei motstand mot foreldede godkjenninger eller leietakerforvirring.
Fiktiv diagnose: godkjenning overlever et endret mål
En fiktiv evaluator godkjenner en endring av programpolitikken for ett domene. Før utførelse endrer en annen autorisert aktør grunnlinjen, og testselen leverer en lignende navngitt ressurs i en andre leietaker. Evalueringen spør om plattformen merker både endringer og stopper i stedet for å bruke den gamle godkjenningen på den nye staten eller målet. Den riktige konklusjonen avhenger av faktisk observert atferd, ikke på agentens uttalte tillit.
Ingen slik test ble kjørt her. Scenarioet inneholder ingen reell domene-, konto- eller produksjonsverktøyhandling, og det er ikke en påstand om EmailAuth . Den illustrerer hvorfor godkjenningskvaliteten må evalueres gjennom forholdet mellom godkjent diff, nåværende tilstand og utført mål. En polert forklaring kan ikke erstatte den bindingen.
Rapporter det demonstrerte omfanget og gjenværende grenser
En nyttig evaluering angir nøyaktig hvilke oppgaver som ble testet, hvilke kontroller som ble observert og hvilke saker som forblir åpne. Unngå brede påstander som fullstendig autonom, alltid trygg eller eliminerer menneskelig vurdering basert på et lite armatursett. Dokumenter det menneskelige ansvaret som gjenstår, inkludert autorisasjon, forretningsmessig vurdering og respons på usikre utfall.
Katalogen krever testet godkjenning-til-forskjell-binding med tilfeller av foreldet tilstand, feil leietaker og mislykket verifisering. Det originale beviset forblir åpent. Gjennomgang av menneskelig spesialist, kildeanvendbarhet, produksjonsruter, tilgjengelighet og eierfrigivelse forblir også åpne. Dette utkastet gir et akseptdesign og fiktiv øvelse, ikke målt agentytelse eller tillatelse til irreversibel handling.