JournalindeksDockup / feltnotat
Note / production-guardrails-for-ai-agents

Sikkerhetsbarrierer for AI-agenter i produksjon som faktisk holder

Sikkerhetsbarrierer for AI-agenter i produksjon som beskytter secrets, krever bekreftelser, fører audit-logger og begrenser tilgang for trygg autonom utrulling.

Sikkerhetsbarrierer for AI-agenter i produksjon må tåle mer enn en høflig prompt. En autonom coding-agent kan misforstå et mål, prøve en operasjon på nytt, eksponere en credential i forklaringen sin eller fortsette etter et tvetydig svar. Sikkerhet i produksjon må derfor være innebygd i det kjørbare grensesnittet, autorisasjonsmodellen og audit-sporet – ikke bare i instruksjonene.

Dockup kombinerer atferdsveiledning i Claude Code- og Codex-skillen sin med håndheving på CLI-nivå: secrets maskeres, destruktive operasjoner krever --yes, feil returnerer stabile koder, deployer kan vente på en terminaltilstand, og mutasjoner vises i audit-loggen.

Hvorfor må sikkerhetsbarrierer håndheves under prompt-nivået?

En prompt er nyttig som policy, men den er ikke en sikkerhetsgrense. Agentkontekst kan bli trunkert, instruksjoner kan komme i konflikt, og en modell kan velge en feil tolkning. Det underliggende verktøyet bør gjøre utrygg atferd vanskelig eller umulig.

Tenk på en forespørsel om sletting. I en svak utforming finnes det en kommando som sletter umiddelbart, og man stoler på at agenten husker å spørre først. I en sterkere utforming avviser verktøyet operasjonen med mindre en separat bekreftelsesflag er til stede.

Dockup bruker det sterkere mønsteret:

dockup up production/api --prune --json

Uten eksplisitt bekreftelse avvises den destruktive oppryddingen, og JSON-svaret inkluderer code:"needs_confirm". Ingenting fjernes. Agenten må vise resultatet til et menneske, motta godkjenning og deretter kjøre kommandoen på nytt med hensikt:

dockup up production/api --prune --yes --json

Dette er defense in depth. Dockup-skillen instruerer agenten om å stoppe, mens CLI-et hindrer utilsiktet kjøring selv om instruksjonen overses.

Hvordan beskytter maskering av secrets autonome agenter?

Agenter inkluderer ofte kommandoutdata i resonnementet eller sluttsvaret sitt. Hvis en leseoperasjon returnerer et production-token, kan secret-et spre seg til chathistorikk, logger, telemetri, skjermbilder eller kopierte incident-notater.

Et trygt konfigurasjonsgrensesnitt skiller metadata om secrets fra selve secret-verdiene. Dockup returnerer nøkler for environment-variabler og isSecret-markøren, men lagrede secret-verdier er null eller maskert.

dockup env list -s production/api --json

Agenten kan angi et secret uten å hente det ut senere:

dockup env set API_KEY="$API_KEY" \
  --secret \
  -s production/api \
  --json

Maskering av secrets fjerner ikke behovet for forsiktig prosesshåndtering. Den opprinnelige verdien finnes fortsatt i shell-miljøet under set-operasjonen. Unngå set -x, ikke skriv ut variabelen, og ikke bygg kommandostrenger som fanges opp av verbose logging.

Databasepassord, API-nøkler, registry-tokens, SSH-credentials og Windows RDP-credentials bør behandles som engangsverdier eller data som bare skal vises i begrensede situasjoner. En agent bør lagre dem i en godkjent secret manager eller overføre dem direkte til neste prosess uten å gjengi dem i tekst.

Den bredere tilnærmingen på applikasjonsnivå er beskrevet i security best practices.

Hvordan bør godkjenning av destruktive handlinger fungere?

Ikke alle mutasjoner krever samme formalitet. En nyttig autonomimodell skiller operasjoner etter hvor reversible de er og hvor stort skadeomfang de kan ha:

NivåEksempelStandardatferd for agenten
SkrivebeskyttetList tjenester, les status, vis loggerKjør og oppsummer
Reversibel skriveoperasjonAngi en variabel, utløs en deployKjør innenfor godkjent scope
Operasjonell gjenopprettingStart på nytt, kjør en eldre deploy på nyttKjør hvis runbooken tillater det; rapporter evidens
DestruktivØdelegg en tjeneste, slett en database, forlat et prosjektStopp og be om eksplisitt godkjenning
Omfattende destruktivBruk --prune, overfør eierskapKrev målspesifikk bekreftelse fra et menneske

En eksplisitt godkjenning bør inneholde det nøyaktige målet og konsekvensen. «Ja, fortsett» er svakere enn «Slett staging/old-api og de tilknyttede tjenesteressursene». Agenten bør ikke gjenbruke en godkjenning som ble gitt for en annen kommando eller et annet mål.

Dockup config as code er som standard additiv. dockup up fjerner ikke environment-variabler eller domener som mangler i manifestet. Sletting krever det eksplisitte flagget --prune:

dockup plan production/api --json
dockup up production/api --prune --json

Planen er skrivebeskyttet og bør gjennomgås først. Selv med --prune er secrets, tjenester, databaser og volumer beskyttet mot denne oppryddingsbanen for manifestet. Se dockup.yaml config as code for hele arbeidsflyten.

Hvordan holder strukturerte feil autonomien innenfor grensene?

En agent trenger et begrenset sett med trygge grener. Friformulerte meldinger er nyttige for mennesker, men stabile feilkoder gjør den første responsen deterministisk.

KodeRiktig respons
not_logged_inStopp og hent en gyldig credential
not_linkedFinn målet eller oppgi det eksplisitt
no_targetKjør tjenesteoppdagelse; finn aldri på en slug
needs_confirmBe om godkjenning fra et menneske
deploy_trigger_failedRapporter hvorfor operasjonen ikke kunne starte
deploy_failedUndersøk build-loggene
deploy_timeoutRapporter at tilstanden ikke er terminal

En deploy bør vente på en terminaltilstand:

dockup deploy production/api --wait --json

Standard timeout er 900 sekunder. Exit 0 bekrefter at deployen nådde suksess. En exit-kode som ikke er null, hindrer agenten i å fortsette med domeneendringer, migreringer eller kunngjøringer som om produksjonen var klar.

Dette designet er gjennomgått i AI agent CLI design. Prinsippet er enkelt: Verktøyet må gjøre et tvetydig resultat eksplisitt.

Hva bør en audit-logg registrere?

Autonomi uten attribusjon er operasjonell gjeld. Et audit-spor for produksjon bør svare på hvem som utførte handlingen, hvilket grensesnitt de brukte, hvilket mål som ble endret, om det var en lese- eller skriveoperasjon, når det skjedde, og om den var vellykket.

Dockup registrerer handlinger fra CLI, UI og API. Operatører kan undersøke nylige mutasjoner:

dockup audit --writes --json
dockup audit --number 30 --json
dockup audit --search domains --json

Agentens egen rapport bør supplere plattformens registrering. Ta med:

  1. Det resolved project/service-målet.
  2. Kommandokategorien, uten secret-verdier.
  3. Deployment- eller ressurs-ID-er som plattformen returnerte.
  4. Exit-koden og den strukturerte statusen.
  5. Evidens som ble samlet inn etter mutasjonen.
  6. Eventuell godkjenning som ble mottatt for destruktivt arbeid.
  7. Gjenværende usikkerhet eller oppfølging.

Audit-logger er ikke bare til for å finne syndebukker etter en incident. De gjør det mulig for en annen agent eller en menneskelig operatør å rekonstruere tilstanden uten å gjenta risikable kommandoer.

Hvordan kan team øke agentautonomien på en trygg måte?

Start med leseadgang og én tjeneste med lav risiko. Utvid først når agenten viser at den finner riktige mål, håndterer secrets forsvarlig, forgrener riktig ved feil og rapporterer godt.

En praktisk progresjon er:

Fase 1: Observer

Tillat lesing av tjenestelister, status, deploymenthistorikk, build-logger, runtime-logger, uptime, bruk og sikkerhetsskanninger. Sammenlign agentens oppsummering med den rå JSON-en.

Fase 2: Deploy til et fast mål

Tillat deployment av én tjeneste med --wait. Krev en health check og en strukturert ferdigrapport. Ikke gi tilgang til sletting eller teamtillatelser.

Fase 3: Administrer reversibel konfigurasjon

Tillat oppdateringer av ikke-sensitive og sensitive variabler, konfigurasjon av health checks og oppsett av custom domains under en gjennomgått runbook. Krev ny deployment etter endringer i environment.

Fase 4: Utfør gjenopprettingshandlinger

Tillat restart eller rollback bare når agenten velger en nøyaktig, kjent deployment-ID og beholder evidens på feil.

Fase 5: Destruktivt arbeid med godkjenning

Hold destruktive flagg bak eksplisitt godkjenning fra et menneske, selv når credentialen teknisk sett gir tilgang til dem. Bruk scoped API-nøkler der det er mulig, og gå jevnlig gjennom audit-sporet.

Agent-skillinstallasjonen forsterker denne atferden:

npm install -g dockup-cli
dockup skill install
dockup skill status --json

Dockup CLI reference dokumenterer den håndhevede kommandoatferden. Agenten bør verifisere sitt lokale schema i stedet for å stole på et eksempel den husker.

Sjekkliste for gjennomgang av sikkerhetsbarrierer

Svar på hvert spørsmål før du gir tilgang til produksjon:

  • Kan agenten finne nøyaktige mål uten å gjette?
  • Er secret-verdier maskert i alle leseoperasjoner?
  • Returnerer hver mislykkede mutasjon en exit-kode som ikke er null?
  • Kan langvarige operasjoner vente på en terminaltilstand?
  • Blokkeres destruktive handlinger uten eksplisitt bekreftelse?
  • Er credentials begrenset i scope og tilført utenfor prompts?
  • Kan hver mutasjon finnes i en audit-logg?
  • Finnes det en testet rollback- eller gjenopprettingsprosedyre?
  • Kan versjonene av skillen og det kjørbare programmet komme ut av takt?
  • Skiller sluttrapporten mellom fakta og usikkerhet?

Et «nei» er en designoppgave, ikke en oppgave med å skrive prompts. Autonomi i produksjon bør bare øke i takt med at de underliggende garantiene blir sterkere.

Test sikkerhetsbarrierene som feilsituasjoner

En gjennomgang er ikke komplett før teamet bevisst utløser grensene. Kjør en deploy med et ugyldig token, be om et ukjent mål, la et test-build feile, angi en svært kort timeout, og prøv en destruktiv kommando uten bekreftelse. Hvert tilfelle bør gi en exit-kode som ikke er null, en stabil kode, ingen lekkasje av secrets og ingen utilsiktet mutasjon.

Disse testene gjør sikkerhetsbarrierer for AI-agenter i produksjon til observerbare garantier. Gjenta dem etter oppdateringer av CLI-et eller policyen, på samme måte som du ville gjentatt tester av authentication og authorization for en applikasjon. En sikkerhetsbarriere som bare finnes i et presentasjonslysbildesett, beskytter ikke en release uten tilsyn.

Ta arbeidsflyten i bruk i produksjon

Installer skillen, undersøk instruksjonene og test alle sikkerhetsbarrierene – inkludert en blokkert destruktiv kommando – før du utsteder et production-token.

npm install -g dockup-cli
dockup skill install

Den første kommandoen installerer CLI-et. Den andre installerer den matchende Dockup-skillen for Claude Code og Codex. Kom i gang gratis på app.dockup.ai.

Vanlige spørsmål

Er prompt-instruksjoner nok til å holde en AI-agent trygg i produksjon?

Nei. Prompts bidrar til å styre atferden, men kritiske kontroller som maskering av secrets, bekreftelse, autorisasjon, exit-koder og audit-logging må håndheves av verktøyet og plattformen.

Hvordan blokkerer Dockup destruktive operasjoner?

Destruktive kommandoer nekter å kjøre uten det eksplisitte --yes-flagget og returnerer den strukturerte needs_confirm-koden, slik at agenten kan stoppe og spørre et menneske.

Kan en AI-agent lese secret-verdier fra environment i Dockup?

Lagrede secret-verdier maskeres i output. Agenten kan se nøkkelen og secret-markøren og kan erstatte verdien, men den mottar ikke det lagrede secret-et.

Hvorfor er strukturerte feilkoder viktige for autonomi?

De begrenser agenten til kjente gjenopprettingsgrener, som å be om authentication, finne det nøyaktige målet, lese build-logger eller be om bekreftelse.

Hvordan bør et team begynne å gi tilgang til produksjon?

Start med skrivebeskyttede operasjoner, tillat deretter deployment til ett mål med lav risiko, og utvid til reversibel konfigurasjon og gjenoppretting først når agenten konsekvent rapporterer verifiserbar evidens.