La sécurité d’exécution des agents d’Arcjet place le contrôle au cœur de la boucle d’action de l’IA

Arcjet a lancé sa sécurité d’exécution des agents le 17 septembre, ajoutant des contrôles en temps réel pour les agents d’IA après leur mise en production. Le produit cible une lacune entre la surveillance d’un agent et l’arrêt de son action suivante. Cette distinction importe lorsque les agents peuvent envoyer des messages, mettre à jour des bases de données, émettre des remboursements ou appeler des outils internes.

La sortie de la sécurité d’exécution des agents d’Arcjet intervient alors que les fournisseurs de sécurité rivalisent pour contrôler cette nouvelle couche d’exécution. Les passerelles inspectent le trafic, les systèmes d’identité authentifient les acteurs et les plateformes d’observabilité enregistrent l’activité. Arcjet souhaite plutôt intégrer les contrôles de politique au chemin applicatif, là où l’action proposée par un agent peut encore être bloquée.

Cette architecture donne aux développeurs davantage de contexte pour chaque décision. Elle les oblige aussi à placer du code d’application des règles autour des actions conséquentes. Le pari central d’Arcjet est que les organisations accepteront ce travail d’intégration, car les contrôles externes ne peuvent pas accéder à suffisamment de détails applicatifs.

Le produit associe découverte des agents, application des règles au niveau des actions et enregistrements d’audit. Arcjet affirme que les équipes peuvent observer les agents via leur télémétrie existante, puis ajouter des contrôles préventifs grâce à des kits de développement logiciel et à des intégrations de frameworks.

Le lancement n’est donc pas une nouvelle promesse générale de rendre les modèles plus sûrs. C’est une tentative de définir où commence la responsabilité lorsque la sortie d’un modèle devient une opération réelle.

La sécurité d’exécution des agents d’Arcjet ajoute trois couches de contrôle

Arcjet réunit visibilité, prévention et éléments de preuve dans un même flux de travail de production.

La première couche est l’observation. Arcjet indique que les organisations peuvent transmettre l’activité des agents via OpenTelemetry, une norme ouverte de collecte des traces, métriques et journaux. Les équipes utilisant Claude peuvent également se connecter via la Compliance API d’Anthropic.

Ce processus d’ingestion constitue un inventaire des agents et des applications. Arcjet associe ensuite les sessions individuelles à l’agent qui les a produites. Les enquêteurs en sécurité peuvent examiner un flux de travail plus long au lieu de chercher parmi des prompts et appels d’outils déconnectés.

Cette approche repose en partie sur l’adoption croissante d’une télémétrie standardisée. Le projet OpenTelemetry développe des conventions d’observabilité des agents pour signaler les tâches des agents, l’activité des frameworks et les interactions avec les modèles.

Cette standardisation peut réduire le travail nécessaire pour découvrir des agents répartis entre différents frameworks. Toutefois, l’observation seule n’empêche pas une opération dangereuse. Elle enregistre ce qui s’est produit et fournit du contexte pour une analyse ultérieure.

La deuxième couche est l’application des règles. Arcjet place une décision de politique avant qu’un agent appelle un outil, une base de données, une interface de programmation d’application ou un modèle. L’application reçoit une réponse typée telle que autoriser, bloquer, masquer ou mettre en attente pour examen.

Une réponse typée est un résultat structuré que le code de l’application peut traiter de manière cohérente. Elle permet au flux de travail d’arrêter une action, de demander une approbation humaine ou de renvoyer une explication à l’agent.

Arcjet prend également en charge les contrôles après un appel. Ces contrôles peuvent inspecter un résultat avant qu’une autre étape du flux de travail l’utilise. Cela crée des contrôles autour de l’action proposée comme des informations qu’elle renvoie.

Selon l’entreprise, les politiques disponibles couvrent l’injection de prompts, l’exposition de données sensibles, les abus d’automatisation, les limites de débit et les quotas de ressources. L’injection de prompts survient lorsqu’un contenu non fiable manipule un modèle afin qu’il suive des instructions hostiles ou non prévues.

La troisième couche est l’audit. Arcjet enregistre la décision, la version de la politique, l’acteur, les entrées et le contexte d’exécution associé. Cet enregistrement doit montrer ce qu’un agent a tenté de faire et pourquoi le système l’a autorisé ou rejeté.

L’annonce de lancement corrigée de l’entreprise décrit le produit à travers ces trois fonctions : observer, appliquer et auditer. L’annonce indique que les politiques peuvent fonctionner avant et après des appels impliquant des modèles, des outils, des bases de données et des API.

Cette conception répond à un problème opérationnel précis. Un agent d’assistance peut lire un e-mail, interroger une base de données clients et préparer une réponse. Chaque étape peut sembler inoffensive lorsqu’elle est examinée isolément.

La séquence combinée peut néanmoins exposer des informations personnelles à une adresse ajoutée par un attaquant. Arcjet tente de conserver les étapes antérieures et d’évaluer le message sortant dans ce contexte historique.

Le fondateur et directeur général David Mytton a déclaré à SiliconANGLE qu’un résultat risqué peut se développer à travers plusieurs actions individuellement raisonnables. La couverture initiale du lancement a également signalé des intégrations avec plusieurs grands frameworks d’agents.

Ces intégrations comprennent le Claude Agent SDK, OpenAI Agents SDK, LangChain, Mastra et Microsoft’s Agent Framework. La page produit plus générale d’Arcjet affirme prendre en charge 20 SDK et intégrations de frameworks.

Cette étendue compte, car les déploiements d’agents utilisent rarement un environnement d’exécution unique. Les organisations peuvent faire fonctionner des agents web, des workers de file d’attente, des assistants de programmation et des flux de travail planifiés par différentes interfaces.

Le produit d’Arcjet tente de relier ces environnements grâce à un modèle de décision partagé. Le changement le plus important n’est pas l’écran d’inventaire. C’est la possibilité de placer une décision obligatoire avant l’exécution d’une action.

La frontière de sécurité se déplace de l’accès vers l’action

Un agent authentifié peut toujours effectuer la mauvaise action avec des identifiants valides.

Le contrôle d’accès traditionnel demande si une identité peut entrer dans un système. Cela reste nécessaire, mais devient incomplet lorsqu’un logiciel peut interpréter des objectifs et sélectionner des actions de manière autonome.

Un employé peut autoriser un agent à utiliser une plateforme de service client. Cette autorisation ne signifie pas automatiquement que l’agent doit rembourser chaque transaction qu’il rencontre. Le montant autorisé, le compte, le moyen de paiement et la demande environnante restent déterminants.

Le même problème apparaît dans les flux de travail de programmation. Un agent de programmation peut disposer d’un accès légitime au dépôt tout en n’étant pas autorisé à exposer des secrets, modifier les paramètres de déploiement ou exécuter des commandes destructrices.

L’accès permanent établit une frontière extérieure. Il ne confirme pas que chaque action au sein de cette frontière reflète l’intention actuelle de l’utilisateur.

Google a décrit un changement similaire dans son cadre Beyond Zero de 2026. La proposition évalue l’autorisation au niveau des actions individuelles sur des ressources précises, au lieu d’accorder un large accès à une application.

Arcjet poursuit une version plus ciblée et déployable de cette orientation. Il vérifie l’action à l’aide du contexte disponible dans l’application. Ce contexte peut inclure l’identité, la route, le nom de l’outil, les arguments typés, les étapes antérieures et l’utilisation cumulée.

Prenons un agent de comptabilité fournisseurs pouvant accéder à un système de planification des ressources de l’entreprise. La lecture d’une facture et le déclenchement d’un paiement ont lieu dans la même application. Leurs conséquences diffèrent pourtant considérablement.

Une passerelle réseau peut reconnaître un trafic dirigé vers cette application. Elle peut ne pas comprendre si la fonction sous-jacente lit un dossier fournisseur ou modifie des coordonnées bancaires.

Un contrôle dans le code peut inspecter la fonction et ses arguments. Il peut appliquer une politique à la lecture d’une facture et une autre au déblocage de fonds.

Cette distinction explique le positionnement d’Arcjet face aux plans de contrôle externes. Une passerelle peut centraliser le routage des modèles, l’authentification, la journalisation et les contrôles de contenu. Arcjet soutient qu’une partie du contexte applicatif se perd lorsque l’application des règles se déplace hors du code qui exécute l’action.

Les deux approches ne s’excluent pas mutuellement. Une entreprise peut utiliser une passerelle pour le trafic des modèles et Arcjet pour des appels d’outils spécifiques. La question importante est de savoir quel contrôle détient la décision finale.

Arcjet affirme que les décisions locales ajoutent moins d’une milliseconde de surcharge. L’entreprise annonce entre 20 et 30 millisecondes lorsqu’une décision nécessite son service cloud.

Ces chiffres sont des affirmations de l’entreprise, et non des résultats de benchmarks indépendants. Ils excluent aussi des contrôles plus lourds. Arcjet affirme que sa détection spécialisée d’injection de prompts peut ajouter environ 100 millisecondes avant un appel à un fournisseur.

La latence devient importante lorsqu’une exécution d’agent contient des dizaines d’actions. Un léger délai peut s’accumuler, notamment lorsque l’évaluation distante des politiques ou la détection basée sur un modèle intervient à répétition.

L’architecture crée donc un problème de placement des politiques. Les équipes doivent décider quelles actions exigent des règles locales, des contrôles distants, une analyse de contenu ou un examen humain.

Une consultation en lecture seule peut ne nécessiter qu’une autorisation et une journalisation. Un remboursement de valeur élevée peut justifier plusieurs contrôles et une approbation manuelle. Appliquer le processus le plus strict à chaque action ralentirait les flux de travail et accroîtrait les frictions opérationnelles.

La réponse d’Arcjet est une application granulaire des règles. Les équipes d’ingénierie peuvent conserver les règles près du gestionnaire protégé, tandis que les équipes de sécurité peuvent gérer des politiques distantes sans demander un nouveau déploiement de l’application.

Les règles fondées sur le code facilitent les tests, la revue et le contrôle de version. Les règles distantes permettent aux équipes de sécurité d’ajuster les seuils dans tous les services. Leur combinaison peut préserver la responsabilité de l’ingénierie tout en donnant aux équipes de sécurité une capacité d’intervention plus rapide.

Elle peut aussi soulever des questions de gouvernance. Une application peut contenir une politique tandis que le service distant en applique une autre. Les équipes ont besoin de règles de priorité claires, d’un historique des modifications et d’un comportement défini en cas de défaillance.

Si le service cloud de politique devient indisponible, l’application doit décider si elle bloque ou poursuit l’opération. Cette décision dépend des conséquences de l’action et de la tolérance de l’organisation aux interruptions.

Le produit rend la frontière de l’action visible, mais il n’élimine pas ces choix de conception. Il donne aux équipes un endroit où les encoder.

L’application des règles dans le code défie les passerelles et les tableaux de bord de sécurité

Le principal affrontement oppose les contrôles capables d’interrompre une action aux systèmes qui observent surtout le trafic autour d’elle.

Les tableaux de bord de sécurité peuvent identifier un comportement inhabituel après l’arrivée de la télémétrie. Cela reste utile pour les enquêtes, la réponse aux incidents et la conformité. Cela n’arrête pas nécessairement un remboursement ou une mise à jour de base de données déjà effectués.

Les passerelles d’IA peuvent intervenir avant qu’une requête ou une réponse de modèle les traverse. Elles peuvent détecter du contenu hostile, restreindre les fournisseurs ou appliquer des limites de dépenses à un point centralisé.

Cependant, l’opération conséquente d’un agent peut avoir lieu après l’interaction avec le modèle. Le modèle propose un appel d’outil, puis le code applicatif l’exécute contre un autre système. Une passerelle qui ne voit que le trafic des modèles peut manquer l’opération finale.

Arcjet place sa protection dans ce chemin d’exécution. L’application demande une décision de politique immédiatement avant d’appeler la fonction concernée. Cela permet à la politique d’inspecter des arguments typés au lieu d’inférer l’intention à partir du langage naturel.

Un remboursement d’un montant modeste et un autre d’un montant beaucoup plus élevé peuvent sembler similaires au niveau réseau. Le gestionnaire applicatif connaît le montant exact, le compte, la devise et le contexte utilisateur.

La contrepartie est l’étendue du déploiement. Une passerelle centralisée peut couvrir de nombreuses applications une fois que le trafic y est acheminé. Les contrôles dans le code doivent être insérés aux frontières identifiées par les développeurs.

Arcjet tente de réduire cette charge grâce aux SDK, aux hooks et aux intégrations de frameworks. L’entreprise indique également prendre en charge l’observation via OpenTelemetry sans exiger de modifications de l’application.

Pourtant, la découverte et l’application restent deux choses différentes. La télémétrie peut révéler un agent inconnu sans placer automatiquement un contrôle bloquant avant chaque action menée par cet agent.

Cette distinction crée une séquence d’adoption. Une équipe plateforme peut d’abord inventorier l’activité des agents. Les développeurs choisissent ensuite les actions à fort impact et ajoutent des garde-fous autour de celles-ci.

La séquence est pragmatique, mais la couverture peut rester inégale. Un service peut protéger les remboursements tandis qu’un autre laisse les modifications de compte sans garde-fou. Les équipes de sécurité ont besoin d’éléments montrant quelles actions ne font l’objet d’aucune application de contrôle.

Les grands fournisseurs investissent des territoires qui se chevauchent. Cisco a étendu AI Defense en février 2026 avec des protections d’exécution pour l’utilisation d’outils par les agents et la gouvernance des interactions. Son extension d’AI Defense met l’accent sur la protection des environnements réseau, cloud et sur site.

L’approche de Cisco bénéficie d’une présence établie dans la sécurité d’entreprise. Arcjet met en avant une intégration native aux applications et l’adoption par les développeurs.

D’autres produits se concentrent sur les pare-feux de modèles, le red teaming IA, l’identité, le routage via passerelle ou l’observabilité. Ces catégories se recoupent de plus en plus à mesure que les fournisseurs suivent l’activité des agents, des prompts jusqu’à l’exécution des outils.

Arcjet doit donc démontrer que le contexte au niveau des actions permet de prendre de meilleures décisions, et pas seulement de générer davantage de journaux. Les acheteurs voudront des preuves que les politiques bloquent des attaques significatives sans interrompre le travail légitime.

Les exemples actuels de l’entreprise sont intuitifs. Ils comprennent les limites de remboursement, les appels d’outils non autorisés, le masquage des données sensibles, les boucles incontrôlées et les séquences d’actions dangereuses.

Les cas les plus difficiles concernent l’intention ambiguë. Une politique peut facilement refuser un outil indisponible pour un rôle. Il est plus difficile de déterminer si un appel d’outil autorisé correspond à l’objectif mal spécifié d’un utilisateur.

Les politiques déterministes aident lorsque les organisations peuvent exprimer une règle claire. Une politique déterministe renvoie le même résultat pour les mêmes entrées connues, plutôt que de s’appuyer sur le jugement ouvert d’un modèle.

Les règles peuvent plafonner les dépenses, contraindre les ressources, exiger des approbations ou bloquer certaines catégories de données. Elles deviennent moins décisives lorsque le contexte dépend d’une signification métier nuancée.

Cette limite ne rend pas l’application de contrôles à l’exécution superflue. Elle définit la frontière entre les contrôles déterministes et la gouvernance fondée sur le raisonnement.

Le produit d’Arcjet met actuellement l’accent sur un socle d’application fiable. Une analyse plus riche des séquences peut s’appuyer sur cette base, mais elle a toujours besoin d’un mécanisme capable d’arrêter l’action qui en résulte.

C’est l’argument le plus solide de l’entreprise. Une meilleure détection offre une protection limitée lorsque l’application ne peut pas appliquer la décision avant l’exécution.

La partie la plus faible concerne la preuve opérationnelle. Arcjet n’a pas publié de vastes données tierces montrant les taux de faux positifs, l’adoption par les clients ou la réduction des incidents pour cette version.

Tant que ces résultats ne seront pas disponibles, les acheteurs doivent considérer les chiffres de performance et d’efficacité comme des affirmations du fournisseur. Les déploiements pilotes devraient exécuter les politiques en mode observation avant d’activer le comportement de blocage.

L’injection de prompt n’est qu’une partie du problème à l’exécution

Un filtre de prompt ne peut pas remplacer l’autorisation, le moindre privilège, les budgets ou les contrôles d’approbation.

L’injection de prompt attire l’attention car un attaquant peut dissimuler des instructions dans des e-mails, des documents, des sites web ou la sortie d’un outil. Un agent peut traiter ce contenu non fiable comme une instruction et modifier son comportement.

Le filtrage peut identifier certains schémas hostiles avant que le contenu n’atteigne un modèle. Il ne peut pas déterminer de manière fiable si chaque action métier qui en découle est autorisée.

Une demande bien formulée peut tout de même dépasser l’autorité d’un utilisateur. Un compte compromis peut envoyer des instructions apparemment inoffensives. Un agent peut également commettre une erreur sans rencontrer d’attaque.

La sécurité à l’exécution doit donc séparer l’évaluation du contenu de l’autorisation des actions. Une vérification demande si une entrée paraît hostile. Une autre demande si cet acteur peut effectuer cette opération sur cette ressource.

Les recommandations d’OWASP sur l’autonomie excessive préconisent de réduire au minimum les extensions, les autorisations et l’autonomie. Elles recommandent également une approbation humaine avant les actions à fort impact.

Arcjet peut fournir le point d’application de certains de ces contrôles. Il ne peut pas décider de la tolérance au risque d’une organisation ni redéfinir un agent doté d’identifiants excessivement étendus.

Un agent disposant d’autorisations de base de données inutiles demeure dangereux. Les politiques de blocage réduisent l’exposition, mais le principe du moindre privilège devrait empêcher l’agent d’accéder à de nombreuses opérations sensibles dès le départ.

L’approbation humaine exige également une mise en œuvre rigoureuse. Un écran de confirmation doit afficher l’outil réel, la destination, les arguments et la conséquence. Demander aux utilisateurs d’approuver un résumé rédigé par l’agent peut masquer le détail dangereux.

Selon ses documents produit, Arcjet renvoie une décision de mise en attente pour révision. L’application environnante contrôle toujours la manière dont cette révision est présentée et les personnes habilitées à l’approuver.

Les registres d’audit créent un autre ensemble de préoccupations. Les prompts et les paramètres des outils peuvent contenir des informations personnelles, des identifiants, des documents internes ou des données clients.

Arcjet indique que les vérifications sensibles peuvent s’exécuter localement tandis que les éléments justifiant la décision sont stockés séparément. Il propose le stockage via son cloud, un environnement à locataire unique, un cloud virtuel privé ou une infrastructure gérée par le client.

Les organisations doivent vérifier quels champs quittent leur environnement. Elles doivent également définir la conservation, le stockage régional, les contrôles d’accès, les procédures de suppression et les responsabilités de réponse aux incidents.

Le produit annonce un rapport SOC 2 Type II couvrant la sécurité, la disponibilité et la confidentialité. Cette assurance porte sur les contrôles organisationnels, mais elle ne valide pas chaque politique ou intégration d’agent.

La détection fondée sur les séquences introduit une incertitude supplémentaire. Relier les actions entre les sessions peut révéler un risque progressif que des vérifications isolées manquent. Cela peut aussi produire des historiques incomplets ou incorrects lorsque les identifiants sont incohérents.

Les conventions OpenTelemetry peuvent aider à normaliser les enregistrements. Elles ne garantissent pas que chaque framework émette un contexte équivalent ou conserve les mêmes informations d’identité.

Les développeurs doivent propager les identifiants de corrélation à travers les files d’attente, les tâches en arrière-plan et les frontières de services. Un contexte manquant peut faire apparaître un même workflow comme plusieurs exécutions sans rapport.

Une collecte excessive crée le problème inverse. Enregistrer chaque prompt, argument d’outil et sortie peut étendre la quantité de données sensibles accessible à la plateforme de supervision.

Les équipes de sécurité doivent équilibrer le niveau de détail utile à l’enquête et la minimisation des données. Une piste d’audit utile devrait prouver la décision sans copier automatiquement chaque charge utile sensible.

Les faux positifs constituent un autre défi. Un détecteur d’injection de prompt peut signaler des discussions légitimes sur la sécurité, des instructions de malware citées ou du contenu client.

Arcjet recommande un déploiement en mode dry-run, qui enregistre les décisions sans les appliquer. Cela permet aux équipes de comparer les blocages proposés au comportement réel de l’application avant d’activer une règle.

Les dry runs sont précieux, mais ils nécessitent une revue structurée. Les équipes doivent étiqueter les faux positifs, mesurer les cas manqués et tester les chemins d’échec plutôt que d’observer passivement un tableau de bord.

Une politique peut également devenir obsolète. De nouveaux outils, arguments, classes de données et processus métier changent la signification d’une action. Des enregistrements de politiques versionnés aident les enquêteurs à comprendre quelle règle s’appliquait à un moment donné.

Ils ne garantissent pas que la règle soit restée appropriée. Les responsables de la sécurité et de l’application doivent revoir les politiques à mesure que le workflow évolue.

Ces limites renforcent le principal compromis. Déplacer l’application des contrôles dans le code apporte un contexte utile, mais répartit aussi les responsabilités entre les services et les équipes.

Arcjet doit rendre ce modèle distribué plus facile à gouverner qu’un assemblage de vérifications d’autorisation personnalisées. Sinon, les acheteurs pourraient gagner une couche de politiques supplémentaire sans obtenir un contrôle cohérent.

Le prochain test porte sur les preuves en production, pas sur l’étendue des fonctionnalités

Le lancement d’Arcjet comptera si les clients peuvent démontrer une couverture, de faibles perturbations et des interventions réussies dans de vrais workflows d’agents.

Le premier signal à surveiller est l’adoption au-delà des environnements de démonstration. Arcjet devrait montrer comment les équipes inventorient les agents, identifient les actions conséquentes et font passer certaines politiques du dry run à l’application.

Des déploiements de production nommés préciseraient les workflows que les acheteurs privilégient. Les opérations de support, le développement logiciel, la finance et l’accès aux données internes présentent des risques et des exigences de latence différents.

Les preuves les plus solides incluraient le temps de déploiement, la couverture des actions protégées, les taux de faux positifs et le nombre d’actions arrêtées avant l’exécution. Ces mesures mettraient à l’épreuve l’affirmation centrale d’Arcjet.

Le deuxième signal est l’interopérabilité. Arcjet répertorie actuellement des intégrations avec des frameworks d’agents et assistants de programmation majeurs. Le marché jugera si ces intégrations préservent un contexte utile dans des environnements hétérogènes.

Les organisations standardisent rarement tous leurs agents sur un seul framework. Un workflow peut commencer dans une interface de chat, se poursuivre dans une file d’attente et se terminer dans un service personnalisé.

Arcjet doit relier ces étapes sans forcer chaque équipe à adopter un seul système d’orchestration. La prise en charge d’OpenTelemetry fournit une couche de découverte plausible, tandis que les garde-fous SDK assurent l’application des contrôles.

L’écart entre ces couches exigera de l’attention. Les acheteurs ont besoin d’une vue claire des agents découverts dont les actions conséquentes restent non protégées.

Les rapports de couverture pourraient devenir l’une des fonctionnalités les plus précieuses du produit. Ils permettraient aux équipes de sécurité de distinguer la visibilité du contrôle préventif réel.

Le troisième signal est la réaction de la concurrence. Cisco et d’autres fournisseurs d’entreprise ajoutent déjà la gouvernance des interactions d’agents et la protection à l’exécution.

Si ces entreprises s’implantent davantage dans les gestionnaires d’applications, la distinction architecturale d’Arcjet se réduira. Si elles restent concentrées sur l’inspection centralisée, Arcjet pourra soutenir que son contexte au niveau du code comble une lacune persistante.

Les fournisseurs de frameworks d’agents peuvent également ajouter des points d’ancrage de politiques natifs. Cette évolution pourrait aider Arcjet en créant des points d’application communs, ou réduire la demande pour une plateforme distincte.

Le marché est susceptible de prendre en charge des contrôles en couches. L’identité, l’inspection via passerelle, l’autorisation des actions, la télémétrie et la revue humaine répondent à différents modes de défaillance.

Le défi pour l’acheteur est d’empêcher que le chevauchement ne se transforme en complexité. Chaque service de décision supplémentaire crée des exigences de configuration, de latence, de journalisation et de disponibilité.

L’opportunité immédiate d’Arcjet est de devenir le dernier point de contrôle des politiques avant l’exécution d’une fonction conséquente. Son risque est de devenir un tableau de bord supplémentaire que les équipes déploient largement mais appliquent de façon limitée.

Les développeurs qui évaluent la sécurité à l’exécution des agents Arcjet devraient commencer par un workflow limité. Ils devraient cartographier les entrées, les identités, les outils, les accès aux données, les étapes d’approbation et les actions irréversibles.

Ils peuvent ensuite protéger l’appel le plus conséquent et exécuter la règle en mode dry-run. Les évaluateurs devraient examiner les cas légitimes comme les cas adversariaux avant d’activer un blocage.

Les équipes de sécurité devraient également tester le comportement en cas d’indisponibilité du service. Un service de remboursement, un outil d’écriture dans une base de données de production et un outil de recherche de documents ne devraient pas partager une même politique d’échec par défaut.

Enfin, les équipes devraient vérifier les éléments d’audit obtenus. Un enquêteur doit pouvoir reconstituer la décision sans exposer inutilement des données sensibles.

Le lancement met en lumière une véritable évolution de la sécurité de l’IA. Les agents créent des risques par leurs actions, et non uniquement par les sorties des modèles. Les contrôles doivent donc suivre le workflow jusqu’au point où le logiciel modifie un autre système.

Arcjet a proposé une mise en œuvre concrète de cette idée. Les prochains mois devraient montrer si son approche dans le code fournit un contrôle cohérent dans de vraies organisations.

Pour les développeurs, la question pratique est désormais précise : quelle action d’agent causerait le plus de dégâts si elle était exécutée incorrectement aujourd’hui ? Commencez par là, vérifiez l’identité et le contexte environnants, puis imposez une décision exécutoire avant l’appel.