Les agents de codage IA ont introduit une nouvelle classe de contraintes d’authentification GCP au-delà du problème standard multi-projet. Trois contraintes s’appliquent à tous les agents, quel que soit le fournisseur :
- Pas de flux OAuth interactifs.
gcloud auth loginouvre une fenêtre de navigateur pour le consentement utilisateur. Les agents en terminal ne peuvent pas gérer cela. Il n’y a pas d’URL de callback, pas de surface d’interaction utilisateur. - Pas de ré-authentification en cours de session. Quand les tokens expirent pendant une longue tâche, les agents ne peuvent pas vous inviter à vous ré-authentifier. Ils échouent silencieusement ou avec des erreurs cryptiques.
- Conflits de fichiers de config lors d’exécutions parallèles. Plusieurs agents tournant simultanément contre le même répertoire
~/.config/gcloud/s’écrasent mutuellement l’état.
La manière dont les différents agents gèrent ces contraintes varie considérablement.
Claude Code
Claude Code délègue entièrement aux credentials d’environnement pour se connecter à Vertex AI ou exécuter des commandes gcloud. Il utilise les ADC standards, ce qui signifie qu’il nécessite une pré-authentification via gcloud auth login et gcloud auth application-default login avant de démarrer une session.
L’expiration des tokens est un problème connu. Un bug documenté (GitHub #726) affecte les organisations avec des restrictions de durée de session GCP. Quand les credentials expirent en milieu de session, Claude Code ne les détecte pas et ne les rafraîchit pas. Il continue à utiliser des credentials périmés mis en cache jusqu’à ce qu’il rencontre un échec hard, typiquement une erreur invalid_grant. La seule solution est de redémarrer Claude Code entièrement.
L’authentification en environnement headless (flux device code, pour les environnements sans accès navigateur) est une demande de fonctionnalité ouverte (GitHub #7100) sans calendrier.
L’implication pratique : Si vous utilisez des politiques d’organisation GCP avec des durées de session courtes (courantes dans les configurations de sécurité enterprise), les sessions Claude Code se casseront plus fréquemment. Pour la plupart des configurations de conseil avec des credentials de compte de service (qui n’expirent pas de la même façon), c’est moins problématique.
Ce qui fonctionne de façon fiable : Démarrez Claude Code depuis l’intérieur d’un répertoire de projet géré par direnv. L’agent hérite des variables d’environnement du shell, notamment CLOUDSDK_CONFIG, GOOGLE_APPLICATION_CREDENTIALS et GOOGLE_CLOUD_PROJECT. L’agent utilise automatiquement les credentials du bon projet sans configuration spéciale. Consultez Configuration GCP multi-client avec direnv pour la mise en place.
Dimension sécurité : Des recherches ont documenté que des dépôts malveillants peuvent utiliser des intégrations MCP ou des shell hooks pour exfiltrer les credentials gcloud actifs avant que vous n’ayez accordé votre confiance au projet. C’est une des raisons pour lesquelles l’isolation CLOUDSDK_CONFIG par projet importe au-delà du problème multi-client — un vol de credentials se limite à un répertoire de config temporaire d’un projet, pas à l’intégralité de ~/.config/gcloud/.
OpenAI Codex
Codex adopte l’approche architecturale opposée. Il s’exécute dans des conteneurs isolés sans accès internet par défaut. Les secrets peuvent être fournis via des variables d’environnement lors de la configuration, mais ils sont supprimés avant que la phase d’exécution de l’agent ne commence.
Cela signifie que l’accès persistant aux credentials GCP est architecturalement impossible par défaut. Si vous avez besoin que Codex interagisse avec GCP, vous devez explicitement activer l’accès réseau et câbler vous-même les credentials — c’est un choix de conception délibéré, pas un oubli.
Codex a ajouté l’authentification par device code (codex login --device-auth) pour sa propre authentification au compte Codex, mais la gestion des credentials GCP reste entièrement votre responsabilité. Le modèle d’isolation est robuste par conception. Le compromis est que le câblage des credentials doit être fait en amont, explicitement, avant toute exécution d’agent.
Cursor
Le terminal agent de Cursor s’exécute dans un sous-shell sandboxé et non interactif. Il n’hérite pas des variables d’environnement utilisateur et ne source pas les fichiers de configuration shell comme .zshrc ou .bashrc.
Cela a une conséquence directe : les commandes CLI cloud interactives sont complètement non fonctionnelles. Exécuter gcloud auth login dans le terminal agent de Cursor échouera parce qu’il n’y a pas de navigateur, pas de sourcing de shell et pas d’héritage de variable d’environnement.
Le contournement communautaire est d’utiliser des serveurs MCP pour les interactions GCP plutôt que des commandes gcloud CLI directes. Un serveur MCP configuré avec des credentials au démarrage peut accepter des requêtes structurées de l’agent sans nécessiter d’accès CLI. Cursor et Windsurf supportent des configurations MCP au niveau du projet, ce qui signifie que le serveur MCP redémarre avec les bons credentials quand vous changez de projet.
Comptes de service sur tous les agents
Pour tous les agents, les fichiers de clé JSON de compte de service restent la méthode d’authentification la plus fiable. Les raisons :
- Les comptes de service ne nécessitent pas de flux navigateur interactifs
- Les fichiers de clé n’expirent pas en cours de session (bien qu’ils puissent être révoqués)
- Tout outil qui lit
GOOGLE_APPLICATION_CREDENTIALSfonctionne sans modification - Les fichiers de clé fonctionnent dans des environnements sandboxés et non interactifs
Google recommande fortement d’éviter les fichiers de clé de compte de service en faveur de Workload Identity Federation. WIF est réellement plus sûr — tokens de courte durée de vie, pas de clés statiques sur le disque, pistes d’audit appropriées. Mais WIF nécessite un fournisseur d’identité externe (GitHub Actions OIDC, AWS IAM) pour valider votre workload. Un ordinateur portable de développeur n’est pas GitHub Actions. Il n’y a pas de fournisseur d’identité externe pour le développement local.
Le juste milieu — l’impersonation de compte de service — génère un token d’accès à courte durée de vie sans fichier de clé persistant :
gcloud auth print-access-token \ --impersonate-service-account=dbt-runner@acme-prod.iam.gserviceaccount.comCela génère un token de 60 minutes avec une piste d’audit appropriée. Le problème pour les workflows d’agents est que les tokens expirent et doivent être rafraîchis, ce qui ajoute de la friction précisément quand vous souhaitez que les agents s’exécutent sans interruption. Consultez Tradeoffs clé de compte de service vs. impersonation pour l’analyse complète sur le moment où chaque approche est appropriée.
Perspectives d’évolution
Les serveurs MCP officiels de Google pour BigQuery, Cloud SQL et d’autres services déplacent l’authentification de la couche shell vers la couche protocole. Au lieu qu’un agent exécute des commandes gcloud dans votre shell et hérite (ou se batte avec) de votre état global, l’agent parle à un serveur MCP qui gère ses propres credentials.
Pour le travail multi-projet, c’est la direction architecturalement correcte. Le mode d’échec à surveiller est la dérive de contexte : votre IDE ouvert sur le projet du Client A pendant que le processus MCP en arrière-plan est encore authentifié sur le Client B. Les fichiers mcp_config.json au niveau du projet évitent cela. L’écosystème est encore en maturation début 2026, mais c’est la bonne direction.