Lorsqu'un agent IA transporte ses propres identifiants et communique directement avec des services externes, il se comporte moins comme un logiciel destiné aux employés que comme un prestataire disposant d'une carte de société sans aucun superviseur. Vous ne pouvez pas voir ce qu'il a touché, qui a approuvé l'accès, ou pourquoi une conversation a coûté dix fois plus cher qu'une autre. Les journaux se fragmentent à travers une douzaine de services. Les questions se multiplient.
Quel outil l'agent a-t-il réellement invoqué ? Qui lui a donné la permission d'accéder à cette base de données ? Pourquoi l'exécution de mardi a-t-elle consommé quarante mille tokens alors que celle de lundi n'en a utilisé que cinq ? Combien avons-nous réellement dépensé ?
Sans une couche de contrôle centrale située entre les utilisateurs, les modèles et les services, ces questions restent sans réponse. Vous avez besoin d'un plan unique qui enregistre chaque connexion une seule fois, n'expose que l'ensemble restreint de fonctions dont un agent a réellement besoin, et enregistre chaque exécution dans son intégralité. Cet article détaille un laboratoire avancé utilisant deco Studio comme plan de contrôle local. Vous allez le configurer, connecter un serveur Model Context Protocol sécurisé, exposer exactement une fonction autorisée et observer ce qui se passe lorsqu'un agent tente de dépasser ses limites.
Le problème des identifiants dispersés
Imaginez une configuration d'équipe typique. Un développeur connecte un agent à une API de recherche en utilisant une clé personnelle. Un autre branche le même agent à une base de données de production parce que la démo semblait sans danger. Un troisième ajoute un outil de consultation de facturation pour que l'agent puisse « aider avec les factures ». Chaque connexion est invisible pour les autres. L'agent a désormais un accès direct à la recherche, aux données de production et aux dossiers financiers, mais l'équipe ne dispose d'aucune liste unifiée de ce qui est actif.
Lorsque les identifiants résident à l'intérieur de l'agent, la gouvernance s'effondre. Vous ne pouvez pas révoquer l'accès de manière centralisée car la clé se trouve dans la mémoire de l'agent ou dans son fichier d'environnement local. Vous ne pouvez pas auditer l'utilisation car le service externe ne voit qu'un appel API provenant d'un client automatisé anonyme. Les surprises de coûts apparaissent plusieurs jours plus tard sur une facture cloud, et à ce moment-là, plus personne ne se souvient quel prompt a déclenché le pic.
Construire votre plan de contrôle dans deco Studio
deco Studio résout ce problème en agissant comme un hub local. Vous l'exécutez sur votre propre machine, et il devient l'unique endroit où résident les configurations. Au lieu de disperser les clés API et les définitions d'outils entre les agents, vous enregistrez une connexion une seule fois à l'intérieur de Studio. Ensuite, vous décidez exactement quelles fonctions chaque agent peut voir.
Considérez cela comme l'installation d'un standard téléphonique. Tous les câbles arrivent dans une seule pièce. Vous choisissez quelles lignes se connectent à quels départements, et vous gardez une trace de chaque appel.
Commencez par exécuter deco Studio localement. Une fois qu'il est opérationnel, vous centralisez la configuration. Chaque agent qui souhaite utiliser un outil doit désormais s'adresser au plan de contrôle, et non directement au service externe. Cela crée immédiatement un point de passage obligé où vous pouvez observer, filtrer et enregistrer les logs.
Connecter un serveur MCP sécurisé
Dans ce laboratoire, vous connectez un serveur Model Context Protocol. MCP est un standard ouvert permettant aux modèles d'interagir avec des outils externes, mais les standards ne garantissent pas la sécurité. L'étape critique ici est la sélectivité. Vous n'exposez pas aveuglément chaque endpoint proposé par le serveur. Vous enregistrez le serveur dans deco Studio, puis vous n'exposez qu'une seule fonction autorisée à votre agent de test.
Par exemple, votre serveur MCP pourrait proposer dix fonctions : lecture de fichier, écriture de fichier, requête de base de données, récupération réseau, et d'autres. Vous choisissez une opération inoffensive, peut-être une calculatrice isolée (sandboxed) ou une recherche en lecture seule sur des données synthétiques, et vous n'exposez que celle-là. Les neuf autres deviennent invisibles pour l'agent. Si l'agent les demande, le plan de contrôle renvoie un refus catégorique.
C'est le principe du moindre privilège rendu mécanique. L'agent reçoit ses capacités non pas par une instruction polie, mais par une barrière logicielle.
Tester la limite
Créez un agent de test et dirigez-le vers votre plan de contrôle deco Studio. Donnez-lui une tâche qui nécessite la seule fonction autorisée. Observez sa réussite. Les logs à l'intérieur de Studio montreront la requête du modèle, l'appel de l'outil routé via le plan de contrôle, l'exécution de la fonction et le résultat revenant au modèle. Vous pourrez lire tout le chemin dans une trace continue.
Now give the agent a second task that requires a function you deliberately excluded. The agent might attempt to reason its way around the limitation, or it might hallucinate that the tool exists. Either way, the call hits the control plane, the allowlist rejects it, and the execution fails. That failure is your proof that the boundary is software-enforced, not theoretical.
Do this with synthetic tasks first. Build a fake database full of generated user profiles. Let the agent query it. Verify the allowlist and the denials. Only after you trust the boundary should you even consider pointing the agent at production systems. Rushing to real data before you verify the wall is how secrets leak.
Reading the Full Path of a Run
deco Studio lets you inspect every layer of an execution. You see the raw model request: the prompt, the context window, the formatting. You see the tool call the model decided to make. You see the control plane route that call, the function execute, and the payload return. Finally, you see how the model consumes that result to form its answer.
This visibility answers the basic audit questions. You know which tool fired because the control plane logged it. You know who granted access because the configuration records sit in one local registry. You know why the run was expensive because you can count the tokens.
Counting What Matters
For every run, track four specific metrics. First, input and output tokens. These drive the bulk of model costs, and you need exact counts, not rough estimates. Second, separate model latency from tool latency. The time between your prompt and the model's response is different from the time the external service takes to answer a tool call. Confusing the two leads to misdiagnosed slowdowns. Third, calculate cost based on verified provider rates. Do not guess. Check your provider's pricing sheet and match it against the measured tokens. Fourth, compare successful calls against rejected unauthorized calls. A high rejection count means your agent is probing boundaries or your allowlist is misaligned with legitimate needs.
These numbers turn agent operations from a black-box subscription into an observable system. You can budget, optimize, and explain.
The Difference Between Local Control and Local Execution
Here is a lesson that trips up even careful builders. Running deco Studio on your machine gives you local control over configuration, but it does not guarantee local execution of the model itself. If you configure the agent to call an external provider such as OpenAI, Anthropic, or any hosted API, your prompts leave your machine. Studio manages the gate, but the data still crosses the network.
Always track these boundaries. Know which parts of the pipeline stay on localhost and which bits travel to someone else's server. If your data is sensitive, local control of the tool layer is not enough. You also need to know where the model inference happens. Do not confuse the comfort of a local dashboard with the reality of a remote model.
Instructions Are Not Authorization
One dangerous shortcut is trying to secure an agent through prompting. Telling the model, "Never call the delete function," is not a security control. It is a suggestion. Models can misinterpret instructions, jailbreak prompts, or simply make reasoning errors. Real security lives at the software boundary.
Use allowlists inside deco Studio to define exactly which functions are callable. Enforce those limits with server-side checks inside the control plane. The agent should discover its capabilities the way a user discovers file permissions: by hitting a hard limit, not by reading a friendly note. Security belongs in architecture, not in natural language.
Start Small, Stay Skeptical
Build your control plane one step at a time. One MCP server. One exposed function. One synthetic task. Verify that the agent succeeds where it should and fails where it must. Read the trace. Confirm the token counts. Then add the next tool.
Control is not a switch you flip. It is a habit of proving boundaries before you trust them. deco Studio gives you the local plane to practice that habit. Use it to turn a swarm of autonomous agents into a managed, observable, and bounded system.
Source: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost
Communauté d'apprentissage facultative : GyaanSetu AI sur Telegram