Agents beheren en bedienen - waarneembaarheid, hulpprogramma's, MCP, geheimen, hooks en betrouwbaarheid

In deze les leert u het volgende:

• Ontdek het bewijs en de artefacten die vereist zijn voor agentwerk

• Hoe hulpprogramma's, MCP-integraties en gevoelige gegevens veilig te beheren

• Hoe hooks beveiligingsmaatregelen en auditlogboeken toepassen

• Ontwerpen voor betrouwbaarheid met behulp van opnieuw proberen, escalatie en minimale bevoegdheden

Vereist bewijs en artefacten voor agents

Een agentsysteem moet zichtbare artefacten produceren voor elke zinvolle actie. Zonder artefacten kunt u het gedrag niet betrouwbaar controleren, fouten opsporen of post-hocanalyses uitvoeren.

In GitHub wordt waarneembaarheid bereikt via artefacten zoals:

• tijdlijnen en pull-aanvragen voor PR's

• doorvoeringen en vertakkingsgeschiedenis,

• workflow-uitvoeringen en taaklogboeken

• vereiste controles en scanresultaten, en

• geüploade werkstroomartefacten (bijvoorbeeld testrapporten).

Minimale waarneembaarheidsset

Een goed ontworpen agenttaak moet zichtbaar, controleerbaar bewijs produceren met behulp van GitHub systeemeigen artefacten:

• een gestructureerd plan, meestal opgenomen in een beschrijving of discussie van een pull-aanvraag

• een begrensde pull request en commitgeschiedenis

• Koppelingen in de werkstroom voor vereiste validaties

• geüploade artefacten (bijvoorbeeld logboeken of rapporten)

• resultaten controleren (goedkeuringen of aangevraagde wijzigingen)

Werkstroomartefacten uploaden voor controle en foutopsporing

Het uploaden van artefacten maakt bewijs duurzaam en controleerbaar, zelfs wanneer logboeken weg scrollen.

We raden u aan om de beste praktijk te volgen door koppelingen naar workflow-runs en relevante artefacten in de pull request onder een sectie "Bewijs" op te nemen, zodat reviewers snel resultaten kunnen valideren.

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

Betrouwbaarheid gaat ervan uit dat er storingen optreden

In betrouwbare systemen wordt ervan uitgegaan dat de fout optreedt. Agents begrijpen taken verkeerd, tests mislukken en wijzigingen conflicteren met bestaand gedrag. Uw architectuur moet fouten vroegtijdig detecteren en veilige herstelpaden bieden.

Een praktisch betrouwbaarheidspatroon omvat:

• Nieuwe pogingen: de agent kan de vertakking bijwerken wanneer controles mislukken.

• Escalatie: permanente fouten worden samengevat en overgedragen aan een mens.

• Gereedheid voor terugdraaien: wijzigingen met een hoog risico omvatten terugdraainotities en bereiklimieten.

Veilig iteratiebeleid

Een voorspelbaar beleid gebruiken voor iteratie:

• Als een vereiste controle mislukt, kan de agent de PR-vertakking herzien en de controles opnieuw uitvoeren.

• Als dezelfde vereiste controle twee keer mislukt, escaleert u naar een menselijke revisor met:

  • wat is mislukt,

  • wat werd geprobeerd

  • welk bewijs bestaat, en

  • wat de voorgestelde volgende stap is.

Dit beleid helpt oneindige lussen te voorkomen en maakt fouten uitvoerbaar.

Waarneembaarheid als vereiste architectuurfunctie

Een minimale waarneembaarheidsset voor autonoom werk moet het volgende omvatten:

• een zichtbaar planartefact,

• een pull-aanvraag + doorvoergeschiedenis,

• werkstroomuitvoeringskoppelingen voor vereiste controles,

• duurzame artefacten (logboeken/rapporten/traceringen),

• resultaten en goedkeuringen bekijken.

Bewijs traceerbaar maken voor uitvoering en codestatus

Leer een naamgevings-/metagegevensprincipe:

• Bewijs moet traceerbaar zijn naar een specifieke werkstroomuitvoering en een specifieke commit.

Dit helpt bij audits en foutopsporing: u kunt beantwoorden "welke run heeft dit artefact geproduceerd, en met welke status van de code?"

Bewijs delen tussen taken met behulp van artefacten

Het patroon leren:

• Artefacten uploaden waar ze worden geproduceerd

• Download ze waar ze worden beoordeeld of geïmplementeerd

Hierdoor worden uitvoer inspecteerbaar en bruikbaar zonder gegenereerde bestanden terug te zetten naar de opslagplaats.

Hoe hulpprogramma's, MCP-integraties en gevoelige gegevens veilig te beheren

Configuratie van agentprofielen biedt drie soorten beheer:

• Mogelijkheidsgrens: welke hulpprogramma's zijn toegestaan (voorkeur voor allowlists)
• Zichtbaarheidsgrens: of de agent door de gebruiker kan worden geselecteerd in de interactieve gebruikersinterface
• Delegatiegrens: welke subagenten kunnen worden aangeroepen en hoe de overdracht plaatsvindt Ontwerprichtlijnen:
• Gebruik alleen-lezenhulpprogramma's voor het plannen en controleren van agents.
• Beperk implementatiehulpprogramma's tot uitvoerende agenten.
• Wijzigingen in toegestane lijst met hulpprogramma's behandelen als een governancegevoelige wijziging.

MCP-servers: hulpprogramma's veilig uitbreiden

MCP-servers breiden de mogelijkheid van hulpprogramma's uit. Leer deze patronen:

• Transportvorm: sommige MCP-servers zijn externe eindpunten; andere zijn lokale processen.
• Verificatie: tokens moeten tijdens runtime worden geïnjecteerd via beveiligde geheime grenzen.
• Naamruimtebeheer: voorkeur om een smalle toolsubset in te schakelen in plaats van brede jokertekens.

Operationele richtlijnen:

• Het toevoegen of uitbreiden van MCP-hulpprogramma's vergroot het impactgebied en moet worden beoordeeld als een risico met hoge afhankelijkheid.

Beperkingen voor geheimen en omgevingen (voorkom dat geheimen in de opslagplaatsinhoud terechtkomen)

Plaats geen geheimen in:

• instructiebestanden
• vastgelegde configuratiebestanden,
• of werkstroom YAML in tekst zonder opmaak.

In plaats van:

• Beveiligde geheime grenzen gebruiken die zijn bedoeld voor runtime-injectie,
• Geheimen alleen doorgeven aan de onderdelen die ze nodig hebben,
• Beperk geheime beschikbaarheid (bijvoorbeeld per omgeving) om blootstelling te verminderen.

Leer het principe:

• "De runtime-omgeving van de agent heeft een eigen geheime grens; neem niet aan dat deze automatisch CI-geheimen van de opslagplaats overneemt."

Hoe hooks beveiligingsmaatregelen en auditlogboeken toepassen

In GitHub Copilot agents worden hooks gedefinieerd als configuratiebestanden die zijn opgeslagen in de opslagplaats (bijvoorbeeld onder .github/hooks/). Elke haak geeft aan wanneer deze wordt uitgevoerd en welke actie wordt uitgevoerd.

Hooks voeren aangepaste opdrachten uit op specifieke punten tijdens de uitvoering van de agent. Hierdoor kunnen teams beleidsregels afdwingen, acties valideren en controlegegevens automatisch vastleggen.

Een vereenvoudigd voorbeeld:

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

Hoe dit werkt

• De haak draait voordat een hulpprogramma wordt uitgevoerd (voor het gebruik van het hulpprogramma)

• Het inspecteert de aangevraagde actie

• Als de actie overeenkomt met een geblokkeerd patroon, wordt de uitvoering gestopt

Algemene haakpatronen

• Pre-action hooks Onveilige acties valideren of blokkeren vóór uitvoering

• Post-action hooks Log het gebruik van hulpmiddelen, uitvoer of beslissingen voor auditing/controle.

• Fouthaken Fouten opvangen en escalatie of waarschuwingen activeren

Welke hooks zijn ingeschakeld

• Beveiligingsbeleid afdwingen (bijvoorbeeld onveilige opdrachten blokkeren)

• Auditlogboeken toevoegen voor naleving en foutopsporing

• Integreren met externe systemen (waarschuwingen, bewaking, goedkeuringen)

• Hooks bieden afdwingbare besturingspunten die onafhankelijk van de redenering van het model werken. In plaats van te vertrouwen op instructies, zorgen ze ervoor dat bepaalde regels altijd worden toegepast tijdens de uitvoering.

Ontwerpen voor betrouwbaarheid met behulp van opnieuw proberen, escalatie en minimale bevoegdheden

Zoals we eerder hebben besproken, zullen agents uiteindelijk mislukken, maar we kunnen systemen bouwen die deze fouten kunnen ondervangen en ervoor zorgen dat menselijke interventie het onderschept, bijvoorbeeld een aantal manieren om ervoor te zorgen dat fouten worden onderschept:

• Begrensde herhalingen voor tijdelijke fouten

• Escalatiepaden voor herhaalde fouten

• Gereedheid voor terugdraaien voor wijzigingen met een hoog risico

• Machtigingen met minimale bevoegdheden voor het verminderen van de straalstraal

Een rollback-veilig patroon om aan te leren:

• Gebruik expliciete verwijzingen (commit/tag) bij het implementeren van gevoelige configuraties in plaats van 'laatste op een branch'.

Herinnering voor minimale bevoegdheden:

• Werkstroommachtigingen standaard beperken en alleen indien nodig uitbreiden.

Werkstroommachtigingen met minimale bevoegdheden

Minimale bevoegdheden verminderen het risico wanneer er iets misgaat. Het voorkomt ook dat automatisering met te veel machtigingen een beveiligingsprobleem in de architectuur wordt.

permissions:
  contents: read
  pull-requests: write

Met deze configuratie kan automatisering de inhoud van de opslagplaats lezen en pr-context bijwerken (opmerkingen, statussen) en wordt de brede schrijftoegang standaard voorkomen.