Kontroll- och driftagenter – observerbarhet, verktyg, MCP, hemligheter, krokar och tillförlitlighet

Slutförd

I den här lektionen får du lära dig:

  • Identifiera de bevis och artefakter som krävs för agentarbete

  • Så här styr du verktyg, MCP-integreringar och hemligheter på ett säkert sätt

  • Så här inför hooks skyddsräcken och granskningsloggning

  • Att utforma för tillförlitlighet genom återförsök, eskalering och minsta behörighet

Nödvändiga bevis och artefakter för agenter

Ett agentsystem måste skapa synliga artefakter för varje meningsfull åtgärd. Utan artefakter kan du inte på ett tillförlitligt sätt granska beteende, felsöka fel eller utföra post hoc-analys.

I GitHub uppnås observerbarhet genom artefakter som:

  • pull-begäranden och PR-tidslinjer

  • kommandon och grenhistorik

  • arbetsflödeskörningar och jobbloggar.

  • nödvändiga kontroller och skanningsresultat, och

  • uppladdade arbetsflödesartefakter (till exempel testrapporter).

Minsta observabilitetsuppsättning

En väl utformad agentuppgift bör skapa synliga, granskningsbara bevis med hjälp av GitHub ursprungliga artefakter:

  • en strukturerad plan, som vanligtvis ingår i en beskrivning eller diskussion av pull-begäranden

  • en begränsad pull-begäran och commithistorik

  • länkar för körning av arbetsflöden för nödvändiga kontroller

  • uppladdade artefakter (till exempel loggar eller rapporter)

  • granskningsresultat (godkännanden eller begärda ändringar)

Ladda upp arbetsflödesartefakter för granskning och felsökning

Uppladdning av artefakter gör bevis hållbara och granskningsbara, även när loggar rullas bort.

Vi rekommenderar bästa praxis att inkludera länkar till arbetsflödeskörningar och relevanta artefakter i PR under ett "Bevis"-avsnitt så att granskare snabbt kan verifiera resultat.

- name: Upload test results
  uses: actions/upload-artifact@v4
  with:
    name: test-results
    path: results/

Tillförlitlighet förutsätter fel

Tillförlitliga system förutsätter att fel inträffar. Agenter kommer att missförstå uppgifter, tester misslyckas och ändringar kommer att stå i konflikt med befintligt beteende. Din arkitektur bör identifiera fel tidigt och tillhandahålla säkra återställningsvägar.

Ett praktiskt tillförlitlighetsmönster omfattar:

  • Återförsök: agenten kan uppdatera grenen om kontrollerna misslyckas.

  • Eskalering: beständiga fel sammanfattas och överlämnas till en människa.

  • Återställningsberedskap: Högriskändringar inkluderar återställningsanteckningar och omfångsgränser.

Säker iterationsprincip

Använd en förutsägbar princip för iteration:

  • Om en nödvändig kontroll misslyckas kan agenten revidera PR-grenen och köra igen kontrollerna.

  • Om samma obligatoriska kontroll misslyckas två gånger eskalerar du till en mänsklig granskare med:

    • vad som misslyckades,

    • vad som försöktes,

    • vilka bevis som finns, och

    • vad det föreslagna nästa steget är.

Den här principen hjälper till att förhindra oändliga loopar och gör att fel kan åtgärdas.

Observerbarhet som en nödvändig arkitekturfunktion

En minsta observerbarhetsuppsättning för autonomt arbete bör omfatta:

  • en synlig planartefakt,

  • en PR och kommenteringshistorik

  • arbetsflödeskörningslänkar för nödvändiga kontroller,

  • hållbara artefakter (loggar/rapporter/spårningar),

  • granskningsresultat och godkännanden.

Gör bevis spårbara till exekvering och kodstatus

Lär ut en namngivnings-/metadataprincip:

  • Bevis ska kunna spåras till en specifik körning av arbetsflöde och en specifik commit.

Detta hjälper till att granska och felsöka: du kan svara "vilken körning skapade den här artefakten och mot vilket kodtillstånd?"

Dela bevis mellan jobb med artefakter

Lär ut mönstret:

  • Ladda upp artefakter där de skapas

  • Ladda ned dem där de granskas eller distribueras

Detta gör att utdata kan kontrolleras och kan användas utan att de genererade filerna sparas på lagringsplatsen igen.

Så här styr du verktyg, MCP-integreringar och hemligheter på ett säkert sätt

Konfigurationen av agentprofilen ger tre typer av kontroll:

  • Kapacitetsgräns: vilka verktyg som tillåts (föredrar tillåtna listor)
  • Synlighetsgräns: om agenten är användarvalbar i interaktivt användargränssnitt
  • Delegeringsgräns: vilka underagenter som kan anropas och hur överlämningar sker Designvägledning:
  • Använd skrivskyddade verktygssatser för planering och granskning av agenter.
  • Begränsa implementeringsverktygen till utförandeagenter.
  • Behandla ändringar i verktygslista som en styrningskänslig ändring.

MCP-servrar: utöka verktyg på ett säkert sätt

MCP-servrar utökar verktygsfunktionen. Lär ut följande mönster:

  • Transportform: vissa MCP-servrar är fjärrslutpunkter; andra är lokala processer.
  • Autentisering: token ska matas in vid körning via skyddade hemliga gränser.
  • Namnområdeskontroll: Föredra att aktivera en smal verktygsdeluppsättning i stället för breda jokertecken.

Driftvägledning:

  • Om du lägger till eller expanderar MCP-verktyg ökar du explosionsradien och bör granskas som ett högriskberoende.

Hemliga och miljörelaterade konsekvenser (förvara hemligheter utanför lagringsplatsinnehåll)

Placera inte hemligheter i:

  • instruktionsfiler,
  • bekräftade konfigurationsfiler,
  • eller YAML för arbetsflöde i ren text.

Istället:

  • Använd skyddade hemlighetsgränser som är avsedda för körningsinmatning,
  • Skicka hemligheter endast till de komponenter som behöver dem,
  • Begränsa tillgängligheten av hemligheter till specifika omfattningar (till exempel baserat på miljö) för att minska risken för exponering.

Lär ut principen:

  • "Agentens körningsmiljö har en egen hemlig gräns; anta inte att den automatiskt ärver lagringsplatsens CI-hemligheter."

Så här framtvingar hooks säkerhetsspärrar och revisionsloggning

I GitHub Copilot-agenter definieras krokar som konfigurationsfiler som lagras i förvaret (till exempel under .github/hooks/). Varje krok anger när den körs och vilken åtgärd den utför.

Hooks kör anpassade kommandon vid specifika tidpunkter under agentkörningen. På så sätt kan teamen tillämpa principer, verifiera åtgärder och samla in granskningsdata automatiskt.

Ett förenklat exempel:

{
  "name": "block-high-risk-command",
  "trigger": "pre-tool-use",
  "run": "if [[ \"$TOOL\" == \"delete\" ]]; then echo 'Blocked unsafe command'; exit 1; fi"
}

Så här fungerar detta

  • Kroken körs innan ett verktyg används (innan verktygsanvändning)

  • Inspekterar den begärda åtgärden

  • Om åtgärden matchar ett blockerat mönster stoppas körningen

Vanliga krokmönster

  • Pre-action hooks Validera eller blockera osäkra åtgärder innan de exekveras

  • Krokar efter åtgärd Loggverktygsanvändning, utdata eller beslut för granskning

  • Felkrokar Fånga upp fel och utlösa eskalering eller varningar

Vad krokar aktiverar

  • Framtvinga säkerhetsprinciper (till exempel blockera osäkra kommandon)

  • Lägga till granskningsloggar för efterlevnad och felsökning

  • Integrera med externa system (aviseringar, övervakning, godkännanden)

  • Krokar ger framtvingande kontrollpunkter som fungerar oberoende av modellens resonemang. I stället för att förlita sig på instruktioner ser de till att vissa regler alltid tillämpas under körningen.

Att utforma för tillförlitlighet genom återförsök, eskalering och minsta behörighet

Som vi talade om tidigare kommer agenter så småningom att misslyckas, men vi kan skapa system som kan fånga dessa fel och se till att mänskliga ingripanden fångar det, till exempel här är ett par sätt att se till att fel fångas:

  • Begränsade återförsök för tillfälliga fel

  • Eskaleringsvägar för upprepade fel

  • Återställningsberedskap för högriskändringar

  • Behörigheter med minimal åtkomst för att minska explosionsradien

Återställningssäkert mönster att lära ut:

  • Använd explicita referenser (commit/tagg) när du distribuerar känslig konfiguration, i stället för den senaste versionen av en gren.

Minsta behörighetspåminnelse:

  • Begränsa arbetsflödesbehörigheter som standard och höj endast vid behov.

Behörigheter för arbetsflöden med lägsta behörighet

Minsta behörighet minskar risken när något går fel. Det förhindrar också att överbehörighetsbaserad automatisering blir en sårbarhet i arkitekturen.

permissions:
  contents: read
  pull-requests: write

Den här konfigurationen gör det möjligt för automatisering att läsa lagringsplatsens innehåll och uppdatera PR-kontexten (kommentarer, statusar) samtidigt som bred skrivåtkomst förhindras som standard.