Zapier repense la gouvernance des agents IA autour de règles basées sur les ressources

Zapier a récemment publié une rétrospective technique détaillant comment il a repensé l'architecture des autorisations et des approbations pour Sidekick, son agent IA d'espace de travail. L'entreprise s'est éloignée des prompts fragiles centrés sur les outils au profit d'un moteur de sécurité déterministe basé sur les ressources, conçu pour éliminer la fatigue d'approbation et prévenir les effets secondaires inattendus lors de l'exécution.

Ce qui s'est passé

Selon le Zapier Blog, le système d'autorisations initial de Sidekick classait les actions par types d'outils — exécutant automatiquement les opérations en lecture seule tout en s'arrêtant pour demander l'approbation de l'utilisateur pour les actions d'écriture, de modification ou de suppression. Cependant, cette première implémentation présentait d'importantes failles architecturales. Les demandes d'autorisation étaient liées aux onglets de navigateur ouverts, disparaissant si un onglet était fermé ou rafraîchi, tandis que les actions échouées déclenchaient à plusieurs reprises des prompts redondants. Les opérations de lecture de routine généraient également des cartes, faisant perdre les prompts importants dans le bruit.

Plus critique encore, Zapier a découvert une division interne du système : les capacités intégrées de Sidekick et les scripts de code personnalisés qu'il écrivait pour interagir avec les applications fonctionnaient sur deux moteurs d'autorisations distincts avec des règles incohérentes. De plus, les règles étaient attachées aux outils plutôt qu'aux objets — demandant l'autorisation d'utiliser un "outil d'écriture" générique plutôt que de protéger des documents, comptes ou chemins de répertoire spécifiques.

Pour résoudre cela, Zapier a reconstruit la sécurité de Sidekick autour d'autorisations basées sur les ressources. Les règles sont désormais attachées directement aux fichiers, applications connectées, sites web ou automatisations, maintenant l'application des règles quel que soit le mode d'exécution de l'action par l'agent. Zapier a établi une logique d'évaluation déterministe stricte : les règles explicites "Jamais" prévalent sur toutes les actions, suivies des prompts "Demander d'abord", permettant une exécution silencieuse uniquement lorsqu'aucune règle bloquante n'existe. De plus, Zapier a déplacé les prompts d'approbation du fil de discussion linéaire vers un panneau d'entrée dédié et une boîte de réception globale persistante, tout en codant en dur des garde-fous qui empêchent l'agent de proposer des autorisations globales.

Pourquoi cela importe aux créateurs d'agents et aux responsables opérationnels

Pour les petites équipes qui construisent ou déploient des agents IA en production, la rétrospective technique de Zapier met en lumière un défi d'infrastructure fondamental : la gouvernance humaine dans la boucle (HITL) ne peut pas être traitée comme un simple prompt au niveau du chat, mais doit être conçue comme un moteur de règles backend étatful et conscient des ressources. Les autorisations au niveau des outils offrent des limites opérationnelles faibles car le risque est défini par la ressource cible — par exemple envoyer un message à un canal Slack global versus un DM à un seul utilisateur.

Un excès de prompts conduit les utilisateurs à approuver réflexivement, tandis que les architectures sans prompts risquent une perte totale de confiance après une seule mauvaise exécution. En découplant l'état d'approbation des fils de conversation actifs et en imposant des surcharges déterministes rigides où le refus d'une action l'emporte toujours, les orchestrateurs peuvent accorder aux agents une autonomie opérationnelle sans mettre en danger les données critiques de l'entreprise.

Que faire cette semaine

1. Déplacer l'évaluation des autorisations des outils vers les ressources cibles : Refactorez votre couche d'orchestration d'agent afin que les limites de sécurité évaluent l'actif de destination (par ex., une table de base de données spécifique ou un chemin de dossier) plutôt que l'appel de fonction lui‑même.
2. Appliquer des surcharges de politique déterministes codées en dur : Mettez en place un moteur de règles explicite en dehors de la fenêtre de contexte du modèle où les règles de blocage rejettent inconditionnellement l'exécution avant tout appel d'outil LLM.
3. Découpler l'état humain dans la boucle de l'interface de chat : Stockez les demandes d'approbation dans une file d'attente serveur persistante afin que les portes d'exécution en attente survivent aux onglets de navigateur fermés et aux tâches de fond de longue durée.

Sources

• How much should an AI decide without asking you first? — Zapier Blog