Sécurité IA

Claude (Anthropic) en entreprise : sécuriser l'usage de l'API et des agents

Cloisonner les workspaces, gérer les clés, surveiller les agents tool-using, encadrer le MCP. Posture de sécurité de bout en bout pour une intégration enterprise de Claude.

Aroua Biri 9 min

Claude est devenu en 2025-2026 un des modèles préférés des équipes tech européennes. Constitutional AI, performances solides, posture sécurité d'Anthropic plus stricte que la moyenne. Mais "Anthropic prend la sécurité au sérieux" ne dispense pas de sécuriser votre intégration. Voici la posture de bout en bout que je mets en place sur les missions Claude.

Le périmètre à sécuriser

Une intégration enterprise de Claude touche typiquement à :

  • Claude.ai (interface web, plans Pro/Team/Enterprise).
  • API Claude (claude-opus, claude-sonnet, claude-haiku) appelée depuis vos applications.
  • MCP (Model Context Protocol) pour exposer vos outils internes à des agents Claude.
  • Claude Code ou clients tiers qui utilisent l'API.
  • Bedrock (AWS) ou Vertex AI (Google) qui réservent Claude derrière leur infrastructure.

Chaque vecteur a ses risques propres et ses contrôles spécifiques.

1. Gouvernance des comptes Claude.ai

Si vous avez activé Claude for Work / Claude Enterprise :

  • SSO obligatoire : connexion uniquement via votre IdP (Okta, Entra ID, Google Workspace). Pas de comptes locaux.
  • SCIM activé pour le provisioning/déprovisioning automatique.
  • Workspaces séparés par fonction : un workspace "produit", un "finance", un "RH". Pas de mixité.
  • Politique de partage des conversations : par défaut interne au workspace, jamais public.
  • Politique de mémoire : Anthropic ne s'entraîne pas sur les données enterprise mais cela mérite d'être confirmé dans le DPA signé avec Anthropic.

2. Sécurisation des clés API

Les clés API Claude permettent d'envoyer des requêtes facturées sur votre compte et d'accéder aux features. C'est un secret de production critique.

  • Clés par environnement (dev, staging, prod) — jamais une clé partagée.
  • Clés par application — une clé par service consommateur, pas une clé pour toute l'entreprise.
  • Stockage dans un secret manager (AWS Secrets Manager, HashiCorp Vault, Doppler, GCP Secret Manager). Jamais dans .env commité, jamais dans le code, jamais dans Slack DM.
  • Rotation automatique au moins trimestrielle, immédiate sur tout soupçon.
  • Limites de quota par clé pour éviter les fuites coûteuses (un attaquant qui récupère une clé peut consommer des dizaines de milliers d'euros en heures).

3. Filtrage des entrées et sorties

Toute application qui envoie du contenu utilisateur à Claude doit avoir :

Pre-processing

  • Suppression ou tokenisation des PII détectables (emails, IBAN, numéros de carte, numéros de sécu).
  • Limites de taille (max input length adapté à votre cas d'usage, pas illimité).
  • Détection des patterns de prompt injection connus (mais c'est faillible — voir Threat modeling LLM).

Post-processing

  • Classifieur en sortie qui détecte : leak de PII non sollicité, génération de code malveillant, hallucinations factuelles sur des domaines sensibles.
  • Filtrage des liens générés : allowlist de domaines, sandbox des URLs.
  • Logging structuré : prompt, contexte, réponse, timestamp. Conservation 90 jours minimum pour investigation.

4. MCP — Model Context Protocol

MCP, lancé par Anthropic en novembre 2024 et désormais largement adopté, permet à un agent Claude d'appeler des outils externes : lire des fichiers, interroger une base, envoyer des emails. C'est aussi la nouvelle surface d'attaque la plus large des intégrations LLM.

Règles de design pour vos serveurs MCP :

  • Authentification stricte : OAuth, mTLS, ou tokens scoped. Pas de "trust the network".
  • Autorisations granulaires : un agent qui doit lire la base CRM ne doit pas pouvoir l'écrire ; un agent qui peut envoyer un email doit avoir une allowlist de destinataires.
  • Confirmation humaine pour les actions à effet de bord (paiement, modification, suppression).
  • Sandbox d'exécution pour les outils qui interprètent du contenu (eval de code, traitement de fichiers fournis par l'utilisateur).
  • Logs détaillés des appels d'outils, avec corrélation prompt utilisateur ↔ appel MCP ↔ réponse.

Le risque majeur du MCP est le hijack d'agent par prompt injection indirecte : une instruction cachée dans un document que l'agent lit déclenche un appel d'outil malveillant. Voir Agents autonomes : périmètre de privilèges, sandbox, kill-switch.

5. Choix entre API directe, Bedrock, et Vertex AI

Trois modes d'accès à Claude, trois profils de sécurité différents :

API directe Anthropic

  • Interlocuteur unique : Anthropic.
  • DPA standard, hébergement aux US.
  • Pour la majorité des usages interne EU non-sensibles, c'est suffisant.

Claude via AWS Bedrock

  • Données et inference dans la région AWS de votre choix (Frankfurt, Paris, Stockholm).
  • Pas de transit de données vers Anthropic au-delà de l'inférence dans Bedrock.
  • IAM / VPC / KMS d'AWS appliqués.
  • Recommandé pour les workloads sensibles ou réglementés en EU.

Claude via Google Vertex AI

  • Équivalent à Bedrock côté Google Cloud.
  • Régions EU disponibles.
  • Choix selon votre cloud principal.

Pour des données soumises à HDS, secret bancaire, secret défense, ou toute donnée régulée, Bedrock ou Vertex AI sont quasi obligatoires. L'API directe Anthropic ne fournit pas les garanties de localisation requises.

6. Surveillance des coûts et anomalies

Une clé API compromise peut coûter cher avant d'être détectée. À mettre en place :

  • Budget alarms par projet et par clé (CloudWatch Billing, Vertex AI quotas).
  • Anomaly detection sur les volumes d'appels (qu'un service appelle 10x sa moyenne en 1h doit alerter).
  • Alerte sur les patterns suspects : appels depuis des IP inhabituelles, requêtes 24/7 quand l'usage normal est en heures ouvrées.

7. Politique d'usage interne

Au-delà des contrôles techniques, une politique écrite vaut son pesant d'or :

  • Quels cas d'usage sont validés ?
  • Quelles données peut-on envoyer à Claude (par niveau de sensibilité) ?
  • Quels processus de validation pour un nouveau cas d'usage ?
  • Comment signaler un incident ou un comportement anormal du modèle ?

Cette politique évite le shadow AI (voir Shadow AI : le cas Samsung × ChatGPT) tout en libérant les usages légitimes.

Récap : la stack de sécurité Claude enterprise

| Couche | Contrôle | |---|---| | Identité | SSO, SCIM, MFA phishing-resistant | | Workspace | Séparation par fonction, pas de mixité | | API keys | Per environnement, secret manager, rotation | | Données | Pre/post processing, classifieurs, logs 90j | | MCP | OAuth, scoped tokens, sandbox, confirmation humaine | | Localisation | Bedrock/Vertex EU pour données sensibles | | Monitoring | Anomaly detection, budget alarms | | Gouvernance | Politique écrite, formation, audit |

Sans toutes ces couches, une intégration Claude reste exploitable. Avec elles, elle devient une vraie capacité enterprise.

Un sujet connexe chez vous ?

20 minutes pour cadrer ensemble. Aucune offre commerciale envoyée à froid.

Réserver un échange Calendly