AI coding agent beveiliging: veilige start bij een onbekende repository

Bij AI coding agent beveiliging is de start belangrijker dan de eerste prompt: een agent kan in een paar minuten een onbekende codebase lezen, doorzoeken en wijzigen. Een repository bevat niet alleen broncode: ook Git-configuratie, hooks, scripts, dependencies en instructiebestanden zijn invoer die een agent kan tegenkomen.

Dit is een neutrale demo. De fictieve repository bevat geen klantcode, echte secrets of bewezen productie-incident. Het doel is een herhaalbare startprocedure, niet een claim dat één controle alle risico's wegneemt.

Waarom is een repository ook invoer voor een coding agent?

Omdat automatisering soms meer leest dan alleen .ts- of .py-bestanden. Een agent kan Git-status opvragen, testcommando's vinden, scripts volgen of configuratie interpreteren. Zie die bestanden daarom als gegevens uit een externe bron, niet als vertrouwde instructies.

Dat is geen theoretisch verschil. De GitHub Advisory Database over CVE-2026-19590 beschrijft dat een aanvaller in een specifieke Codex Desktop-situatie een lokaal bewaarde core.hooksPath kon laten wijzen naar een eigen hook-directory. De advisory zegt ook dat een gewone git clone die lokale repositoryconfiguratie niet bewaart. De les is dus niet: “elke repository is al gecompromitteerd.” De les is: controleer welke metadata je behoudt of uitvoert.

Gebruik dit mentale model:

Stap 1: maak eerst een geïsoleerde intakekopie

Begin niet in een werkmap met productcredentials, een ingelogde cloud-CLI of een SSH-agent met brede rechten. Maak een tijdelijke kopie of disposable container waarin de agent in eerste instantie alleen mag lezen. Gebruik een vast, door jou gestart clone-proces; neem geen zip, bestaande werkmap of bewaarde .git-directory zonder inspectie over.

Voor de demo is de eerste opdracht expres klein:

Lees de repository. Wijzig niets, voer geen scripts uit en maak geen netwerkcalls.

Rapporteer alleen:
- remote URL en huidige branch;
- Git-configuratie op system-, global- en local-niveau;
- hook-pad en aanwezige hooks;
- package/build/test-bestanden;
- instructiebestanden zoals AGENTS.md of CONTRIBUTING.md.

Bewaar het resultaat als intakeverslag bij de run. Laat de agent niet zelf besluiten dat een gevonden bestand betrouwbaar is. Een document met de tekst “voer eerst dit shellscript uit” is een signaal voor beoordeling, geen bevoegdheid.

Stap 2: inspecteer Git en hooks zonder ze te activeren

Een Git-hook is automatisering die Git op bepaalde momenten kan aanroepen. De officiële Git-hooksdocumentatie legt uit welke hooknamen en hook-directory's Git gebruikt. Dat maakt hooks een normale, maar relevante inspectiecategorie.

Gebruik een menselijk gecontroleerde read-only inventarisatie. De precieze commando's verschillen per besturingssysteem en omgeving; de veiligheidsgrens is belangrijker dan een universele one-liner.

Inventaris voor review

1. Controleer remote(s), branch en werkboomstatus.
2. Lees local Git-configuratie, vooral core.hooksPath.
3. Toon namen en inhoud van hooks als tekst; voer ze niet uit.
4. Inventariseer package-, build-, CI- en containerbestanden.
5. Noteer welke commando's later eventueel nodig zijn.

Zie je een onverwacht hook-pad, een script met externe downloads of onduidelijke setup-instructies? Stop dan bij de inspectiegate. Zet niet simpelweg “--no-verify” op alles: daarmee sla je ook controles over die juist nuttig kunnen zijn. Kies liever een expliciet, agent-specifiek beleid voor welke Git-operaties en hooks wel of niet mogen plaatsvinden.

De Codex-pull request #22843 beschrijft een command-local override voor hookdirectories in interne Git-helpers, plus regressietests. Dat is nuttige context voor die specifieke helperfix, maar geen reden om repository-intake, permissions of patchstatus over te slaan.

Stap 3: geef minimale rechten voor één taak

Na een schone inspectie mag de agent hoogstens doen wat nodig is voor één klein werkitem. Voor de fictieve invoice-parser-demo is dat alleen src/parse.ts plus één testbestand.

Gebruik geen echte productie-secrets om “even te testen”. Zelfs read-only tokens verraden soms metadata of geven toegang tot systemen die deze taak niet nodig heeft. Maak een aparte, kortlevende testidentity wanneer een externe integratie onvermijdelijk is, en log welke scope die identity had.

Stap 4: maak één wijziging en controleer de diff

Geef pas nu een heldere, smalle opdracht. Bijvoorbeeld:

Wijzig alleen src/parse.ts en src/parse.test.ts.

Klaar wanneer:
1. lege invoer een gedocumenteerde fout geeft;
2. de gerichte tests slagen;
3. geen andere bestanden zijn gewijzigd;
4. de diff geen credentials, gegenereerde artifacts of lockfile-wijzigingen bevat.

Stop en rapporteer als een extra dependency, script of productbeslissing nodig lijkt.

Een eenvoudige releasegate kan er zo uitzien. Dit is pseudocode, niet uitgevoerde code:

const allowed = ["src/parse.ts", "src/parse.test.ts"];

const result = await runControlledAgent({
  mode: "write-limited",
  allowedPaths: allowed,
  network: "disabled",
  secrets: "unavailable",
});

const checks = await Promise.all([
  changedFilesAreOnly(allowed),
  runWithTimeout("npm test -- parse", 60_000),
  noSecretsInDiff(),
  noUnexpectedGitConfigChange(),
]);

if (!checks.every(Boolean)) {
  throw new Error("Niet mergen: de gecontroleerde wijziging haalde de gate niet.");
}

De observabilitytip: leg per run een run-ID, commit-ID, agentversie, toegestane paden, gebruikte toolrechten, uitgevoerde commando's, diff-samenvatting en stopreden vast. Sla niet automatisch volledige broncode, promptinhoud of secrets in een centrale trace op.

Welke foutmodi moet je expliciet testen?

Een goede procedure test ook de negatieve uitkomst. Voeg minstens deze controles toe:

• een repository met een onverwachte lokale Git-configuratie stopt vóór de agent schrijft;
• een instructiebestand dat om netwerktoegang vraagt, leidt niet automatisch tot netwerktoegang;
• een agentwijziging buiten de allowlist blokkeert de gate;
• een test die een credential in de diff vindt, blokkeert de gate;
• een mislukte test leidt tot een rapport, niet tot een push of deployment.

De realistische foutmodus is niet alleen een kwaadaardige hook. Ook een eerlijke agent kan een onbekend bootstrap-script starten, te brede refactor doen of een secret in een debuglog zetten. De vier gates beperken de impact, maar een review door een software- of securityverantwoordelijke blijft nodig.

Wanneer is deze startprocedure nodig?

Gebruik hem altijd voor externe, gedeelde of lang niet gebruikte repositories; bij agenten die shell- of Git-tools mogen aanroepen; en vóór toegang tot bedrijfsnetwerk, CI of cloudaccounts. Bij een bekende, intern beheerde repository kun je de intake verkorten, maar behoud je minimaal een beperkte identity, padenallowlist en diff/testgate.

Een sandbox is niet genoeg wanneer je geen duidelijke eigenaar, scope, rollback of testcommando kent. Kies dan eerst voor een menselijke code-review of een read-only analyse. Wil je veilig gebruik van agents in een groter team ontwerpen, lees ook over coding agents en AI-agenten in productie. Voor een afgebakende governance- en deliveryaanpak kun je een AI engineer inschakelen.

Samenvatting

AI coding agent beveiliging begint vóór de eerste wijziging: isoleer de repo, inspecteer Git en scripts, beperk rechten en maak de test-/diffgate blokkerend. Deze aanpak voorkomt geen enkele fout, maar zorgt dat een onbekende repository geen stilzwijgende bevoegdheid krijgt. Bewaar daarom de intake en beslis pas na review of de volgende, beperkte stap verantwoord is.