Ce brief technique Workstation couvre la sécurité et l’authentification de l’IA agentique : sécuriser les agents d’entreprise qui appellent des outils via le MCP (Model Context Protocol) avec OAuth 2.1, placer les endpoints MCP à haut risque derrière un VPN / réseau privé, et gérer les identifiants d’outils avec HashiCorp Vault — secrets dynamiques, baux, rotation automatique et révocation immédiate. Il recommande des configurations alignées sur l’industrie pour Claude, OpenAI et Cursor.
- Problème : Agents avec clés d’outils statiques longue durée + MCP public = dispersion des identifiants et mouvement latéral.
- Auth : MCP distant = serveur de ressources OAuth 2.1 + RFC 9728 PRM + audience RFC 8707 ; PKCE obligatoire.
- Entreprise : Préférer MCP Enterprise-Managed Authorization (EMA / ID-JAG) via l’IdP d’entreprise.
- Réseau : MCP interne et Vault sur VPN/lien privé ; listes d’autorisation d’egress par outil.
- Secrets : Secrets dynamiques Vault + TTL de bail ; rotation auto des rôles statiques ; révocation en fin de session.
- Séparation : Clés API du fournisseur LLM != jetons d’accès MCP != secrets des outils backend.
Sources : MCP Authorization, Vault leases, Vault AI agent validated pattern, Claude connector auth. Vérifiez la documentation fournisseur actuelle avant un déploiement en production.
1. Modèle de menace pour les agents d’entreprise
Un agent est un principal d’automatisation privilégié. Modes de défaillance typiques :
- Dispersion des secrets — clés API dans le JSON MCP,
.envcommités dans git, ou collés dans les prompts. - Substitution de jeton — jeton d’accès émis pour le serveur A accepté par le serveur B (absence de liaison d’audience).
- Outils trop permissifs — un même MCP peut écrire en bases de prod et ouvrir des firewalls avec la même session.
- OBO non audité — l’agent agit sans lier les actions à une identité humaine.
- MCP public — outils internes accessibles depuis Internet sans VPN ni lien privé.
Les contrôles doivent couvrir l’identité (qui), l’autorisation (quels outils), les secrets (avec quels identifiants) et le réseau (depuis où).
2. Authentification MCP : standard industriel
Pour le MCP distant basé sur HTTP, la spécification s’aligne sur OAuth 2.1 :
- Serveur MCP = serveur de ressources OAuth ; les clients envoient
Authorization: Bearer. - PKCE est obligatoire ; le grant implicite est interdit.
- Les serveurs MUST publier les Protected Resource Metadata (RFC 9728) pour que les clients découvrent le serveur d’autorisation.
- Utiliser les Resource Indicators (RFC 8707) pour lier l’audience des jetons à ce serveur MCP.
- Authorization Server Metadata (RFC 8414) et/ou découverte OIDC pour les capacités de l’AS.
- Dynamic Client Registration (RFC 7591) est recommandé lorsque les clients doivent s’enregistrer sans ID client manuels.
# Protected Resource Metadata (conceptual)
{
"resource": "https://mcp.internal.example/mcp",
"authorization_servers": ["https://auth.example.com"],
"scopes_supported": ["mcp:tools", "mcp:resources"]
}
STDIO / MCP local est différent : préférez des identifiants d’environnement injectés par Vault Agent — ne forcez pas OAuth navigateur sur chaque outil de bureau. Le MCP distant/public doit implémenter OAuth 2.1.
2.1 Enterprise-Managed Authorization (zero-touch)
L’extension MCP Enterprise-Managed Authorization permet à l’IdP d’entreprise (Okta, Entra ID, etc.) d’accorder l’accès aux serveurs MCP approuvés au SSO via un ID-JAG (Identity Assertion JWT Authorization Grant), en évitant la fatigue de consentement par serveur. Adoptez EMA pour les flottes Claude / IDE / agents à l’échelle de l’organisation.
3. Intégration VPN et MCP privé
OAuth authentifie le client ; il ne remplace pas l’isolation réseau.
- Hébergez les serveurs MCP internes et Vault sur un CIDR privé (VPN, PrivateLink, mesh Tailscale/WireGuard, ou mTLS de service mesh).
- Liez les écouteurs MCP aux interfaces privées ; bloquez le 443 public sauf si le produit est volontairement exposé à Internet.
- Appliquez des listes d’autorisation d’egress depuis le runtime de l’agent : uniquement les API/hôtes MCP approuvés.
- Séparez les plans : laptops développeurs sur VPN d’entreprise pour Cursor ; agents côté serveur dans un VPC sans MCP Internet sauf SaaS approuvé.
Modèle : VPN pour la reachabilité + OAuth pour l’autorisation + Vault pour les secrets.
4. HashiCorp Vault pour les secrets d’agents
Les clés d’outils statiques longue durée sont incompatibles avec le rayon d’explosion des agents. Vault fournit :
4.1 Secrets dynamiques + baux
Chaque secret dynamique renvoie un lease_id et un TTL. Le consommateur doit renouveler (si autorisé) ou demander un remplacement avant expiration. Lorsque le bail se termine, Vault peut révoquer l’identifiant chez le fournisseur. Cela impose un check-in, améliore les journaux d’audit et réduit les fenêtres d’exposition.
4.2 Rotation automatique
Pour les rôles statiques (ex. mot de passe de base de données avec rotation_period), Vault rotate selon un calendrier. Les templates Vault Agent re-fetchent près de la fin de vie (seuil par défaut lease_renewal_threshold ~0,9 du TTL) et peuvent redémarrer un processus enfant lorsque les identifiants changent.
4.3 TTL recommandés pour les agents
| Classe de risque | Exemple | Guidance TTL |
|---|---|---|
| Écriture critique | Mutation BD prod, admin IAM | 5-15 minutes ; révoquer en fin d’outil |
| Lecture / staging | Réplicas en lecture, API tickets | 30-60 minutes |
| Clé fournisseur LLM | Clé org OpenAI / Anthropic | Gérée par Vault ; rotation planifiée ; jamais dans le JSON MCP |
4.4 Vault + attribution utilisateur (validated pattern)
Validated pattern HashiCorp : l’utilisateur s’authentifie ; l’agent reçoit un jeton on-behalf-of (OBO) ; les outils s’authentifient auprès de Vault avec JWT ; Vault mappe les claims aux policies et émet des secrets dynamiques à périmètre limité. Les pistes d’audit lient l’émission du secret à l’humain, pas à un compte robot partagé.
Vault Enterprise ajoute Agent Registry et des profils OAuth resource server pour que les agents inscrits présentent des JWT OAuth sans étape de login Vault séparée — avec des contraintes spécifiques à l’agent pour la délégation / OBO.
# Conceptual agent tool hook (do not ship secrets to the model)
vault_token = login_jwt(obo_token) # Vault auth
secret = vault.read("database/creds/agent-ro")
lease_id, ttl = secret["lease_id"], secret["lease_duration"]
try:
run_tool(db_url=secret["data"]) # use within TTL
finally:
vault.lease.revoke(lease_id) # or let TTL expire
5. Configurations recommandées par fournisseur
5.1 Claude (Anthropic)
- Préférez OAuth pour les connecteurs MCP distants ; renvoyez 401 avec
WWW-Authenticatepointant vers PRM pour que les clients découvrent l’auth. - Ne placez jamais de jetons/clés API dans les query strings d’URL de connecteur (journalisés, mis en cache, interdits par les règles de jetons MCP).
- Claude Code : OAuth local avec stockage sécurisé des jetons et refresh ; les plugins ne doivent pas lire les jetons.
- Claude hébergé : identifiants client gérés par Anthropic pour les utilisateurs consentants ; conservez quand même les secrets d’outils dans Vault derrière votre MCP.
- Entreprise : alignez l’IdP avec MCP EMA pour un accès serveur zero-touch.
5.2 OpenAI (Agents / tools)
- Séparez les clés API du modèle des identifiants d’outils ; rotation et rayon d’explosion différents.
- Exécutez les runtimes d’agents dans un VPC ; appelez le MCP privé via réseau privé.
- Passez des jetons attribués à l’utilisateur aux outils ; authentifiez-vous auprès de Vault avec JWT ; émettez des secrets dynamiques par invocation.
- Journalisez chaque appel d’outil avec user + agent + lease_id pour la conformité.
5.3 Cursor
- Config serveur MCP : référencez uniquement des variables d’environnement — ne codez jamais en dur des secrets dans
mcp.json. - Serveurs STDIO : exécutez sous Vault Agent (template ou env) pour que les baux tournent sans que les développeurs copient des mots de passe.
- MCP distant : OAuth lorsque le serveur le prend en charge ; sinon VPN d’entreprise + bearer courte durée depuis Vault.
- Politique d’équipe : liste blanche des serveurs MCP approuvés ; bloquez les MCP communautaires non fiables sur les bases de code prod.
- Gardez
.env/ fichiers secrets hors contexte via les règles d’ignore ; règles projet : interdire de coller des secrets dans le chat.
6. Matrice de contrôles de référence
| Couche | Contrôle | Anti-pattern |
|---|---|---|
| Identité | SSO IdP + EMA / OAuth PKCE | Mot de passe robot partagé |
| MCP | PRM + jetons liés à l’audience | Jetons dans l’URL ; pas d’expiration |
| Réseau | VPN / PrivateLink + ACL d’egress | MCP public pour outils prod |
| Secrets | Bail Vault + rotation + révocation | Clés d’un an dans mcp.json |
| Ops | Audit IdP+MCP+Vault ; gates humains | Déploiements / paiements prod sans gate |
7. Checklist d’implémentation
- Inventoriez chaque serveur MCP et classifiez public vs privé.
- Implémentez OAuth 2.1 + PRM sur tous les MCP distants ; activez EMA avec l’IdP d’entreprise.
- Placez MCP + Vault derrière VPN/réseau privé ; documentez comment Cursor/Claude rejoignent le réseau.
- Remplacez les clés d’outils statiques par des secrets dynamiques Vault ; définissez les TTL par classe de risque.
- Intégrez Vault Agent (ou renew/revoke SDK) dans les runtimes d’agents ; révoquez les baux en fin de session.
- Séparez les clés fournisseurs LLM ; stockez-les et faites-les tourner dans Vault — jamais dans les prompts ou la config MCP.
- Ajoutez des gates d’approbation humaine pour l’argent, les changements d’identité et les déploiements en production.
- Testez : bail expiré échoue en fail-closed ; jeton mauvaise audience rejeté ; chemin public bloqué.
Publié par Workstation — automatisation d’entreprise, plateformes multi-agents et livraison sécurisée sur Kubernetes.