Introducing Contextual Access : le troisième niveau de sécurité pour les agents IA

Par Sterling Dreyer (Ingénieur fondateur), Guru Sattanathan (Architecte solutions principal)

TL;DR : Arcade.dev sécurise l’exécution des outils par les agents IA grâce à l’identité déléguée, l’accès aux outils scopé et la gouvernance. Nous étendons aujourd’hui ce modèle de sécurité avec le Contextual Access : des hooks runtime qui vous permettent d’injecter votre propre logique de sécurité, de conformité et de filtrage directement dans le pipeline d’exécution des outils, sur trois points d’accroche, via n’importe quel webhook à chaque appel d’outil.

Le problème : faire passer les agents IA par la sécurité

Voici ce qui se passe quand une entreprise tente de déployer des agents IA : l’agent doit accéder à des outils comme SAP, Snowflake, Gmail ou vos API internes, et l’équipe sécurité veut des réponses. Qui a autorisé cet agent ? Qu’est-ce qu’il peut faire ? Que se passe-t-il si quelque chose tourne mal ?

C’est là que la plupart des agents ne passent pas en production. Les équipes commencent par créer des comptes de service, générer des clés API et embarquer des tokens dans le contexte du LLM. Très vite, c’est ingérable : de nouvelles identités à gouverner, de nouveaux identifiants à sécuriser. Et encore, si les agents passent la revue de sécurité.

Arcade a été conçu pour résoudre ce problème et vous permettre de livrer des agents IA que la sécurité approuvera. Intégré au runtime MCP, Arcade offre trois niveaux de sécurité : l’application des politiques, l’accès aux outils scopé et le Contextual Access. Aucun compte de service à gérer, aucun identifiant dans le contexte du LLM, et pas de nouveau cycle d’approbation à chaque agent déployé.

Comment Arcade résout la sécurité pour les agents IA en entreprise

Le modèle de sécurité d’Arcade fonctionne en trois couches. Elles sont indépendantes et cumulatives, ce qui vous offre une défense en profondeur pour l’exécution des outils par les agents IA, le tout directement intégré au runtime MCP.

Couche 1 : Application des politiques pour les agents IA - Votre identité, vos règles

Quand un agent IA exécute un outil via Arcade, il n’utilise pas un compte de service et ne génère pas de nouvelle clé API. L’agent agit au nom de l’utilisateur, avec son identité existante, régie par les politiques que votre équipe IT gère déjà : Entra ID, Okta, ou ce que vous utilisez aujourd’hui.

Si Jim, dans la chaîne d’approvisionnement, peut accéder à trois codes de transaction SAP, c’est exactement ce que peut faire un agent opérant en son nom, pas un octet de plus. Et les tokens utilisateurs ne touchent jamais le contexte du LLM. Arcade gère l’intégralité du cycle OAuth dans un runtime isolé : l’agent ne voit jamais un identifiant ni un secret.

Couche 2 : Accès aux outils scopé par agent - Accès ≠ Capacité

La couche 1 garantit qu’un agent ne peut pas dépasser les permissions de l’utilisateur. La couche 2 vous permet de restreindre davantage ce que l’agent est autorisé à faire dans le cadre de ces permissions.

Un utilisateur peut avoir un accès Gmail complet : lecture, envoi, suppression. Mais son agent doit-il avoir le droit de supprimer ? Les équipes qui construisent les agents définissent la boîte à outils de chaque agent pour n’exposer que les opérations qui ont du sens. Nous le faisons pour nos propres agents internes : une assistante chez Arcade dispose d’un accès Gmail complet au compte du CEO en tant qu’utilisatrice, mais nous avons retiré le scope de suppression de son agent. L’agent du responsable logistique accède aux outils de suivi des commandes. L’agent de l’équipe finance accède aux outils de reporting. Chaque agent ne voit que ce qui le concerne et ne peut faire que ce qui a été approuvé.

Ces deux couches à elles seules placent Arcade bien au-delà de ce que d’autres runtimes d’agents peuvent offrir nativement. Pour la plupart des déploiements, elles couvrent la grande majorité des exigences de sécurité en entreprise. Mais « la plupart » n’est pas « tout ».

Couche 3 : Contextual Access - Des politiques sophistiquées au runtime

Les couches 1 et 2 répondent à la question : qui peut faire quoi. Mais certaines politiques ne peuvent pas s’exprimer uniquement via l’identité et le scopage des outils. L’agent d’un utilisateur peut être scopé pour envoyer des emails, mais rien dans le modèle OAuth de Gmail ne peut le limiter aux domaines internes.

Nous lançons aujourd’hui le Contextual Access, un système qui vous permet d’injecter votre propre logique de sécurité, de conformité et de filtrage directement dans le pipeline d’exécution des outils d’Arcade. Trois points d’accroche vous permettent d’intercepter les appels d’outils aux moments qui comptent : avant que l’agent découvre un outil, avant qu’un outil s’exécute, et après qu’un outil a renvoyé son résultat.

Exemples concrets de politiques :

Injection de prompt : Un agent soumet une requête SAP avec un payload embarqué. Avec le Contextual Access, la requête ne s’exécute jamais.

Sorties d’outils empoisonnées : Un outil de scraping renvoie du contenu contenant des instructions de détournement. Le payload est supprimé avant que le LLM ne le voie.

Données personnelles dans les réponses : Un outil renvoie des enregistrements clients avec des champs sensibles. Ils sont anonymisés avant d’entrer dans le contexte du modèle.

Schémas suspects : Une séquence d’appels ressemble à une exfiltration de données. Elle est signalée et bloquée en temps réel.

Les trois points d’accroche

Le Contextual Access vous offre trois points d’accroche dans le runtime MCP d’Arcade, pour les appels d’outils API comme MCP server. Chacun est un point de contrôle indépendant où vous injectez votre propre logique via des webhooks ; ensemble, ils forment un pipeline de sécurité complet autour de chaque appel d’outil.

Hook d’accès : contrôlez la visibilité des outils

Le hook d’accès est un point d’accroche dans le runtime d’Arcade qui vous permet de contrôler quels outils un agent peut découvrir. Il se déclenche quand un agent demande la liste des outils disponibles, avant même que l’agent sache qu’un outil existe.

Connectez-le à votre moteur de droits, votre logique RBAC personnalisée ou n’importe quel système externe qui prend des décisions d’accès. L’agent demande les outils disponibles, Arcade appelle votre webhook, et votre système renvoie la liste filtrée. Un agent qui ne peut pas voir un outil ne peut pas l’appeler, et un agent qui ne peut pas l’appeler ne peut pas être manipulé pour en abuser.

Le support batch permet à un seul appel webhook d’évaluer l’intégralité du catalogue d’outils, sans problème N+1 lors du listing de centaines d’outils. Les résultats sont mis en cache avec un TTL (time-to-live) configurable pour ne pas ajouter de latence à chaque tour de conversation. L’invalidation du cache se fait automatiquement quand les configurations de hooks changent, ou vous pouvez la déclencher manuellement via l’API.

Quand il s’exécute :

• Listing des outils : filtre le catalogue avant que l’agent ne le voie
• Avant l’exécution : revalide au cas où les permissions auraient changé depuis le dernier cache

Hook de pré-exécution : contrôlez chaque appel d’outil

Le hook de pré-exécution est un point d’accroche dans le runtime d’Arcade qui vous permet de valider, transformer ou bloquer n’importe quel appel d’outil avant son exécution. C’est là qu’intervient l’application des politiques en temps réel. Vous pouvez attraper ce que l’identité et le scopage ne voient pas.

Ce que votre hook reçoit :

• Identité de l’outil (nom, toolkit, version)
• Tous les paramètres que l’agent passe à l’outil
• Contexte utilisateur (ID utilisateur, informations d’autorisation)

Ce que votre hook peut faire :

• Autoriser : continuer tel quel
• Autoriser avec modifications : écraser les paramètres, injecter des paramètres par utilisateur, mapper des IDs lisibles vers des UUID internes, router vers des backends spécifiques
• Refuser : bloquer l’exécution avec un motif renvoyé à l’agent

Un client dans les services financiers impose que les outils d’email n’envoient qu’au sein du domaine de l’organisation. Un client dans l’industrie valide que les codes de transaction SAP correspondent à l’affectation de l’utilisateur à son site. Un client dans la santé s’assure que les requêtes sur les dossiers patients incluent les paramètres de consentement requis.

Si votre hook de pré-exécution dit non, l’outil ne se déclenche jamais et le système en aval ne voit jamais la requête, ce qui maintient le rayon d’impact aussi réduit que possible.

Hook de post-exécution : contrôlez ce qui revient

Le hook de post-exécution est un point d’accroche dans le runtime d’Arcade qui vous permet de scanner, anonymiser ou bloquer la sortie d’un outil avant qu’elle n’atteigne le LLM. C’est votre dernier rempart avant que des données n’entrent dans le contexte du modèle.

Ce que votre hook reçoit :

• Tout le contexte de pré-exécution (identité de l’outil, paramètres, contexte utilisateur)
• ID d’exécution (corrèle avec le hook de pré-exécution pour une traçabilité bout en bout)
• Statut de succès/échec
• La sortie complète de l’outil

Ce que votre hook peut faire :

• Autoriser : renvoyer la sortie telle quelle
• Autoriser avec modifications : anonymiser des champs, transformer des données, supprimer du contenu sensible
• Refuser : remplacer entièrement la sortie par un message d’erreur ; l’agent ne voit jamais l’original

C’est ici que vous gérez l’anonymisation des données personnelles et que vous interceptez les payloads d’injection de prompt les plus dangereux : ceux embarqués dans les données renvoyées par les outils, pas dans les prompts utilisateurs, tout en capturant le contexte d’exécution complet pour les logs de conformité.

Le Contextual Access protège dans les deux sens : il sécurise les outils vis-à-vis de l’agent, et il sécurise l’agent vis-à-vis des outils.

Appliquer une sécurité composable et complexe avec le Contextual Access

Plusieurs hooks sur le même point d’accroche s’exécutent en pipeline, ordonnés par priorité. Chaque hook voit la sortie accumulée de tous les hooks précédents. Vous pouvez ainsi construire des protections sophistiquées qui s’appliquent automatiquement à chaque appel d’outil, sans qu’un seul hook ait besoin de connaître les autres.

Chaîne de pré-exécution : Le hook A enrichit les paramètres → le hook B les valide → le hook C journalise la requête finale.

Chaîne de post-exécution : Le hook A anonymise les données personnelles dans la sortie → le hook B scanne la sortie anonymisée pour détecter les injections de prompt → le hook C ne voit jamais les valeurs sensibles d’origine.

Chaîne d’accès : Le hook A renvoie le sous-ensemble d’outils accessibles à l’utilisateur → le hook B n’évalue que les outils ayant passé le hook A.

La chaîne s’arrête immédiatement quand un hook refuse ; les hooks suivants ne s’exécutent pas, car un seul refus suffit à bloquer l’appel.

Comment configurer le Contextual Access au niveau organisation et projet

Les hooks de Contextual Access se configurent à deux niveaux, et les deux s’exécutent toujours :

• Niveau organisation- Politiques à l’échelle de l’entreprise, appliquées à chaque projet
• Niveau projet- Règles spécifiques à l’équipe, scopées aux cas d’usage individuels

Le flux d’exécution suit une séquence stricte en trois phases :

Phase 1 : Hooks d’organisation (avant) : conformité à l’échelle de l’entreprise en premier

Phase 2 : Hooks de projet : validation et filtrage spécifiques à l’équipe

Phase 3 : Hooks d’organisation (après) : anonymisation des données personnelles et audit à l’échelle de l’organisation

Les modifications s’accumulent à travers toutes les phases. Si le hook pré-exécution de l’organisation injecte un paramètre de conformité, le hook pré-exécution du projet le voit. Si le hook post-exécution du projet anonymise un champ, le hook post-exécution de l’organisation voit la version anonymisée.

Comment contrôler les modes de défaillance avec le Contextual Access

Chaque hook de Contextual Access est configuré avec un mode de défaillance pour le cas où le webhook est inaccessible :

• fail_closed - Bloque l’opération. Pour les contrôles critiques en matière de sécurité où « je ne sais pas » signifie « non ».
• fail_open - Autorise l’opération. Pour les enrichissements non critiques comme les métriques ou les logs.

Vous configurez cela par hook, car une panne d’un scanner de données personnelles ne doit pas avoir le même impact qu’une panne d’un collecteur de télémétrie.

La prise en charge des tentatives est intégrée avec un nombre maximum de tentatives configurable, un backoff exponentiel, et des relances uniquement sur les erreurs transitoires (5xx, timeouts, erreurs de connexion).

Testez le Contextual Access en production sans risque

N’importe quel hook de Contextual Access peut être configuré en mode dry-run pour le tester avant sa mise en production. En dry-run :

• Votre webhook est appelé avec de vraies requêtes de production
• Mais rien n’est appliqué : l’exécution des outils se poursuit comme si le hook avait renvoyé « autoriser »

Cela vous permet de valider la logique d’un nouveau hook sur du trafic réel avant de l’activer. Vous voyez exactement ce qui aurait été bloqué, ce qui aurait été modifié, la latence qu’ajoute votre webhook, le tout sans toucher un seul workflow de production.

Webhooks : apportez vos politiques aux agents IA

Nous développons continuellement les façons d’appliquer les politiques de sécurité de votre organisation aux agents IA. Nous avons commencé par les webhooks parce qu’ils offrent le plus de flexibilité : vos politiques vous appartiennent, et deux entreprises ne gèrent jamais le contrôle d’accès de la même façon.

Un webhook vous permet d’implémenter exactement votre logique, dans votre langage, sur votre infrastructure, dès aujourd’hui. Le contrat est clair et bien défini :

• Authentification : Bearer token ou mTLS pour les réseaux zero-trust
• Vérifications de santé : Intervalles configurables avec statut sain/dégradé/défaillant visible dans le tableau de bord
• Spécification OpenAPI 3.0 complète : Disponible surGitHubavec les schémas de requête/réponse complets pour les trois points d’accroche
• Versioning : Chaque modification de configuration est versionnée avec support de rollback

Nous avons commencé par les webhooks, et nous continuerons à construire des intégrations directes avec des éditeurs de sécurité comme Snyk, des systèmes d’identité et de gestion des droits comme Sailpoint et Okta, et d’autres encore. Ils s’intègreront dans la même architecture de hooks, de sorte que vos configurations webhook existantes fonctionneront aux côtés des intégrations natives à mesure que votre stack évolue.

Pour commencer

Le Contextual Access est disponible dès aujourd’hui pour tous les clients Arcade.

• Lisez la documentation :Référence API complète, schémas de webhooks et guides de configuration.
• Déployez un webhook :Commencez par un simple pass-through et itérez.
• Configurez vos hooks :Access, Pre-Execution, Post-Execution : choisissez ce qui compte le plus en premier.
• Activez le dry-run : Validez sur du trafic réel avant d’appliquer
• Enchaînez et composez : Ajoutez des hooks progressivement à mesure que vos besoins évoluent

Nous publions des exemples de serveurs webhook pour vous aider à démarrer. La spécification complète de l’API webhook est disponibleon GitHub →

Inscrivez-vous gratuitement et commencez à construire → arcade.dev