Chiffrement, isolation et zero-trust appliqués aux workloads IA

L'application des principes zero-trust (NIST SP 800-207, never trust always verify) aux workloads IA est devenu en 2026 un standard de sécurité enterprise pour les apps LLM critiques. Les approches périmétriques classiques (WAF + firewall + VPN) sont insuffisantes : un agent IA compromis par prompt injection opère depuis l'intérieur, un confused deputy détourne des privilèges légitimes, un modèle weights stocké en clair fuite au premier compromis. Cet article documente les 3 piliers techniques : chiffrement (KMS/HSM, Confidential Computing TDX/SEV-SNP/H100 TEE, quantum-safe), isolation (NetworkPolicies, micro-segmentation eBPF Cilium, GPU isolation MIG), workload identity (SPIFFE/SPIRE, mTLS, OAuth on-behalf-of). Avec 5 piliers CISA Zero Trust Maturity Model adaptés (Identity, Devices, Networks, Apps & Workloads, Data + AI Models en bonus), grille d'audit, patterns d'implémentation. Cible : architectes sécurité / SRE / RSSI structurant la sécurité workloads IA, équipes plateforme migrant vers zero-trust, auditeurs vérifiant la posture sécurité.

Pour l'architecture on-premise associée : architecture sécurisée pour déployer un LLM on-premise. Pour le threat model qui guide ces choix : threat modeling LLM avec STRIDE adapté.

Pourquoi zero-trust pour workloads IA

Limites des approches périmétriques

[Modèle traditionnel]
┌───────────────────────────────┐
│   Périmètre corporate          │
│  ┌─────────────────────────┐   │
│  │ Tout ce qui est ici     │   │  ← problème :
│  │ est trusted             │   │     une fois "dedans",
│  │                         │   │     plus de contrôle
│  │  [App] [LLM] [Tools]    │   │
│  │  [Vector] [Memory]      │   │
│  └─────────────────────────┘   │
│   ↑ WAF / Firewall / VPN       │
└───────────────────────────────┘
        ↑
   Internet (untrusted)

Échoue contre :

• Compromis interne (prompt injection rend l'agent malveillant)
• Confused deputy (agent légitime utilisé pour actions malveillantes)
• Insider threat (admin host accède aux weights)
• Lateral movement (un service compromis attaque les autres librement)

Modèle zero-trust

[Modèle zero-trust]
   Chaque appel = vérification :
   ▸ Identity vérifiée (SPIFFE / mTLS)
   ▸ Authorization explicite (RBAC fin)
   ▸ Channel chiffré (TLS 1.3)
   ▸ Logged et auditable
   
   Pas de "trusted zone" implicite.
   Pas de "shared secret" entre services.
   Tout est authentifié à la frontière.

NIST SP 800-207 (2020), référentiel fondateur. Cinq piliers (CISA Zero Trust Maturity Model v2.0, 2023) :

1. Identity : qui agit ?
2. Devices : depuis quel device ?
3. Networks : sur quel réseau ?
4. Applications & Workloads : quelle app/service ?
5. Data : quelle donnée ?

Pour LLM 2026, ajouter implicitement un 6ème pilier : AI Models (weights, embeddings, training data).

Pilier 1, Chiffrement par actif IA

Modèles weights

Threat : vol disque physique, compromise host, insider threat (admin curieux).

Mitigations :

# K8s : StorageClass chiffré
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: encrypted-models
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  encrypted: "true"
  kmsKeyId: arn:aws:kms:eu-west-1:...:key/...
  iops: "16000"
  throughput: "1000"
allowVolumeExpansion: true

Niveau supérieur, Confidential Computing :

# Pod scheduling sur nodes Confidential Computing
apiVersion: v1
kind: Pod
metadata:
  name: vllm-confidential
spec:
  nodeSelector:
    confidential-computing: "intel-tdx"
  containers:
    - name: vllm
      image: vllm/vllm-openai:v0.6.4
      # Mémoire chiffrée par le hardware,
      # admin host ne peut pas lire weights en mémoire

Embeddings et vector store

Risk spécifique : embeddings peuvent être reverse-engineerés pour reconstruire texte original (Morris et al., Text Embeddings Reveal (Almost) As Much As Text, EMNLP 2023, ~92% reconstruction accuracy).

Mitigation pour données sensibles :

# 1. Pseudonymiser AVANT embedding
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
 
def safe_embed(text: str) -> list[float]:
    # Strip PII before embedding
    redacted = anonymize(text, entities=["EMAIL", "PHONE", "PERSON", "FR_NIR"])
    return embedding_model.encode(redacted)
 
 
# 2. Chiffrer at rest
# ChromaDB / Qdrant supports encryption at rest natif
# Sinon : disque chiffré + access control strict
 
 
# 3. Chiffrer in transit
# TLS 1.3 sur connection vector store
client = QdrantClient(
    url="https://qdrant.internal:6333",
    api_key=os.environ["QDRANT_API_KEY"],
    https=True,
    verify=True,  # ne JAMAIS désactiver verify en prod
)

Prompts et réponses

In transit : TLS 1.3 partout.

At rest dans logs :

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
 
def encrypt_log_payload(plaintext: bytes, key_id: str) -> dict:
    """Chiffre un payload sensible avec KMS-managed key."""
    # Récupérer DEK via KMS (Vault, AWS KMS, Azure Key Vault)
    dek = kms_decrypt(key_id, encrypted_dek)
    
    aesgcm = AESGCM(dek)
    nonce = os.urandom(12)
    ciphertext = aesgcm.encrypt(nonce, plaintext, associated_data=None)
    
    return {
        "ciphertext": ciphertext.hex(),
        "nonce": nonce.hex(),
        "key_id": key_id,
    }
 
 
def log_sensitive_interaction(prompt: str, response: str, user_id: str):
    payload = json.dumps({
        "prompt": prompt,
        "response": response,
        "user_id_hash": pseudonymize(user_id),
    }).encode()
    
    encrypted = encrypt_log_payload(payload, key_id="logs-llm-prod")
    
    logger.info({
        "event": "llm_interaction",
        "encrypted_payload": encrypted,
        "ts": datetime.utcnow().isoformat(),
    })

Standards et quantum-safe

Aujourd'hui :

• AES-256-GCM pour data
• RSA-4096 / ECDSA-P384 / Ed25519 pour signatures
• TLS 1.3 wire (ne plus accepter TLS 1.2 nouveaux services)

Quantum-safe (2026-2028) :

• NIST PQC standards 2024 : ML-KEM (Kyber, key encapsulation), ML-DSA (Dilithium, digital signatures)
• À anticiper pour assets longue durée : modèles weights conservés 5+ ans, audit logs avec rétention longue, embeddings de données médicales/légales
• Stratégie hybride : combiner classique + PQ pendant la transition

Pilier 2, Workload identity (SPIFFE/SPIRE)

Pourquoi pas des API keys partagées

Anti-pattern fréquent :

# ConfigMap avec API key partagée entre tous les pods
apiVersion: v1
kind: ConfigMap
metadata:
  name: shared-llm-config
data:
  vllm_api_key: "sk-shared-key-12345"  # ← TOUT le monde a ça

Problèmes :

• Fuite d'un seul pod = compromise globale
• Aucune traçabilité (qui a appelé ?)
• Rotation manuelle complexe et risquée

Pattern SPIFFE/SPIRE

SPIFFE = format d'identité standard, SVID = certificat X.509 signé par CA SPIRE.

spiffe://zerodaysupport.com/ns/llm-prod/sa/agent-customer-support
        └── trust domain ────────┘    └── workload path ─────────┘

SPIRE Server = CA centrale, SPIRE Agent = sur chaque node, attest workload via méta-données K8s.

# SPIRE Server registration entry
apiVersion: spire.io/v1
kind: ClusterSPIFFEID
metadata:
  name: agent-customer-support
spec:
  spiffeIDTemplate: "spiffe://zerodaysupport.com/ns/{{ .PodMeta.Namespace }}/sa/{{ .PodSpec.ServiceAccountName }}"
  podSelector:
    matchLabels:
      app: agent-customer-support
  ttl: 1h  # rotation automatique

mTLS basé sur SPIFFE

# Service Python qui authenticate via SPIFFE SVID
from pyspiffe.spiffe_id.spiffe_id import SpiffeId
from pyspiffe.workloadapi.default_x509_source import DefaultX509Source
import ssl
 
x509_source = DefaultX509Source()
 
# Server side : seuls SPIFFE IDs authorized acceptés
ALLOWED_SPIFFE = {
    SpiffeId.parse("spiffe://zerodaysupport.com/ns/llm-prod/sa/agent-customer-support"),
    SpiffeId.parse("spiffe://zerodaysupport.com/ns/llm-prod/sa/api-gateway"),
}
 
def verify_peer(svid):
    return svid.spiffe_id in ALLOWED_SPIFFE
 
# Configurer TLS server avec source SPIFFE + verifier
ssl_context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
ssl_context.load_cert_chain(x509_source.get_x509_svid().cert_chain_path,
                            x509_source.get_x509_svid().private_key_path)
ssl_context.verify_mode = ssl.CERT_REQUIRED
ssl_context.set_verify_callback(verify_peer)

Service mesh (alternative) Istio / Linkerd

Plus simple à adopter pour les équipes K8s : Istio fournit mTLS automatique sur tout le mesh, basé sur SPIFFE under the hood.

# Istio strict mTLS namespace-wide
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: llm-prod
spec:
  mtls:
    mode: STRICT
---
# Authorization policy : seul agent-customer-support peut appeler vllm
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: vllm-authz
  namespace: llm-prod
spec:
  selector:
    matchLabels:
      app: vllm-llama-3-70b
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/llm-prod/sa/agent-customer-support"
              - "cluster.local/ns/llm-prod/sa/api-gateway"
      to:
        - operation:
            methods: ["POST"]
            paths: ["/v1/chat/completions"]

OAuth on-behalf-of pour agents

Cf article Confused Deputy du cluster vulnérabilités. Pattern critique pour agents IA : ne jamais propager les privilèges de l'agent vers les tools, toujours utiliser l'identité de l'utilisateur initial via OBO flow.

Pilier 3, Isolation et micro-segmentation

NetworkPolicies, deny-all par défaut

# Étape 1 : Deny all par défaut dans le namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: llm-prod
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
 
---
# Étape 2 : Allow explicite
# vLLM accepte de api-gateway uniquement
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: vllm-from-gateway
  namespace: llm-prod
spec:
  podSelector:
    matchLabels:
      app: vllm-llama-3-70b
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api-gateway
      ports:
        - protocol: TCP
          port: 8000
  egress:
    # Vers observability stack
    - to:
        - namespaceSelector:
            matchLabels:
              name: monitoring
      ports:
        - protocol: TCP
          port: 9090  # Prometheus
        - protocol: TCP
          port: 3100  # Loki
    # Vers model storage (read only)
    - to:
        - podSelector:
            matchLabels:
              app: minio-models
      ports:
        - protocol: TCP
          port: 9000
    # PAS d'internet egress

Cilium eBPF, micro-segmentation L7

NetworkPolicies K8s standard sont L3/L4. Cilium ajoute L7 (HTTP path, gRPC method, Kafka topic).

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: vllm-l7-policy
  namespace: llm-prod
spec:
  endpointSelector:
    matchLabels:
      app: vllm-llama-3-70b
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: api-gateway
      toPorts:
        - ports:
            - port: "8000"
              protocol: TCP
          rules:
            http:
              # Seuls ces paths autorisés
              - method: "POST"
                path: "/v1/chat/completions"
              - method: "GET"
                path: "/health"
              # Bloque /metrics depuis api-gateway (réservé Prometheus)

GPU isolation (rappel)

Cf article Architecture on-premise du cluster. Récap :

• Taints/tolerations K8s pour dédier nodes
• Multi-Instance GPU (MIG) sur H100/A100 pour partition matérielle
• Pas de mix workloads tiers / sensibles
• Confidential Computing GPU pour cas haut risque

Pilier 4, Devices et endpoints

Souvent oublié dans contexte IA mais important :

Posture compliance

Avant qu'un dev / ops accède à la stack LLM (kubectl, console admin, accès SSH GPU node), vérifier :

• OS patché (last patches < 30j)
• Disk encryption activé
• EDR running (CrowdStrike, SentinelOne, etc.)
• MFA enrollment up-to-date
• VPN / ZTNA actif (Cloudflare Access, Tailscale, Twingate)

# Exemple Cloudflare Access policy
- include:
    - emails:
        - llm-team@zerodaysupport.com
- require:
    - mfa
    - device_posture:
        - integration_id: crowdstrike-falcon
          minimum_version: "7.0"

Device attestation pour accès LLM

Pour utilisateurs finaux (employés enterprise) accédant à un assistant IA interne, attester le device avant accès :

• Browser : WebAuthn + device-bound credentials
• Mobile : Apple DeviceCheck / Android SafetyNet attestation
• Desktop : platform attestation (TPM)

Empêche credential stuffing depuis device non corporate.

Pilier 5, Data

Classification automatique

# DLP pre-prompt : détecter classification de la donnée
DATA_CLASSIFICATIONS = {
    "public": 0,
    "internal": 1,
    "confidential": 2,
    "secret": 3,
}
 
CLASS_PATTERNS = {
    "secret": [r"\bSECRET\b", r"CONFIDENTIAL.*", r"API_KEY="],
    "confidential": [r"\bCLIENT-\d+\b", r"contract.*signed"],
    # ...
}
 
def classify_data(text: str) -> str:
    for cls, patterns in CLASS_PATTERNS.items():
        if any(re.search(p, text) for p in patterns):
            return cls
    return "internal"
 
 
@app.post("/chat")
async def chat(req: ChatReq):
    classification = classify_data(req.message)
    
    if classification == "secret":
        # Force routing vers LLM on-prem (pas API cloud)
        return await call_local_llm(req.message)
    elif classification == "confidential":
        # Log avec extra audit + on-prem si dispo
        await audit_log_strict(req)
        return await call_local_llm(req.message)
    else:
        return await call_default_llm(req.message)

DLP egress

Avant que la réponse LLM sorte vers le user, scan PII et data classification :

def dlp_egress(response: str, user_classification: int) -> str:
    """
    Si la réponse contient données plus sensibles que ce que user
    peut voir, redact.
    """
    detected = analyzer.analyze(text=response, language="fr")
    for finding in detected:
        if finding.classification > user_classification:
            response = response.replace(finding.text, "[REDACTED]")
    return response

Access logging granulaire

Chaque accès à donnée sensible (RAG retrieval cross-tenant, weights download, embedding query) → log structured avec SPIFFE ID demandeur, asset accédé, classification, action.

Pilier 6 (bonus IA), AI Models

Pas dans CISA standard. Critique pour IA en 2026 :

CISA Zero Trust Maturity Model, grille adaptée LLM

Cible : Advanced minimum sur tous piliers pour app prod sensible. Optimal pour systèmes high risk EU AI Act.

Roadmap d'adoption

Mois 1-3 : Fondations

• Implémenter MFA partout
• Migrer secrets vers Vault / KMS
• Encryption at rest sur weights et vector store
• Logs structurés avec PII redaction
• TLS 1.3 partout

Mois 4-6 : Identity et segmentation

• Déployer SPIFFE/SPIRE ou service mesh (Istio/Linkerd)
• NetworkPolicies deny-all + allow explicites
• mTLS entre services
• OAuth on-behalf-of pour agents

Mois 7-9 : Niveau avancé

• Cilium eBPF L7 policies
• Device posture compliance enforcement
• Auto-classification + DLP egress
• Audit logs SIEM intégrés

Mois 10-12 : Optimal pour critique

• Confidential Computing pour modèles haut risque
• Quantum-safe planning
• Behavioral analytics intégré au reste
• Audit zero-trust maturity externe

Erreurs récurrentes

Erreur 1, API key partagée entre tous les services

Compromise d'un = compromise de tout. SPIFFE ou IAM workload identity obligatoire.

Erreur 2, NetworkPolicies absentes ou trop permissives

egress: {} (allow all). À chaque pod compromis, lateral movement libre. Deny-all + allow explicites systématique.

Erreur 3, TLS pas vérifié strictement

verify=False quelque part dans le code Python. MITM possible. Strict verify partout, pinning pour critique.

Erreur 4, Confidential Computing sans attestation

Activer TEE sans vérifier l'attestation = sécurité théorique. Toujours valider attestation cryptographique au boot.

Erreur 5, Embeddings PII non pseudonymisés

Reverse-engineering possible. Pseudonymiser upstream avant embedding.

Erreur 6, Pas de roadmap progressive

"Zero trust everywhere now" = échec. Progressive sur 12-18 mois par pillar prioritaire.

Ce que ça change pour votre dispositif

Une posture zero-trust mature pour workloads IA en 2026 :

• Chiffrement 3 couches (modèles, embeddings, prompts/réponses) avec Confidential Computing pour critique
• Workload identity SPIFFE/SPIRE ou service mesh, fini les API keys partagées
• Micro-segmentation eBPF L7 avec deny-all + allow explicites
• Device posture + ZTNA pour accès admin / utilisateur
• DLP automatique + classification + access logging
• AI Models comme pillar dédié avec mesures spécifiques

ROI : transition complète 12-18 mois, 1-2 ETP sécurité + collab avec équipes plateforme. Bénéfices mesurés :

• Réduction blast radius d'un compromis (mouvement latéral bloqué)
• Conformité EU AI Act / NIST AI RMF / ISO 42001 facilitée
• Audits externes simplifiés (preuve via configs + logs)
• Maturité détection (chaque accès loggué = baseline anomaly detection)

Le zero-trust pour IA n'est plus une option en 2026 pour les apps stratégiques. C'est l'état de l'art que les régulateurs et les clients enterprise commencent à exiger.

Pour aller plus loin : la couche zero-trust et chiffrement constitue le socle infra sur lequel se posent les couches applicatives (guardrails, observabilité, détection abus) déjà couvertes dans le cluster défense. La synergie complète forme une architecture sécurité IA mature 2026.