Produktionsværn til AI-agenter, der faktisk holder

Produktionsværn til AI-agenter skal kunne modstå mere end en høflig prompt. En autonom coding-agent kan misforstå et target, gentage en operation, afsløre en credential i sin forklaring eller fortsætte efter et uklart svar. Produktionssikkerhed skal derfor være indbygget i den eksekverbare interface, autorisationsmodellen og audit trailen – ikke kun i instruktionerne.

Dockup kombinerer adfærdsvejledning i sin Claude Code- og Codex-skill med håndhævelse på CLI-niveau: secrets maskeres, destruktive operationer kræver --yes, fejl returnerer stabile koder, deploys kan vente på en terminal tilstand, og mutationer vises i audit loggen.

Hvorfor skal guardrails håndhæves under prompten?

En prompt er en nyttig politik, men den er ikke en sikkerhedsgrænse. Agentens kontekst kan blive afkortet, instruktioner kan være i konflikt, og en model kan vælge en forkert fortolkning. Det underliggende værktøj bør gøre usikker adfærd vanskelig eller umulig.

Overvej en anmodning om sletning. Det svage design eksponerer en kommando, der sletter med det samme, og er afhængigt af, at agenten husker at spørge. Det stærkere design afviser operationen, medmindre der er angivet et separat bekræftelsesflag.

Dockup bruger det stærkere mønster:

dockup up production/api --prune --json

Uden eksplicit bekræftelse afvises den destruktive oprydning, og JSON indeholder code:"needs_confirm". Intet fjernes. Agenten skal vise resultatet til et menneske, modtage godkendelse og derefter bevidst køre kommandoen igen:

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

Dette er defense in depth. Dockup-skillsættet instruerer agenten i at stoppe, mens CLI’en forhindrer utilsigtet eksekvering, selv hvis instruktionen overses.

Hvordan beskytter secret masking autonome agenter?

Agenter inkluderer ofte command output i deres ræsonnement eller endelige svar. Hvis en read-operation returnerer et production-token, kan secretet spredes til chat history, logs, telemetry, screenshots eller kopierede incident-noter.

En sikker konfigurationsinterface adskiller metadata om secrets fra selve secret-værdierne. Dockup returnerer nøgler til environment variables og markøren isSecret, men gemte secret-værdier er null eller maskeret.

dockup env list -s production/api --json

Agenten kan sætte et secret uden senere at hente det:

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

Secret masking fjerner ikke behovet for omhyggelig håndtering af processen. Den oprindelige værdi findes stadig i shell-miljøet under set-operationen. Undgå set -x, skriv ikke variablen ud, og byg ikke command strings, der opsamles af verbose logging.

Database passwords, API keys, registry tokens, SSH credentials og Windows RDP credentials bør behandles som engangsdata eller outputs med begrænset adgang. En agent bør gemme dem i en godkendt secret manager eller give dem direkte videre til den næste proces uden at gengive dem i prosa.

Den bredere tilgang på applikationsniveau er beskrevet i security best practices.

Hvordan bør godkendelse af destruktive handlinger fungere?

Ikke alle mutationer kræver samme ceremoniel. En nyttig autonomimodel opdeler operationer efter reversibilitet og blast radius:

Niveau	Eksempel	Agentens standardadfærd
Skrivebeskyttet	Vis services, læs status, se logs	Udfør og opsummér
Reversibel write	Sæt en variabel, udløs en deploy	Udfør inden for det godkendte scope
Operationel recovery	Genstart, kør en ældre deployment igen	Udfør, hvis runbooken tillader det; rapportér evidens
Destruktiv	Destroy service, slet database, forlad projekt	Stop og bed om eksplicit godkendelse
Omfattende destruktiv	Anvend --prune, overfør ejerskab	Kræv target-specifik menneskelig bekræftelse

Eksplicit godkendelse bør omfatte det præcise target og konsekvensen. “Ja, fortsæt” er svagere end “Slet staging/old-api og de tilknyttede serviceressourcer.” Agenten bør ikke genbruge en godkendelse, der blev givet til en anden kommando eller et andet target.

Dockup config as code er som standard additiv. dockup up fjerner ikke environment variables eller domains, der mangler i manifestet. Sletning kræver det eksplicitte --prune-flag:

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

Planen er read-only og bør gennemgås først. Selv med --prune er secrets, services, databases og volumes beskyttet mod denne manifestoprydningssti. Se dockup.yaml config as code for det fulde workflow.

Hvordan holder strukturerede fejl autonomien afgrænset?

En agent har brug for et endeligt sæt sikre grene. Friformulerede beskeder er nyttige for mennesker, men stabile fejlkoder gør den første respons deterministisk.

Kode	Korrekt respons
not_logged_in	Stop, og hent en gyldig credential
not_linked	Find targetet, eller angiv det eksplicit
no_target	Kør service discovery; opfind aldrig en slug
needs_confirm	Bed om menneskelig godkendelse
deploy_trigger_failed	Rapportér, hvorfor operationen ikke kunne starte
deploy_failed	Undersøg build logs
deploy_timeout	Rapportér, at den terminale tilstand er ukendt

En deployment bør bruge ventetid på terminal tilstand:

dockup deploy production/api --wait --json

Standard-timeout er 900 sekunder. Exit 0 beviser, at deploymenten nåede en succesfuld tilstand. En non-zero exit forhindrer agenten i at fortsætte til domain changes, migrations eller annonceringer, som om production var klar.

Dette design gennemgås i AI agent CLI design. Princippet er enkelt: Værktøjet skal gøre et uklart resultat eksplicit.

Hvad bør en audit log registrere?

Autonomi uden attribution er operationel gæld. En audit trail for production bør besvare, hvem der handlede, hvilken interface de brugte, hvilket target der blev ændret, om det var en read eller write, hvornår det skete, og om det lykkedes.

Dockup registrerer CLI-, UI- og API-handlinger. Operatører kan undersøge de seneste mutationer:

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

Agentens egen rapport bør supplere platformens registrering. Inkludér:

1. Det resolverede project/service-target.
2. Kommandoens kategori uden secret-værdier.
3. Deployment- eller ressource-ID’er, som platformen returnerede.
4. Exit-koden og den strukturerede status.
5. Evidens indsamlet efter mutationen.
6. Eventuel godkendelse til destruktivt arbejde.
7. Resterende usikkerhed eller opfølgning.

Audit logs er ikke kun til at placere skyld efter en incident. De gør det muligt for en anden agent eller menneskelig operatør at rekonstruere tilstanden uden at gentage risikable kommandoer.

Hvordan kan teams øge agentautonomien sikkert?

Start med read-adgang og én service med lav risiko. Udvid kun, når agenten demonstrerer korrekt target discovery, god secret hygiene, korrekt fejlhåndtering og rapportering.

En praktisk progression er:

Fase 1: Observer

Tillad visning af services, status, deployment history, build logs, runtime logs, uptime, usage og security scan-resultater. Sammenlign agentens opsummering med den rå JSON.

Fase 2: Deploy til et fast target

Tillad deployment af én service med --wait. Kræv et health check og en struktureret completion report. Giv ikke adgang til sletning eller team permissions.

Fase 3: Håndter reversibel konfiguration

Tillad opdateringer af non-secret- og secret-variabler, konfiguration af health checks og opsætning af custom domains under en gennemgået runbook. Kræv redeployment efter ændringer i environment.

Fase 4: Udfør recovery-handlinger

Tillad restart eller rollback, men kun når agenten vælger et præcist, kendt deployment-ID og bevarer evidens for fejlen.

Fase 5: Destruktivt arbejde med godkendelse

Behold destruktive flags bag eksplicit menneskelig godkendelse, selv når credentialen teknisk set giver adgang til dem. Brug scoped API keys, hvor det er muligt, og gennemgå audit trailen regelmæssigt.

Installation af agentens skill understøtter disse adfærdsmønstre:

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

Dockup CLI reference dokumenterer den håndhævede kommandoadfærd. Agenten bør kontrollere sit lokale schema i stedet for at stole på et eksempel, den husker.

Tjekliste til gennemgang af guardrails

Besvar hvert spørgsmål, før du giver adgang til production:

• Kan agenten finde præcise targets uden at gætte?
• Er secret-værdier maskeret i alle read-paths?
• Returnerer enhver mislykket mutation non-zero?
• Kan lange operationer vente på en terminal tilstand?
• Blokeres destruktive handlinger uden eksplicit bekræftelse?
• Er credentials scoped og leveret uden for prompts?
• Kan alle mutationer findes i en audit log?
• Findes der en testet rollback- eller recovery-procedure?
• Kan skill- og executable-versioner komme ud af sync?
• Adskiller den endelige rapport fakta fra usikkerhed?

Et “nej” er en designopgave, ikke en promptskrivningsopgave. Produktionsautonomi bør kun vokse, i takt med at de underliggende garantier vokser.

Test guardrails som failure cases

En gennemgang er ikke komplet, før teamet bevidst udløser grænserne. Kør en deploy med et ugyldigt token, anmod om et ukendt target, lad et test-build fejle, angiv en meget kort timeout, og forsøg at køre en destruktiv kommando uden bekræftelse. Hver case bør give et non-zero exit, en stabil kode, ingen lækkede secrets og ingen utilsigtet mutation.

Disse tests gør produktionsværn til AI-agenter til observerbare garantier. Gentag dem efter opdateringer af CLI eller politikker, ligesom du ville gentage authentication- og authorization-tests for en applikation. Et guardrail, der kun findes i et slide deck, beskytter ikke en unattended release.

Sæt workflowet i production

Installér skillen, gennemgå dens instruktioner, og test alle guardrails – inklusive en blokeret destruktiv kommando – før du udsteder en production-token.

npm install -g dockup-cli
dockup skill install

Den første kommando installerer CLI’en. Den anden installerer den matchende Dockup-skill til Claude Code og Codex. Kom gratis i gang på app.dockup.ai.

FAQ

Er prompt-instruktioner nok til at holde en AI-agent sikker i production?

Nej. Prompts hjælper med at styre adfærden, men kritiske kontroller som secret masking, bekræftelse, autorisation, exit-koder og audit logging skal håndhæves af værktøjet og platformen.

Hvordan blokerer Dockup destruktive operationer?

Destruktive kommandoer nægter at køre uden det eksplicitte --yes-flag og returnerer den strukturerede needs_confirm-kode, så agenten kan stoppe og spørge et menneske.

Kan en AI-agent læse secret environment-værdier fra Dockup?

Gemt secret-værdier maskeres i output. Agenten kan se nøglen og secret-markøren og kan erstatte værdien, men den modtager ikke det gemte secret.

Hvorfor er strukturerede fejlkoder vigtige for autonomi?

De begrænser agenten til kendte recovery-grene, såsom at anmode om authentication, finde det præcise target, læse build logs eller bede om bekræftelse.

Hvordan bør et team begynde at give adgang til production?

Start med read-only-operationer, tillad derefter deployment til ét target med lav risiko, og udvid først til reversibel konfiguration og recovery, når agenten konsekvent rapporterer verificerbar evidens.