Begrens agentens fullmakter

Beskriv oppgaven før tilgang gis

En agent som leser kode, trenger andre fullmakter enn en agent som ruller ut en tjeneste. Ikke gi begge tillatelsesett fordi samme produkt støtter begge handlingene.

Bruk tre deler for å definere fullmakt: handling, ressurs og betingelse. For en fiktiv rapportrettelse kan agenten skrive til én featurebranch mens oppgaven er aktiv. Den kan lese godkjente repositoryfiler. Den kan ikke endre produksjonsdata eller repositoryets beskyttelsesregler.

Den nøyaktige håndhevingen avhenger av verktøyet. Hvis et token ikke kan uttrykke en branchbegrensning, bruk flere repositorykontroller eller en utførelsestjeneste. Dokumenter gjenværende fullmakter ærlig.

Håndhev grensen utenfor modellen

En prompt er ikke et tilgangskontrollsystem. Utførelseskomponenten må kontrollere ønsket handling og mål mot gjeldende tillatelser. Den må ikke godta modellens påstand om at godkjenning allerede finnes.

AWS anbefaler begrensede tillatelser og midlertidige påloggingsopplysninger for egnede workloads. OWASP bruker tilsvarende prinsipper om minste privilegium for agenter og verktøyene deres. Prinsippene må implementeres i de faktiske identitets- og utførelsessystemene. AWS IAM-veiledning, OWASP-agentveiledning.

Bruk kortlivede påloggingsopplysninger der det støttes. Hold uvedkommende hemmeligheter ute av miljøet. En repositoryoppgave med bare lesetilgang bør ikke arve et produksjonsdatabasepassord fra utviklerens shell.

Knytt godkjenning til den faktiske handlingen

Godkjenning til å forberede en endring innebærer ikke godkjenning til å rulle den ut. En utrullingsbeslutning bør identifisere artefakt, målmiljø og relevante betingelser. Hvis disse endres, gjelder kanskje ikke den tidligere beslutningen.

Se for deg en agent som foreslår en trygg databaselesing og deretter kjører en annen spørring etter godkjenning. En nyttig godkjenningsmekanisme kontrollerer operasjonen som faktisk kjøres. En generell «fortsett»-melding uten et definert mål kan skjule forskjellen.

Skill også identitet fra evne. Registrer hvilken person eller workload som startet kjøringen. Verifiser at den startende identiteten fortsatt har tillatelse når handlingen skjer. Fjerning av en persons tilgang bør ha en tydelig virkning på arbeid i kø.

Test avslag og avbrudd

Verifiser mer enn det vellykkede forløpet. Forsøk i et isolert testmiljø en handling utenfor den tillatte ressursen. Bekreft at utførelsessystemet avviser den. Undersøk audithendelsen uten å registrere påloggingsopplysninger.

Test deretter avbrytelse eller utløp av påloggingsopplysninger. Fastslå hvilket arbeid som stopper umiddelbart, og hvilken operasjon som kan fullføres. En stoppknapp reverserer ikke nødvendigvis en handling som allerede har nådd et annet system.

Bevar en liten tillatelsesregistrering sammen med oppgaven. Ta med ansvarlig, godkjent omfang, faktiske kontroller, avslagstest og utløp. Det gjør en senere gjennomgang konkret nok til å forbedre arbeidsflyten.