Een beveiligingsgerichte levenscyclus voor LLM-systemen: van governance naar technische implementatie

Governance-frameworks voor AI praten over risiconiveaus, maar laten de technische implementatie vaak impliciet. Dat werkt niet voor LLM-systemen. Een nieuw paper uit de arXiv biedt een security-oriented lifecycle-model dat die kloof overbrugt. En dat is precies wat we nodig hebben om NIS2, de Cyberbeveiligingswet en de AI Act werkbaar te maken.

Van governance naar techniek

De afgelopen jaren zag ik organisaties worstelen met AI-governance. Ze hebben een risicoclassificatie, een ethische commissie, en een mooi document. Maar als ik vraag: "Hoe ondertekenen jullie model artifacts?" of "Wat gebeurt er met trainingsdata na decommissioning?", dan wordt het stil.

Bestaande frameworks zoals NIST AI RMF of de AI Act definiëren risiconiveaus, maar geven geen concrete lifecycle-stappen. Het paper A Security-Oriented Lifecycle Model for Large Language Model Systems arXiv:2608.03626 vult dat gat. Het beschrijft vier fasen: data provenance, artifact signing, agentic permission control en decommissioning. Elke fase bevat technische controles die je direct kunt implementeren.

Data provenance: waar komt je trainingsdata vandaan?

Zonder herleidbare herkomst van trainingsdata kun je geen uitspraken doen over bias, copyright of beveiliging. Het model stelt voor om elke dataset te voorzien van een signed provenance manifest. Denk aan SLSA (Supply-chain Levels for Software Artifacts), maar dan voor data.

Concreet:

• Gebruik een tool als in-toto om de herkomst van elke trainingsbatch vast te leggen.
• Onderteken het manifest met een hardware security module (HSM) of een cloud-KMS.
• Sla het manifest op in een immutable log, bijvoorbeeld op basis van Rekor (Sigstore).

Voor de Nederlandse overheid is dit direct relevant. BIO2 vereist dat je de integriteit en herkomst van gegevens kunt aantonen. Zonder provenance voldoe je simpelweg niet aan de Baseline Informatiebeveiliging Overheid.

Artifact signing: wie heeft het model ondertekend?

Een LLM is een artifact, een binair bestand van tientallen gigabytes. Wie heeft het gebouwd? Wie heeft het getest? Is het onveranderd sinds de laatste audit? Het lifecycle-model eist dat elk model artifact cryptografisch wordt ondertekend.

Praktijkvoorbeeld:

cosign sign --key cosign.key --tlog-url https://rekor.sigstore.dev model.bin

Met cosign (v2.0+) onderteken je het model en publiceer je de signature in een transparency log. Bij deployment controleer je de signature:

cosign verify --key cosign.pub model.bin

Dit klinkt simpel, maar in de praktijk zie ik dat organisaties modellen rechtstreeks van Hugging Face downloaden zonder enige verificatie. Dat is een groot risico, zeker als je het model inzet voor overheidsprocessen. De AI Act (Art. 9) vereist een risicobeheersingssysteem, artifact signing is een concrete invulling daarvan.

Agentic permission control: wie mag wat?

LLM's worden steeds vaker ingezet als agent: ze voeren acties uit, lezen databases, sturen e-mails. Zonder fijnmazige permissies is dat een nachtmerrie voor security. Het lifecycle-model introduceert agentic permission control, een set regels die bepaalt welke acties een LLM-agent mag uitvoeren, en onder welke voorwaarden.

Denk aan OAuth2-scopes, maar dan voor AI-agents. Of gebruik SPIFFE (Secure Production Identity Framework for Everyone) om elke agent een unieke identiteit te geven. Voorbeeldconfiguratie in Kubernetes:

apiVersion: spiffe.io/v1beta1
kind: SPIFFEID
metadata:
  name: llm-agent
spec:
  workloadSelector:
    matchLabels:
      app: llm-agent
  spiffeID: spiffe://example.nl/ai/llm-agent

Vervolgens koppel je aan die identiteit een RBAC-beleid: "mag alleen read-only queries uitvoeren op de database, en alleen tussen 08:00 en 18:00". Dit is geen rocket science, maar het wordt zelden gedaan. En dat terwijl de Nederlandse overheid met BIO2 en NIS2 expliciet vraagt om deze controle.