Securiser les agents IA en production : identite et controle d'acces

Les premiers assistants IA déployés en entreprise avaient un rôle relativement passif. Ils répondaient à des questions, résumaient des documents ou généraient du contenu. Leur impact s'arrêtait à la production d'informations.

Les architectures agentiques changent complètement cette logique.

Aujourd'hui, un agent peut ouvrir un ticket Jira, modifier un CRM, lancer un workflow CI/CD, envoyer un e-mail, déclencher un remboursement Stripe ou enchaîner plusieurs appels API de manière autonome.

À partir du moment où un agent agit sur des systèmes réels, une question devient incontournable :

Qui agit réellement ?

Ce n'est pas une question de fournisseur de modèle, de framework ou de protocole. C'est une question d'architecture.

---

Une nouvelle catégorie d'identité

Pendant des années, les architectures de sécurité ont reposé sur deux catégories d'identités :

• les utilisateurs humains ;
• les identités techniques (applications, services, microservices).

Les agents IA n'appartiennent complètement à aucune de ces catégories.

Ils raisonnent, choisissent des outils, adaptent leurs actions au contexte et exécutent parfois plusieurs dizaines d'opérations successives.

Ils constituent une nouvelle catégorie d'identité que nous appellerons dans cet article l'identité agentique.

Définition

Une identité agentique est l'ensemble des informations permettant d'identifier un agent, de déterminer pour le compte de qui il agit, de connaître les limites de son autonomie et de reconstruire chacune de ses décisions.

Cette définition servira de fil conducteur pour le reste de l'article.

---

Une clé API n'est pas une identité

Les premières implémentations d'agents suivent souvent cette architecture.

Application
      │
      ▼
 Clé API LLM
      │
      ▼
   Agent IA

Cette représentation est pratique.

Elle est également trompeuse.

La clé API identifie votre application auprès du fournisseur du modèle.

Elle n'identifie pas l'agent qui agit dans votre système d'information.

Deux agents peuvent partager la même clé API tout en disposant de responsabilités totalement différentes.

L'identité de l'agent appartient donc à votre architecture, pas au fournisseur de modèles.

---

Le modèle ne réalise jamais directement une action

On entend souvent :

« Claude a supprimé une commande. »

ou

« GPT a créé un remboursement. »

En réalité, un modèle de langage ne fait qu'émettre une proposition.

Votre infrastructure décide ensuite :

• si cette action est autorisée ;
• avec quelles permissions ;
• pour quel utilisateur ;
• sur quelles ressources.

Utilisateur
      │
      ▼
Application
      │
      ▼
Agent Runtime
      │
propose une action
      ▼
Policy Engine
      │
      ▼
Outil métier
      │
      ▼
Système cible

Cette séparation entre raisonnement et exécution constitue l'un des principes fondamentaux des architectures agentiques modernes.

---

La véritable question est la responsabilité

Une entreprise doit pouvoir répondre, plusieurs semaines après un incident :

• Quel agent a agi ?
• Pour quel utilisateur ?
• Dans quel tenant ?
• Quelle politique a autorisé cette opération ?
• Quel outil a été invoqué ?

Un journal indiquant uniquement :

« Le modèle a appelé updateCustomer() »

n'apporte pratiquement aucune valeur.

Une architecture moderne doit permettre de reconstruire l'intégralité de la chaîne de décision.

---

Une identité est toujours contextuelle

Le même agent peut intervenir :

• pour plusieurs utilisateurs ;
• dans plusieurs organisations ;
• sur plusieurs environnements ;
• avec des permissions différentes selon la tâche.

Son identité ne se résume donc jamais à un simple identifiant.

Agent
 ├ identité
 ├ utilisateur représenté
 ├ tenant
 ├ environnement
 ├ session
 └ permissions temporaires

Le contexte fait partie intégrante de l'identité.

---

Les architectures historiques ne répondent pas à cette problématique

OAuth, OpenID Connect, Kubernetes Service Accounts ou les identités de workloads répondent principalement à une question :

Quel composant demande l'accès à une ressource ?

Les agents IA ajoutent une dimension supplémentaire :

Pourquoi cette action est-elle réalisée, pour le compte de qui et dans quelles limites ?

C'est cette différence qui justifie une nouvelle couche de gouvernance.

---

Avant de parler de JWT ou de rbac

La plupart des articles commencent immédiatement par les technologies :

• JWT ;
• OAuth ;
• RBAC ;
• Vault ;
• rotation des secrets.

Toutes sont importantes.

Mais elles arrivent trop tôt.

Avant de choisir une technologie, il faut définir ce qu'est l'identité d'un agent et quelles informations elle doit porter.

C'est précisément l'objectif du chapitre suivant, qui introduit un Agent Identity Reference Model indépendant des fournisseurs, des frameworks et des modèles de langage.

À retenir

Les modèles évolueront.

Les frameworks changeront.

Les protocoles apparaîtront puis disparaîtront.

En revanche, toute architecture agentique devra toujours répondre à une même question :

Qui agit réellement, pour le compte de qui, avec quelles permissions et sous quel contrôle ?

Définition

Un Agent Identity Reference Model est un modèle conceptuel décrivant les informations minimales qu'une plateforme doit connaître pour identifier un agent, déterminer au nom de qui il agit, décider des actions qu'il peut réaliser et assurer la traçabilité complète de son activité.

Une fois que l'on considère un agent comme une véritable identité logicielle, une nouvelle question apparaît immédiatement :

De quelles informations une plateforme a-t-elle réellement besoin pour autoriser un agent à agir ?

La plupart des implémentations répondent avec une liste de mécanismes techniques : un JWT, une clé API, quelques permissions et parfois un rôle RBAC.

En réalité, ces mécanismes n'expriment qu'une partie de l'identité. Pour qu'un agent puisse agir de manière sûre, il faut répondre à plusieurs questions indépendantes.

Vue d'ensemble

Couche	Question	Exemples de technologies
Identity	Qui est cet agent ?	UUID, SPIFFE ID
Authentication	Peut-il prouver son identité ?	JWT, OAuth 2.0, mTLS
Delegation	Pour le compte de qui agit-il ?	OAuth, OIDC
Authorization	Que peut-il faire ?	RBAC, ABAC, Cedar, OPA
Secrets	Comment accède-t-il aux ressources ?	Vault, AWS Secrets Manager
Observability	Peut-on expliquer chaque décision ?	OpenTelemetry
Revocation	Peut-on l'arrêter immédiatement ?	Token revocation

Les couches sont indépendantes

Une erreur fréquente consiste à mélanger plusieurs responsabilités.

Un JWT ne décide pas des permissions. Un moteur de politiques ne prouve pas l'identité. Un gestionnaire de secrets n'autorise aucune action.

Chaque couche répond à une responsabilité unique. Cette séparation permet de remplacer une technologie sans remettre en cause l'architecture globale.

Schéma du modèle

                         Identity
                              │
            ┌─────────────────┴─────────────────┐
            │                                   │
    Authentication                    Delegation
            │                                   │
            └─────────────────┬─────────────────┘
                              ▼
                      Authorization
                              │
             ┌────────────────┴────────────────┐
             │                                 │
         Secret Access                 Observability
             │                                 │
             └────────────────┬────────────────┘
                              ▼
                         Revocation

Identity n'est pas authentication

Ces deux notions sont souvent confondues.

L'identité décrit qui est l'agent.

L'authentification vérifie qu'il est bien celui qu'il prétend être.

Être authentifié ne signifie jamais être autorisé.

Les six couches

1. Identity

Chaque agent possède un identifiant stable, une version, un propriétaire et un environnement d'exécution.

agent:
  id: support-agent
  version: 2.3.1
  owner: customer-support
  environment: production

2. Authentication

L'authentification permet de prouver cette identité au moyen d'un JWT, d'OAuth, de mTLS ou d'une identité de workload.

3. Delegation

Un agent agit rarement pour son propre compte. Il agit pour un utilisateur, un tenant ou un processus métier.

4. Authorization

Les autorisations modernes reposent de plus en plus sur des moteurs de politiques.

Les principaux modèles sont :

• RBAC
• ABAC
• PBAC
• ReBAC

Les architectures agentiques privilégient généralement PBAC, capable d'évaluer le contexte d'exécution.

Exemple Node.js :

const decision = await policyEngine.evaluate({
  identity,
  tool: "refundOrder",
  amount: 75,
  tenant: "acme",
});

if (!decision.allow) {
  throw new ForbiddenError(decision.reason);
}

await refundOrder();

5. Secrets

Le modèle ne manipule jamais directement les secrets.

Il exprime une intention ; l'application récupère les secrets auprès d'un gestionnaire dédié.

6. Observability

Chaque décision doit être traçable : identité, utilisateur représenté, politique appliquée, résultat et durée d'exécution.

7. Revocation

Toute identité doit pouvoir être désactivée immédiatement afin d'empêcher toute nouvelle action.

À retenir

Les modèles changent.

Les frameworks évoluent.

Les protocoles apparaissent puis disparaissent.

En revanche, une architecture devra toujours répondre aux mêmes questions :

• Qui agit ?
• Pour le compte de qui ?
• Que peut-il faire ?
• Comment protège-t-on les ressources ?
• Comment expliquer les décisions ?
• Comment arrêter immédiatement cet agent ?

Tant que ces questions trouvent une réponse, votre architecture restera valable indépendamment du fournisseur de modèles ou du framework utilisé.

Le Agent Identity Reference Model présenté au chapitre précédent est volontairement indépendant des technologies.

Il répond à une question d'architecture :

Quelles informations faut-il manipuler pour sécuriser un agent ?

Ce chapitre répond à une autre question :

Comment implémenter concrètement ce modèle dans une application moderne ?

La bonne nouvelle est qu'il n'est pas nécessaire d'inventer une nouvelle pile de sécurité. La plupart des entreprises possèdent déjà les briques nécessaires.

Une architecture de référence

                  Utilisateur
                        │
                        ▼
              Identity Provider
                        │
                        ▼
             Application métier
                        │
                        ▼
                 Agent Runtime
        ┌───────────────┼────────────────┐
        ▼               ▼                ▼
 Policy Engine   Secret Manager    Observability
        │
        ▼
    Tool Gateway
        │
   ┌────┼───────────────┐
   ▼    ▼               ▼
 CRM PostgreSQL      Stripe

Le modèle de langage n'est volontairement pas le centre du schéma.

Il produit des propositions.

Le runtime applique les politiques de sécurité.

Le runtime devient le point de contrôle

Chaque appel d'outil doit être traité comme une décision de sécurité.

Avant d'exécuter une action, le runtime doit répondre à plusieurs questions :

• Qui est l'agent ?
• Pour quel utilisateur agit-il ?
• Quel tenant est concerné ?
• Cette action est-elle autorisée ?
• Les limites de sécurité sont-elles respectées ?

Autrement dit, le runtime devient un Policy Enforcement Point (PEP).

Un middleware node.js plutôt que de la logique dispersée

Une bonne pratique consiste à centraliser les contrôles.

export async function authorizeTool(ctx, toolName) {

  const decision = await policyEngine.evaluate({
    identity: ctx.identity,
    tool: toolName,
    tenant: ctx.tenant,
    delegatedUser: ctx.user.id
  });

  if (!decision.allow) {
    throw new ForbiddenError(decision.reason);
  }

  return decision;
}

Puis chaque outil utilise ce middleware.

server.registerTool({
  name: "refundOrder",

  async execute(args, ctx) {

    await authorizeTool(ctx, "refundOrder");

    return refundService.execute(args);
  }
});

Ainsi, les règles de sécurité restent indépendantes du modèle et du prompt.

Un JWT transporte une identité, il ne décide de rien

Un JWT peut contenir des informations utiles :

{
  "agent":"support-agent",
  "tenant":"acme",
  "delegatedUser":"user-482",
  "scope":["orders.read","orders.update"]
}

Mais un JWT ne répond jamais à la question :

Cette opération est-elle autorisée maintenant ?

Cette décision appartient toujours au moteur de politiques.

Les permissions sont évaluées à chaque action

Dans une architecture agentique, les permissions ne sont pas figées au moment de la connexion.

Chaque appel d'outil constitue une nouvelle décision.

Par exemple, un remboursement peut dépendre :

• du montant ;
• du tenant ;
• du rôle de l'utilisateur représenté ;
• de l'environnement ;
• de la politique de risque.

Le runtime doit donc interroger un moteur de politiques avant chaque opération sensible.

Les outils représentent des capacités métier

Évitez d'exposer directement des primitives techniques.

À éviter :

executeSQL()
executeShell()
deleteCustomer()

Préférez des outils exprimant une intention métier.

findCustomer()
refundOrder()
updateShippingAddress()
generateInvoice()

Cette approche réduit fortement la surface d'attaque et simplifie les politiques d'autorisation.

Les secrets ne quittent jamais l'infrastructure

Le modèle ne devrait jamais recevoir une clé Stripe, un mot de passe PostgreSQL ou un token AWS.

Le runtime récupère ces secrets auprès d'un gestionnaire dédié.

import Stripe from "stripe";

const stripe = new Stripe(
  await secretManager.get("stripe-api-key")
);

Le modèle exprime une intention.

L'application réalise l'appel technique.

MCP ne remplace pas les contrôles

Le Model Context Protocol (MCP) standardise la découverte et l'invocation des outils.

Il ne décide jamais si un outil peut être utilisé.

Même si un serveur MCP expose :

deleteAllCustomers()

la décision finale appartient toujours :

• au runtime ;
• au moteur de politiques ;
• à votre architecture.

MCP décrit les capacités.

Votre plateforme décide lesquelles sont réellement accessibles.

Build ou buy ?

Toutes les équipes n'ont pas les mêmes besoins.

Taille du projet	Recommandation
Prototype	Règles codées dans le runtime
Quelques agents	RBAC simple
Multi-tenant	Policy Engine
Organisation réglementée	Cedar, OPA ou solution équivalente

Le passage à un moteur de politiques se justifie lorsque les règles deviennent nombreuses, évolutives ou partagées entre plusieurs agents.

Une architecture pérenne

L'un des principaux bénéfices de cette approche est son indépendance vis-à-vis des fournisseurs.

Vous pouvez remplacer :

• Claude par GPT ;
• GPT par Gemini ;
• LangGraph par CrewAI ;
• MCP par un autre protocole.

L'architecture de sécurité reste inchangée.

Votre runtime, vos politiques, vos secrets et vos journaux d'audit appartiennent à votre système d'information.

Ils constituent la véritable couche de confiance de votre plateforme.

À retenir

Le modèle de langage n'est jamais l'autorité de sécurité.

Il propose des actions.

Votre infrastructure décide si elles peuvent être exécutées.

À ce stade, une architecture moderne dispose :

• d'une identité pour chaque agent ;
• d'un mécanisme d'authentification ;
• d'un moteur de politiques ;
• d'une gestion centralisée des secrets.

Ces composants sont nécessaires, mais ils ne suffisent pas.

Une architecture n'est réellement sécurisée que si elle peut être auditée, expliquée et arrêtée à tout moment.

L'audit n'est plus un simple fichier de logs

Dans un système agentique, il ne suffit plus d'enregistrer qu'un endpoint a été appelé.

Chaque décision importante devrait produire un événement retraçant :

• l'identité de l'agent ;
• l'utilisateur représenté ;
• le tenant ;
• l'outil demandé ;
• la politique appliquée ;
• la décision (ALLOW ou DENY) ;
• le résultat de l'exécution.

Exemple :

{
  "timestamp": "2026-07-17T10:48:31Z",
  "agent": "support-agent",
  "delegatedUser": "user-482",
  "tenant": "acme",
  "tool": "refundOrder",
  "decision": "ALLOW",
  "policy": "refund-policy-v3",
  "durationMs": 91
}

Ces événements permettent de reconstruire une décision plusieurs semaines après son exécution.

Les anti-patterns les plus fréquents

1. Une clé API partagée

Tous les agents utilisent la même identité.

Conséquence : impossible de savoir lequel est responsable.

2. Les secrets transmis au modèle

Une clé Stripe ou un mot de passe SQL ne doivent jamais apparaître dans le contexte envoyé au LLM.

3. Des permissions définies dans le prompt

Un prompt ne constitue pas un mécanisme de sécurité.

Les règles d'autorisation doivent être implémentées côté infrastructure.

4. Des outils trop génériques

Évitez :

executeSQL()
executeShell()

Préférez :

createInvoice()
updateShippingAddress()

Les outils doivent représenter des intentions métier.

Une checklist d'audit

Avant une mise en production, vérifiez notamment :

• Chaque agent possède-t-il une identité unique ?
• Les utilisateurs représentés sont-ils identifiés ?
• Les autorisations sont-elles évaluées avant chaque appel d'outil ?
• Les secrets sont-ils stockés dans un Secret Manager ?
• Chaque décision est-elle journalisée ?
• Un agent peut-il être révoqué immédiatement ?
• Les outils exposent-ils des capacités métier plutôt que des primitives techniques ?

Si une réponse est négative, l'architecture mérite probablement d'être revue.

Zero trust appliqué aux agents

Les principes Zero Trust restent parfaitement adaptés aux architectures agentiques.

Chaque requête doit être :

• authentifiée ;
• autorisée ;
• tracée ;
• limitée au strict nécessaire.

Aucun agent ne devrait être considéré comme implicitement fiable.

Foire aux questions

Faut-il un JWT par agent ?

Pas nécessairement.

L'important est que chaque exécution dispose d'une identité authentifiable et contextualisée.

Rbac est-il suffisant ?

Pour un prototype, souvent oui.

Pour plusieurs agents, plusieurs tenants ou des règles dynamiques, un moteur de politiques devient rapidement préférable.

MCP sécurise-t-il les outils ?

Non.

MCP décrit les outils disponibles.

Les contrôles d'accès restent à la charge de votre plateforme.

Le modèle doit-il connaître les secrets ?

Jamais.

Le modèle formule une intention.

Le runtime réalise les appels techniques avec ses propres identités.

Conclusion

Pendant longtemps, la sécurité des applications s'est organisée autour des utilisateurs et des services.

Les architectures agentiques introduisent une troisième catégorie d'identité : l'agent autonome.

Cette évolution impose de repenser plusieurs fondations :

• l'identité ;
• la délégation ;
• l'autorisation ;
• la gestion des secrets ;
• l'observabilité ;
• la révocation.

Les technologies continueront d'évoluer.

Les modèles de langage seront remplacés.

Les frameworks changeront.

En revanche, les questions fondamentales resteront les mêmes :

• Qui agit ?
• Pour le compte de qui ?
• Avec quelles permissions ?
• Comment expliquer chaque décision ?
• Comment interrompre immédiatement un agent ?

Les organisations capables d'y répondre disposeront d'une architecture durable, indépendante des fournisseurs de modèles et suffisamment robuste pour faire évoluer leurs systèmes agentiques dans le temps.