Autoriser l'action, pas simplement le langage.
RADM crée une frontière d'exécution déterministe entre les agents IA et les outils d'entreprise. Il évalue l'autorité, la provenance, l'état opérationnel et l'effet visé avant qu'une action lourde de conséquences ne soit autorisée à s'exécuter.
Agent IA
Probabiliste
Action proposée
Pas encore permise
Tajalli RADM
Déterministe
- identité
- autorité
- provenance
- contrat d'effet
- état de conséquence
- politique
Courtier d'exécution
Frontière exclusive
Outils · API · Systèmes
Conséquence
01Principe
Proposer n'est pas être autorisé.
Les agents modernes peuvent raisonner de manière probabiliste. L'autorité dans l'entreprise doit rester explicite.
RADM permet de conserver des modèles d'IA puissants tout en plaçant un contrôle déterministe sur ce que ces modèles sont autorisés à provoquer.
- Proposition
- ≠Permission
- Preuve
- ≠Autorité
- Une demande plausible
- ≠Un effet autorisé
02Catégorie
Pas un garde-fou. Un plan de contrôle de l'autorité et de l'exécution.
Filtres de prompts et garde-fous de LLM inspectent le langage. RADM ne dépend pas de la détection d'une instruction malveillante : il décide si un effet précis est autorisé au regard de l'identité, de la provenance et de l'état — et seulement alors le laisse s'exécuter.
Approche classique
La sortie du modèle tient lieu d'autorisation. Tout ce que l'agent est amené à demander, l'outil le reçoit.
Avec Tajalli RADM
- 01Agent
- 02Action proposée
- 03Évaluation autorité + provenance + effet
- 04Décision déterministe
- 05Exécution contrôlée
- ALLOW
Autorité, provenance et effet sont établis.
- REQUIRE APPROVAL
L'effet exige une décision humaine explicite.
- BLOCK
L'action n'est pas autorisée à s'exécuter.
03Capacités
Chaque action lourde de conséquences franchit une même frontière déterministe.
- 01
Autorité à l'exécution
L'autorité est évaluée au moment de l'exécution, au regard de droits explicites — jamais déduite de la confiance du modèle ou de la formulation d'une demande.
- 02
Contrôle centré sur l'effet
Les décisions portent sur ce qu'une action va provoquer, déclaré par des contrats d'effet, et non sur le texte qui l'a demandée.
- 03
Identité des outils
Chaque outil et chaque opération portent une identité stable et une surface d'effet déclarée. Un outil inconnu n'est pas exécutable par défaut.
- 04
Liaison de provenance
Les arguments sont liés à leurs sources. Un contenu arrivé par un canal non fiable ne peut pas devenir en silence une instruction dotée d'autorité.
- 05
État suffisant pour juger la conséquence
RADM évalue au regard de l'état opérationnel nécessaire pour juger la conséquence — soldes, périmètres, environnements, effets antérieurs.
- 06
Approbation humaine
Lorsque la politique l'exige, les effets sont mis en attente pour une décision humaine explicite et attribuable avant validation.
- 07
Courtier d'exécution
Les actions permises s'exécutent via un courtier exclusif. L'agent ne détient pas les identifiants qui lui permettraient de contourner la frontière.
- 08
Validation / Annulation
Les effets en plusieurs étapes sont préparés avec des points explicites de validation et d'annulation, afin qu'une exécution partielle ne devienne pas un résultat non revu.
- 09
Reçus et rejeu
Chaque décision et chaque effet constaté produisent un reçu. Les décisions peuvent être rejouées au regard de l'état et de la politique enregistrés.
- 10
Isolation multi-locataire
Autorité, état et politique sont cloisonnés par locataire. Le contexte d'un locataire ne peut pas conférer d'autorité dans un autre.
- 11
Fonctionnement fermé par défaut
État manquant, outil inconnu ou provenance invérifiable conduisent à ne pas exécuter. L'absence de preuve n'est jamais une permission.
04Intégration
Placer une frontière d'exécution déterministe entre le raisonnement autonome et l'action lourde de conséquences.
L'architecture est conçue pour arbitrer les actions partout où un agent atteint un système capable de modifier un état.
Conçu pour arbitrer
- Outils MCP
- Appels de fonctions
- API REST internes
- Actions SaaS d'entreprise
- Opérations cloud
- Opérations sur bases de données
- Processus financiers
- Automatisation de workflows
- Agents IA internes
- Environnements multi-agents
- Outillage d'entreprise à privilèges
Le périmètre d'intégration est confirmé pour chaque déploiement. Les surfaces listées décrivent une compatibilité d'architecture, non des connecteurs natifs.
05Évaluation contrôlée
Validé dans des environnements contrôlés de benchmark d'autorisation et d'actions d'agents.
RADM
Benchmarks d'autorisation contrôlés
Une configuration à contrats de vérité terrain du benchmark public AgentDojo, et un jeu distinct de cas d'autorisation réservés.
- cas légitimes dans la configuration AgentDojo évaluée à contrats de vérité terrain
- 949 / 949
- attaque évaluée réussie dans cette configuration
- 0 / 949
- cas d'autorisation réservés dans une évaluation contrôlée distincte
- 484
- de rappel sur ce jeu réservé
- 100%
- de taux de faux positifs sur ce jeu réservé
- ~0.495%
Les résultats de benchmark valent pour les contrats et configurations évalués indiqués. Ils ne constituent pas une preuve de sécurité universelle.
06Questions sur RADM
Ce que les équipes plateforme et sécurité demandent sur RADM.
RADM est-il un garde-fou de LLM de plus ?
Pas au sens habituel. La plupart des garde-fous au niveau du modèle portent sur le contenu généré, les prompts ou les réponses.
RADM est conçu autour de l'autorité à l'exécution et du contrôle des effets. La question n'est pas seulement « Qu'a dit l'agent ? » mais « Qu'est-il réellement autorisé à provoquer ? »
Un agent peut-il contourner RADM et appeler l'outil directement ?
L'architecture de déploiement la plus robuste place l'exécution lourde de conséquences derrière une frontière d'arbitrage exclusive.
Si un agent conserve un accès direct et indépendant à l'outil sous-jacent, aucune couche intermédiaire ne peut honnêtement revendiquer un contrôle complet de l'exécution sur ce chemin de contournement.
L'architecture de déploiement compte donc autant que le moteur de décision à l'exécution.
Que se passe-t-il lorsque l'autorité est ambiguë ?
RADM ne résout pas l'ambiguïté en faveur de l'exécution.
Si l'identité, l'autorité, la provenance ou l'état pertinent pour la conséquence ne peuvent être établis pour une action, celle-ci est bloquée ou orientée vers un circuit d'approbation explicite, selon la politique. L'ambiguïté est une raison de s'arrêter, pas de deviner.
RADM doit-il inspecter les prompts ?
Pas comme mécanisme principal. RADM statue sur l'action proposée : quel outil, quelle opération, quels arguments, issus de quelles sources, pour quel effet.
Le contexte du prompt ou de la conversation peut être consigné comme élément de provenance lorsque c'est utile, mais l'autorisation ne dépend pas de l'interprétation du langage du modèle.
Des humains peuvent-ils rester dans la boucle d'approbation ?
Oui. La politique peut exiger une approbation humaine explicite pour certains effets, seuils ou outils.
Ces actions sont préparées au lieu d'être exécutées, mises en attente d'une décision humaine attribuable, puis validées ou annulées. L'approbation fait elle-même partie de l'enregistrement de la décision.
RADM peut-il arrêter toute attaque ou toute action dangereuse d'une IA ?
Aucun système responsable ne devrait l'affirmer.
RADM est conçu pour réduire des catégories précises d'exécutions non autorisées ou invalides, en imposant une frontière d'autorité déterministe explicite devant les outils lourds de conséquences. Sa protection dépend de la frontière d'intégration, des preuves disponibles, de la couverture des politiques et de l'ensemble des actions effectivement arbitrées par le système.
Des résultats de benchmark contrôlé ne doivent pas être présentés comme une preuve de sécurité universelle.
Demandes entreprises
Les agents peuvent rester probabilistes. L'autorité n'a pas à l'être.
Étudions la mise en place de RADM devant les outils que vos agents utilisent déjà, en commençant en mode observation.