AI-deploymentpatronen en beveiligingsimplicaties

Hoe API-gebaseerde, self-hosted, edge- en hybride deploymentpatronen elk hun eigen beveiligingsoverwegingen en aanvalsoppervlakken voor AI-systemen creëren.

Deployment bepaalt het aanvalsoppervlak

Hetzelfde AI-model dat op verschillende manieren gedeployd wordt, vertoont fundamenteel verschillende beveiligingsprofielen. Een model dat alleen toegankelijk is via een rate-limited API met server-side guardrails is een heel ander doelwit dan datzelfde model dat lokaal op de laptop van een gebruiker draait, zonder externe controles. Inzicht in deploymentpatronen is essentieel om red team-opdrachten af te bakenen en aanvallen te prioriteren.

Patroon 1: API-gebaseerde deployment

Het model draait op de infrastructuur van de aanbieder en is toegankelijk via een REST-API. Dit is het meest voorkomende patroon voor commerciële AI-diensten.

Architectuur

┌──────────┐     HTTPS      ┌──────────────────────────┐
│  Client  │ ──────────────→ │  API Gateway             │
│  App     │                 │  ├─ Authentication       │
│          │ ←────────────── │  ├─ Rate Limiting        │
└──────────┘                 │  ├─ Input Guardrails     │
                             │  ├─ Model Inference      │
                             │  ├─ Output Guardrails    │
                             │  └─ Logging/Monitoring   │
                             └──────────────────────────┘

Beveiligingskenmerken

Aanvalsoppervlak

• Diefstal of lekkage van API-sleutels: Sleutels ingebed in client-side code, versiebeheer of logs
• Omzeilen van rate limits: Gedistribueerde aanvragen, sleutelrotatie, endpoint-multiplexing
• Authenticatiefouten: Onvoldoende scoping van sleutels, ontbrekende sleutelrotatie, te ruime CORS
• Onderschepping van input/output: Man-in-the-middle-aanvallen als TLS niet goed is geïmplementeerd
• Prompt injection: Blijft mogelijk via de API, ongeacht server-side controles
• Side-channel-informatie: Responstiming, tokenaantallen en foutmeldingen kunnen informatie onthullen over guardrails en modelgedrag

Patroon 2: Self-hosted deployment

De organisatie draait het model op haar eigen infrastructuur (on-premises servers, private cloud of dedicated cloudinstances).

Architectuur

┌──────────┐                 ┌──────────────────────────┐
│  Client  │ ──────────────→ │  Organization's Infra    │
│  App     │                 │  ├─ Load Balancer        │
│          │ ←────────────── │  ├─ API Layer            │
└──────────┘                 │  ├─ Custom Guardrails    │
                             │  ├─ Inference Engine     │
                             │  │   (vLLM, TGI, etc.)  │
                             │  ├─ Model Weights        │
                             │  └─ Custom Monitoring    │
                             └──────────────────────────┘

Beveiligingskenmerken

Aanvalsoppervlak

Self-hosted deployments erven al het aanvalsoppervlak van API-gebaseerde deployments, plus:

• Infrastructuurkwetsbaarheden: Ongepatchte servers, verkeerd geconfigureerde netwerken, blootgestelde beheerinterfaces
• Diefstal van modelgewichten: Fysieke of netwerktoegang tot modelbestanden maakt volledige modelextractie mogelijk
• Kwetsbaarheden in eigen code: Zelfgebouwde guardrails en API-lagen kunnen beveiligingsfouten bevatten die volwassen implementaties van aanbieders niet hebben
• Kwetsbaarheden in de inference-engine: vLLM, text-generation-inference en andere serveringsframeworks kunnen hun eigen beveiligingsproblemen hebben
• Afhankelijkheidsketen: Eigen deployments leunen op veel libraries (transformers, torch, CUDA), elk een potentiële aanvalsvector
• Configuratiedrift: Zonder centraal beheer kunnen beveiligingsconfiguraties in de loop van de tijd verslechteren

Voordelen voor verdedigers

Self-hosted deployments bieden ook beveiligingsvoordelen:

• Volledige controle over data — er verlaat geen data de infrastructuur van de organisatie
• De mogelijkheid om domeinspecifieke guardrails te implementeren die aanbieders niet bieden
• Geen afhankelijkheid van de beveiligingspositie van een externe aanbieder
• De mogelijkheid om modellen in air-gapped omgevingen te draaien voor zeer gevoelige workloads

Patroon 3: Edge-deployment

Het model draait op apparaten van eindgebruikers — smartphones, laptops, IoT-apparaten of embedded systemen. Dit patroon groeit snel door de komst van efficiënte kleine modellen.

Architectuur

┌─────────────────────────────────┐
│  End-User Device                │
│  ├─ Application                 │
│  ├─ Local Inference Runtime     │
│  │   (ONNX, Core ML, llama.cpp)│
│  ├─ Model Weights (quantized)  │
│  └─ (Optional) Client-side     │
│      guardrails                 │
└─────────────────────────────────┘
         │ (optional)
         ▼
┌──────────────────────┐
│  Backend Services    │
│  (analytics, updates)│
└──────────────────────┘

Beveiligingskenmerken

Aanvalsoppervlak

Edge-deployment verandert het beveiligingsmodel fundamenteel, omdat de gebruiker de potentiële aanvaller is en de uitvoeringsomgeving beheert:

• Extractie van modelgewichten: De gewichten zijn op het apparaat opgeslagen en kunnen worden geëxtraheerd, gereverse-engineerd of aangepast
• Verwijderen van guardrails: Elke client-side veiligheidsmaatregel kan worden uitgeschakeld door de applicatie aan te passen
• Modelaanpassing: Gewichten kunnen worden gewijzigd om de veiligheids-fine-tuning te verwijderen of backdoors te injecteren
• Onbeperkte inference: Geen rate limits, geen monitoring, geen gebruiksbeperkingen zodra het model op het apparaat staat
• Aanmaken van afgeleide modellen: Geëxtraheerde gewichten kunnen worden gebruikt om fine-tuned varianten zonder veiligheidsbeperkingen te maken

Patroon 4: Hybride deployment

Hybride architecturen combineren meerdere patronen, doorgaans door edge-deployment voor eenvoudige taken en clouddeployment voor complexe taken te gebruiken.

Architectuur

┌─────────────────────┐          ┌─────────────────────┐
│  End-User Device    │          │  Cloud Backend       │
│  ├─ Small Local     │  ─────→  │  ├─ Full Model      │
│  │  Model           │  Complex │  ├─ Guardrails      │
│  ├─ Simple Tasks    │  queries │  ├─ Monitoring      │
│  └─ Routing Logic   │  ←─────  │  └─ Analytics       │
│                     │  Results │                      │
└─────────────────────┘          └─────────────────────┘

Beveiligingskenmerken

Hybride deployments combineren de aanvalsoppervlakken van zowel edge- als cloudpatronen, en introduceren bovendien extra risico's:

• Manipulatie van de routing: De routinglogica misleiden zodat gevoelige queries naar het lokale (onbewaakte) model worden gestuurd in plaats van naar het cloudmodel
• Verwarring rond vertrouwensgrenzen: Het systeem moet beslissen welk model het vertrouwt wanneer ze het oneens zijn
• Datalekkage via routing: De routingbeslissing zelf kan informatie onthullen over de gevoeligheid van een query
• Inconsistent gedrag: Gebruikers ontdekken mogelijk dat het lokale en het cloudmodel verschillend reageren op dezelfde invoer, wat het bestaan van server-side guardrails onthult

Vergelijking van deploymentpatronen

Het deploymentpatroon identificeren

Tijdens de verkenningsfase van een opdracht onthullen verschillende indicatoren het deploymentpatroon:

Gerelateerde onderwerpen

• Het AI-landschap — de bredere ecosysteemcontext voor deploymentbeslissingen
• Het AI-API-ecosysteem — diepere duik in API-gebaseerde deploymentpatronen
• Open versus gesloten modellen — hoe modelbeschikbaarheid de deploymentopties beïnvloedt
• AI-systeemarchitectuur — een blik op systeemniveau op deploymentarchitecturen

Bronnen

• "MLOps: Continuous Delivery for Machine Learning" - Google (2024) - Best practices voor het deployen en beheren van ML-systemen in productieomgevingen
• "On-Device AI: Challenges and Opportunities" - Apple ML Research (2024) - Technisch overzicht van het deployen van AI-modellen op edge-apparaten met beperkte resources
• "vLLM: Efficient Memory Management for Large Language Model Serving" - Kwon et al. (2023) - De inference-engine die aan veel self-hosted LLM-deployments ten grondslag ligt
• "Securing AI Model Deployment: A Practitioner's Guide" - OWASP (2025) - Beveiligingsoverwegingen voor elk deploymentpatroon in AI-applicaties