Vercel a déployé la version 7 de son AI SDK avec une fonctionnalité de contexte d'outil à portée limitée (scoped tool context) qui oblige chaque outil d'un agent IA à ne recevoir que les secrets qu'il déclare explicitement. En limitant l'exposition, les développeurs peuvent empêcher les outils tiers de voir accidentellement toutes les informations d'identification stockées dans leur environnement.

Pourquoi ce changement est important

Les agents IA assemblent souvent plusieurs services externes — recherche de commandes, création de tickets, traitement de paiements — chacun nécessitant ses propres clés API ou URL. Le raccourci habituel consiste à transmettre l'objet process.env complet à chaque outil :

execute(input, { context: process.env })

Ce modèle crée une extension implicite de privilèges : l'ajout d'un nouvel outil lui accorde instantanément l'accès à tous les secrets existants, y compris les mots de passe de base de données ou les jetons de paiement, sans qu'aucun signal ne soit levé lors de la revue de code. Le risque est qu'un outil compromis ou buggé divulgue soudainement des identifiants qui ne lui étaient pas destinés.

Comment fonctionne le contexte d'outil à portée limitée

Dans l'SDK 7, un outil déclare un schéma de contexte (context schema) — une définition basée sur Zod des champs exacts dont il a besoin. Lorsque l'agent invoque un outil, l'appelant fournit un objet toolsContext qui ne contient que ces champs déclarés. L'SDK valide la structure avant l'exécution, et toute clé manquante ou supplémentaire provoque une erreur.

Une démo minimale montre deux outils ayant des besoins distincts :

  • lookupOrder – nécessite baseUrl pour appeler un service de commande interne.
  • createTicket – nécessite supportToken pour ouvrir un ticket de support.

Chaque outil exporte un contextSchema qui liste sa clé unique requise. Lorsque l'agent s'exécute, il passe :

{
  lookupOrder: { baseUrl: "https://orders.internal" },
  createTicket: { supportToken: "s3cr3t-token" }
}

Seul lookupOrder voit baseUrl ; createTicket n'y touche jamais, et vice-versa. L'SDK impose cette limite au moment de l'exécution, transformant une dépendance cachée en une liste de capacités explicites que les réviseurs peuvent auditer.

Avantages pour la sécurité

  • Limite l'exposition des données – les identifiants restent là où ils sont nécessaires.
  • Valide le contexte – les champs incorrects ou manquants interrompent l'exécution.
  • Rend les capacités explicites – les réviseurs peuvent voir exactement ce que chaque outil peut accéder.
  • Réduit le rayon d'impact (blast radius) – si un outil est compromis, l'attaquant ne gagne que les secrets auxquels cet outil était autorisé.

Cette fonctionnalité ne remplace pas le sandboxing traditionnel. Les développeurs doivent toujours employer la rédaction de logs (log redaction), des contrôles de sortie réseau (network egress controls) et une rotation régulière des jetons. Le contexte à portée limitée est une frontière ; il ne scelle pas la pièce.

Ce que les développeurs doivent ajuster

  1. Définir un schéma pour chaque outil – utilisez la bibliothèque Zod fournie avec l'SDK.
  2. Passer un toolsContext restreint – évitez le process.env universel.
  3. Réviser les agents existants – identifiez les secrets qui peuvent être retirés des appels d'outils.
  4. Ajouter des tests automatisés – assurez-vous que la validation du contexte échoue lorsqu'une donnée supplémentaire est injectée.

Un démarrage rapide ressemble à ceci :

mkdir scoped-tools && cd scoped-tools
npm init -y
npm install ai zod
npm install -D typescript tsx @types/node

Créez demo.ts, déclarez le contextSchema de chaque outil et lancez-le avec tsx demo.ts. L'SDK générera une erreur si vous essayez de donner à un outil un secret qu'il n'a pas demandé.

Contre-argument

Certaines équipes pourraient arguer que les définitions de schémas supplémentaires ajoutent du code répétitif (boilerplate) et ralentissent le prototypage. Bien que ce soit vrai, le coût est modeste — seulement quelques lignes par outil — et le gain de sécurité augmente avec le nombre de services intégrés. Dans les environnements manipulant des données de paiement ou des informations personnelles, le compromis est difficile à ignorer.

À surveiller ensuite

  • Métriques d'adoption – les premiers utilisateurs signalent moins d'incidents de fuite de secrets.
  • Outils communautaires – des plug-ins qui génèrent automatiquement des schémas de contexte à partir de fichiers de configuration.
  • Futures versions de l'SDK – des indices suggèrent que Vercel pourrait étendre les contextes à portée limitée pour inclure des permissions réseau et des limites de débit (rate-limit caps).

Si vous construisez déjà des agents IA avec l'SDK de Vercel, la première étape consiste à auditer votre utilisation actuelle de process.env. Identifiez la valeur unique qui peut être retirée de tous les appels d'outils et remplacez le modèle universel par un toolsContext à portée limitée. Le résultat est une posture de sécurité plus robuste sans sacrifier la flexibilité qui rend les agents IA puissants.