AI in productie: server, identity,
secrets en gates
De eerste vijf stappen maakten de agent reproduceerbaar, persistent en zichtbaar. Met stap 6 verschuift de context: van een developer die de agent opstart, naar een server die hem automatisch start. Van ‘iemand kijkt mee’ naar ‘niemand kijkt mee’. Dat vraagt om vier aanvullende lagen die gezamenlijk bepalen of het systeem veilig kan schalen.
Zonder die lagen is een autonoom draaiende agent geen voordeel, maar een risico. De agent doet zijn werk ijverig, ook als hij vast zit in een redeneerlus, ook als hij een geambiguëerd commando letterlijk uitvoert, ook als de productiecredential die per ongeluk in de configuratie stond al door vijftien sessies is gebruikt. De vier stappen in dit artikel zijn de technische reactie op precies die risico’s.
Stap 6 · Verplaats dezelfde workspace naar een server
Het doel van stap 6 is dat dezelfde werkwijze die op de werkplek werkte nu unattended draait: gestart door een scheduler, binnen expliciete budgetten en grenzen, zonder dat er een mens bij is die bijstuurt.
Het kernidee is opzettelijk simpel. Clone dezelfde repositories op een beheerde server. De agent gebruikt exact dezelfde kennis en workflows als op de werkplek. Er komen geen nieuwe instructies, geen nieuwe tools en geen nieuwe logica bij. Wat er wel bij komt, zijn de operationele randvoorwaarden die unattended gebruik veilig maken.
Hoe een run er uitziet:
De stappen zelf zijn dezelfde als bij een handmatige sessie. Het verschil zit volledig in de randvoorwaarden eromheen.
Operationele randvoorwaarden (niet optioneel):
- Eén run-ID en volledige audittrail per uitvoering. Elke logregel, commit en statusupdate is herleidbaar tot één run. Zonder dit is een incident onmogelijk te reconstrueren.
- Locking en idempotency. Twee gelijktijdige runs mogen nooit dezelfde taak verwerken. Een herstartte run mag geen dubbel werk opleveren. Implementeer dit in de taskboard-integratie, niet als commentaar in de code.
- Budgetten. Maximale tijd, tokens, taken en parallelle workers per run zijn harde limieten. Zonder budget is één vastgelopen redeneerlus een rekening van honderden euro’s.
- Heartbeat, timeout, retrybeleid en dead-letter queue. Een run die vastloopt wordt gedetecteerd, beëindigd en zichtbaar geparkeerd. Niet stilzwijgend afgebroken.
- Schone, geïsoleerde werkomgeving per run. Geen restanten van een vorige run in de werkdirectory, de tussenbestanden of de omgevingsvariabelen.
- Menselijke escalatie bij ambiguïteit, conflict of risico. Een agent die twijfelt en stopt is beter dan een agent die gokt en doorgaat. Escaleren is gewenst gedrag, geen fout.
Een crashend duplicaatproces schrijft een keurig startuplog; de scheduler meldt succes terwijl er niets draait. Controleer het werkelijke effect: draait het proces, luistert de poort, is de taak geclaimd in het taskboard. Nooit alleen op logaanwezigheid. Een log die zegt “gestart” bewijst precies één ding: het startcommando is aangeroepen.
Een week lang unattended runs zonder incident. Geen dubbele verwerking, geen budgetoverschrijding, elke run herleidbaar tot één run-ID, en minstens één ambigue taak netjes geëscaleerd in plaats van gegokt.
Stap 7 · Identity via een IdP
Het doel van stap 7 is dat elke aanvraag, menselijk of van een agent-workload, een bewezen identiteit heeft, en dat autorisatie steunt op rollen in plaats van op vertrouwen.
Koppel aan Microsoft Entra ID, Active Directory, Okta, Keycloak of vergelijkbaar. De IdP bewijst wie of welke workload een aanvraag doet. De gate beslist vervolgens of die actie op dit moment voor deze identiteit is toegestaan. Die twee verantwoordelijkheden blijven strikt gescheiden.
Hoe identiteit en autorisatie door de keten lopen:
Aanbevolen inrichting:
- Aparte workload identities en service principals per agent. Nooit gedeelde menselijke accounts. Zonder eigen identiteit per agent is de audittrail waardeloos: je weet niet wie wat deed.
- Map AD-groepen op rollen. Developer, Reviewer, Release Approver, Security Admin. Bevoegdheden volgen de rol, niet het individu. Iemand die de organisatie verlaat verliest automatisch alle rollen.
- MFA en conditional access voor menselijke goedkeuringen. Een approval is een waardevolle handeling en verdient een sterke authenticatie.
- Agents kunnen geen groepslidmaatschappen of gatebeleid wijzigen. Wie de regels kan aanpassen heeft geen regels. Dit is een harde architecturele grens, geen beleidslijn.
- Separation of duties. De maker van een wijziging en de goedkeurder voor productie zijn nooit dezelfde identiteit. Technisch afdwingen, niet organisatorisch afspreken.
- Log per beslissing. Actor, workload, taak, policyversie, beslissing, tijdstip en resultaat. Niet als steekproef, maar voor elke privileged aanvraag.
Active Directory regelt identiteit en groepslidmaatschap. De externe policy-engine of gateway blijft verantwoordelijk voor contextuele autorisatie per taak en actie. De IdP zegt wie je bent. De gate zegt wat je nu mag. Die twee lagen nooit samenvoegen: de AD-beheerder mag niet ook de gate-configuratie beheren.
Elke agent-workload heeft een eigen identiteit met minimale rollen. Het intrekken van één agent-identiteit raakt niets anders. En in het auditlog is voor elke privileged aanvraag te zien welke identiteit hem deed en op grond van welke rol.
Stap 8 · Gated secrets en credentials
Het doel van stap 8 is dat geen enkel secret in code, prompt of log staat, en dat toegang minimaal, tijdelijk en gecontroleerd is.
Bewaar wachtwoorden, API-keys en certificaten in een secrets manager: HashiCorp Vault, Azure Key Vault, AWS Secrets Manager of vergelijkbaar. De repository bevat alleen logische referenties zoals secret://prod/payment-api. De werkelijke waarde is op geen enkel moment zichtbaar buiten de secretslaag.
Er zijn drie manieren waarop een agent bij een secret kan komen. Ze verschillen sterk in lekkagerisico:
| Toegangsvorm | Wat er gebeurt | Risico | Voorkeur |
|---|---|---|---|
| Retrieve | Het secret wordt tijdelijk opgehaald en aan de agent meegegeven. De waarde is zichtbaar in de agent-context. | Hoogste lekkagerisico: prompt injection, logs, foutmeldingen kunnen de waarde bevatten. | Laatste keus |
| Inject | Het secret wordt alleen in het toolproces geïnjecteerd. Het komt niet in de prompt, de context of de algemene shellomgeving. | Beperkt: de waarde is niet zichtbaar voor de agent zelf, maar bestaat wel buiten de secretslaag. | Goed |
| Execute on behalf | De gateway voert de actie zelf uit namens de agent. De credential verlaat de secretslaag nooit. | Laagst: de agent ziet en verwerkt de credential op geen enkel moment. | Voorkeur |
Execute on behalf → Inject → Retrieve. Elke stap naar links haalt een hele klasse potentiële lekken weg. Kies altijd de meest linkse optie die technisch haalbaar is voor de betreffende integratie.
Aanvullende regels die altijd gelden:
- Least privilege. Een agent-identity krijgt alleen de secrets die hij voor zijn specifieke taken nodig heeft, niet het volledige productie-secret-pakket.
- Short-lived credentials en automatische rotatie. Een gecompromitteerde credential die over vier uur verloopt is fundamenteel anders dan een die voor altijd geldt.
- Geen secrets in logs, prompts, taskcomments of Git. Dit klinkt vanzelfsprekend; in de praktijk zijn productieincidenten vrijwel altijd terug te leiden tot één van deze vier plekken.
- Egressbeperking. De workeromgeving kan alleen bij toegestane endpoints. Een secret dat nooit de servergrens verlaat kan niet worden geëxfiltreerd via een netwerkaanroep.
- Secret scanning als vangnet, niet als primaire beveiliging. Scanning detecteert fouten achteraf. Architectuur voorkomt ze.
Veel bestaande projecten hebben een appsettings.production.json of vergelijkbaar bestand met API-keys of database-credentials in plain text. Inventariseer die vóórdat de agent er toegang toe krijgt. Een agent die de workspace leest en zulke bestanden aantreft, heeft automatisch toegang tot productiecredentials die niemand aan hem wilde geven.
Een doorzoek van alle repositories, promptlogs en taskcomments levert nul plaintext secrets op. En de agent kan zijn werk volledig doen zonder ooit een productiecredential te zien.
Stap 9 · Gate productie en risicovolle acties
Het doel van stap 9 is dat risicovolle acties technisch onmogelijk zijn zonder geldige, externe autorisatie. Ook voor een gecompromitteerde of misleide agent.
“Een tekstregel als ‘deploy nooit zonder toestemming’ is een instructie, geen beveiligingsgrens. Instructies beperken wat een goedwillende agent doet. Grenzen beperken wat elke agent kan.”
Dit onderscheid is niet filosofisch maar praktisch. Een agent kan worden misleid via prompt injection vanuit een taaktekst, een webpagina of een externe API-response. Als de enige beveiliging een instructieregel is, is die beveiliging weg zodra de agent een andere instructie krijgt. Als de beveiliging een technische gate is die buiten de agent staat, helpt prompt injection niet.
Voorbeeldpolicy per actietype:
| Actietype | Beleid | Toelichting |
|---|---|---|
| Code wijzigen | Automatisch vrij | Gaat via branch en PR; reviewbaar voor merge. |
| Tests en build | Automatisch vrij | Geïsoleerde omgeving; geen productie-impact. |
| Deploy development | Automatisch vrij | Lage risico-omgeving; snelle feedbackcyclus gewenst. |
| Deploy staging | Policyafhankelijk | Afhankelijk van of staging klantdata of gedeelde services bevat. |
| Deploy productie | Expliciete gate + bevoegde approver | Nooit automatisch; altijd een menselijke handtekening. |
| Destructieve datamigratie | Gate + aantoonbare back-up/restore-check | De back-up moet aantoonbaar aanwezig zijn, niet alleen beloofd. |
| DNS · IAM · secrets wijzigen | Zware gate; separation of duties | Wijzigingen in de beveiligingsinfrastructuur zelf vereisen de hoogste drempel. |
| Betaling · externe communicatie | Specifieke policy en audit | Elke uitgaande communicatie of financiële actie is auditeerbaar en beleidsgestuurd. |
De gate staat buiten de agent, buiten diens repository en buiten diens wijzigingsbevoegdheid. Een agent die zijn eigen gate kan aanpassen, of de configuratie ervan kan committen, heeft geen gate. Dit geldt evenzeer voor een gecompromitteerde agent: ook die kan de gate dan niet omzeilen, want de gate is architectureel buiten zijn bereik geplaatst.
Een opzettelijke test bevestigt het: geef de agent de expliciete opdracht om zonder approval naar productie te deployen. Constateer dat het technisch faalt. Niet omdat hij niet wil, maar omdat hij niet kan.
De vier iteraties samengevat
De negen stappen vormen vier opeenvolgende iteraties. Elke iteratie veronderstelt dat de vorige stevig staat. De tijdsindicaties zijn realistische doorlooptijden voor een team dat er serieus mee aan de slag gaat.
| # | Iteratie | Doorlooptijd | Wat er staat na afronding |
|---|---|---|---|
| 1 | Reproduceerbaar | 1–2 weken | Launcher, workspace-repo, AGENTS.md, projectmapping, basislogging. |
| 2 | Workflow | 2–4 weken | Taskboard-integratie, branches en PR’s, CI, review- en teststatussen. |
| 3 | Automatisering | 2–4 weken | Serverworker, scheduler of queue, locking, budgetten, retries en monitoring. |
| 4 | Governance | 3–6 weken | IdP en AD, workload identities, secrets gateway, action gates, approvals, audit en rollback. |
De totale doorlooptijd varieert sterk per team en omgeving, maar wie de volgorde respecteert bouwt op wat daadwerkelijk werkt. Elke iteratie levert al waarde op voordat de volgende begint.
“Wie de bouwvolgorde respecteert, komt geen van de zeven veelgemaakte fouten tegen. Wie hem overslaat, merkt dat niet meteen · maar merkt het wel.”
