Modèle d'autorisation pour agent IA : identité utilisateur, droits d'outils, journaux d'audit et isolation des secrets

Une équipe donne le même token administrateur à un agent, avec l’idée que “de toute façon, c’est un système interne”. Résultat : l’utilisateur A envoie une requête, et l’agent lit l’enregistrement CRM de l’utilisateur B avec l’identité administrateur. Des autorisations mal conçues rendent un agent plus dangereux que l’absence d’agent.

Ce n’est pas un scénario inventé. MCP Security Best Practices classe explicitement token passthrough comme anti-pattern : cela contourne les contrôles de sécurité, casse l’audit trail et franchit les trust boundaries. L’OWASP AI Agent Security Cheat Sheet place aussi l’abus d’outils et l’escalade de privilèges parmi les risques centraux.

Le problème tient en trois questions : qui l’agent représente-t-il, sur quelle base appelle-t-il, et à quoi peut-il accéder ? Voici le plan d’ingénierie complet : table d’identité, liste des champs de permissions d’outils, étapes clés du Secret Vault, schema d’audit log avec règles de masquage, table de décision, checklist de dépannage et étapes de mise en place.

Mapping d’identité : qui l’agent représente-t-il ?

Quand un agent appelle un outil, les journaux et le système d’autorisation doivent d’abord répondre à une question : qui a déclenché l’appel, et au nom de qui l’opération est-elle exécutée ? Ces deux entités peuvent être identiques ou différentes. Les confondre provoque des dérives de droits et des audits impossibles à relire.

Tableau de référence des types d’identité

Type	actor	subject	Cas d’usage	Limite d’autorisation
user identity	Utilisateur A	Utilisateur A	Interaction directe avec l’utilisateur	Hérite des droits utilisateur
service account	system_bot	null	Tâches de fond, jobs planifiés	Droits système, indépendants d’un utilisateur
delegated token	workflow_123	Utilisateur A	Workflow automatisé autorisé par l’utilisateur	Scope du workflow, limité au périmètre accordé
tenant context	agent_456	tenant_B	Système multi-tenant	Isolation tenant, pas d’accès inter-tenant

Définition des champs : actor est l’entité qui déclenche l’appel, qu’il s’agisse d’un utilisateur, d’un agent, d’un workflow ou du système. Le journal enregistre son ID. subject est l’entité représentée, un utilisateur ou null. Dans une interaction utilisateur directe, actor=subject. Quand un compte système exécute une tâche de fond, subject=null. delegatedBy indique quel utilisateur a autorisé le workflow. tenantId identifie le tenant et sert à isoler les données en multi-tenant.

Selon la spécification MCP Authorization, les MCP servers doivent vérifier que l’access token a été émis pour eux comme intended audience. Le champ audience du token doit pointer vers l’identifiant de ressource du MCP server. Un token ne doit pas être placé dans l’URI query string, car les URI peuvent apparaître dans les logs, l’historique du navigateur et les caches proxy.

L’OWASP Access Control Cheat Sheet insiste sur deny by default, least privilege et la vérification à chaque requête. Le mapping d’identité est la première étape du contrôle : actor, subject et tenantId déterminent la décision d’autorisation qui suit.

Permissions d’outils : que peut appeler l’agent ?

Enregistrer un outil ne consiste pas seulement à définir name, description et input_schema. La référence des outils de l’OpenAI Agents SDK expose aussi des champs de permission et de contrôle d’exécution.

Table de décision des permissions d’outils

Contrôle de permission	Cas d’usage	Mise en œuvre	Risque
per-tool permission	Chaque outil a sa propre autorisation	Définir permission_level à l’enregistrement de l’outil, par exemple read/write/admin	Configuration plus complexe, matrice de permissions à maintenir
scope minimization	Moindre privilège progressif	Scope initial limité aux opérations peu risquées, extension par scope challenge pour les droits élevés	Gestion des scopes plus coûteuse, ajustement dynamique nécessaire
whitelist	Liste d’outils autorisés	Autoriser uniquement certaines combinaisons, comme read_customer + summarize	Coût de maintenance, flexibilité parfois réduite
approval	Approbation humaine	Les outils needs_approval=true se mettent en pause avant l’exécution et attendent l’approbation	L’approbation ajoute de la latence et pèse sur l’expérience utilisateur

Les champs d’outils de l’OpenAI Agents SDK incluent is_enabled pour contrôler l’activation à l’exécution. On peut désactiver dynamiquement un outil selon le rôle utilisateur, le tenant ou le workflow context. needs_approval indique qu’une approbation humaine est requise. Après approbation, tool_input_guardrails s’exécute encore. tool_input_guardrails valide les entrées, par exemple la détection de PII ou les limites de paramètres. tool_output_guardrails valide les sorties, par exemple via un filtrage de contenu.

MCP Security Best Practices recommande un moindre privilège progressif pour la scope minimization : le scope initial ne doit contenir que des opérations de découverte ou de lecture à faible risque, comme read:metadata et list:resources. Les opérations à privilèges élevés doivent être ajoutées par un scope challenge précis. Les scopes wildcard/full-access sont à éviter.

L’OWASP AI Agent Security Cheat Sheet recommande per-tool permission scoping : utiliser des tool sets différents selon le trust level, exiger une autorisation explicite pour les opérations sensibles et fail closed quand le contrôle échoue.

Isolation des secrets : comment l’agent utilise-t-il les clés ?

Un agent ne devrait pas détenir directement des API keys longues en clair. L’OWASP Secrets Management Cheat Sheet recommande de centraliser et de standardiser la gestion des secrets. Le système de gestion des secrets lui-même doit aussi couvrir Authentication, Authorization, Accounting et lifecycle.

Tableau des modes d’accès aux secrets

Mode	Risque	Cas d’usage	Exemple
Possession directe, par exemple .env en clair	Risque de fuite élevé, pas de traçabilité, pas de révocation	Déconseillé	API key codée en dur
Variables d’environnement	Risque de fuite dans les logs, traçabilité et révocation faibles	Déploiement sur une seule machine	process.env.API_KEY
secret vault	Gestion centralisée, stockage chiffré, audit trail, révocation	Production	AWS Secrets Manager, HashiCorp Vault
secret reference	L’agent détient une reference et obtient un token court à l’exécution	Multi-tenant, contexte à haute sécurité	vault.get(secretRef)

Le cycle de vie d’un secret comporte quatre étapes : creation génère un token court plutôt qu’une clé longue ; rotation renouvelle régulièrement le secret, par exemple tous les 30 jours, avec un processus automatisé qui met à jour le secret et notifie les systèmes concernés ; revocation fournit une désactivation d’urgence en cas de fuite ; expiration fixe une date de fin, après laquelle le secret cesse de fonctionner automatiquement.

MCP Security Best Practices indique clairement que token passthrough est un anti-pattern : transmettre directement le token OAuth d’un utilisateur à l’agent contourne les contrôles de sécurité, casse l’audit trail et franchit les trust boundaries. La bonne approche consiste à émettre un delegated token au moment où l’utilisateur autorise l’agent : court, limité en scope et avec une audience explicite.

Les principes OWASP Secrets Management sont centralize, least privilege, automate et auditing. L’accès aux secrets suit le moindre privilège. La maintenance manuelle augmente le risque de fuite et d’erreur ; rotation, revocation et expiration font partie du lifecycle.

Audit log : qui a appelé quoi, et quand ?

Un audit log doit permettre de reconstituer “qui a appelé quel outil au nom de qui, quel objet a été consulté, et quel résultat a été obtenu”, tout en masquant paramètres et secrets.

Audit Log Schema

Champ	Description	Règle de masquage
traceId	ID de la chaîne d’appel, réutilise le concept trace/runId de N156	Ne pas masquer
timestamp	Heure de l’appel, ISO 8601	Ne pas masquer
actor	Entité qui déclenche l’appel	Ne pas masquer
subject	Entité représentée	Ne pas masquer
tool	Nom de l’outil	Ne pas masquer
action	Type d’opération, read/write/delete	Ne pas masquer
resource	Objet ciblé	Masquer : customer_id → cust_***
outcome	Résultat, success/failure/denied	Ne pas masquer

Règles de masquage : ne pas enregistrer token, secret, password, email, phone ou PII. Enregistrer who/what/when/where/outcome. Exemple : customer_id=12345 devient cust_*** ; email=user@example.com devient e***@***.com ; token=Bearer xxx devient Bearer *** ; password=secret123 n’est pas enregistré.

Selon l’OWASP Logging Cheat Sheet, les journaux de sécurité doivent aider l’enquête, l’audit et la supervision, mais ne doivent pas contenir de mots de passe, session IDs, access tokens ou données personnelles sensibles. Ils doivent enregistrer des informations traçables comme who/what/when/where/outcome.

La famille audit and accountability de NIST SP 800-53 rappelle que l’audit log est la dernière ligne de défense du système de permissions. Quand une vérification échoue, la raison doit être écrite : actor sans droit, subject sans droit sur la cible, scope insuffisant.

Table de décision du modèle d’autorisation : choisir la bonne combinaison

Mapping d’identité, permissions d’outils, isolation des secrets et audit logs ne sont pas des contrôles séparés. Ils se contraignent ensemble. Voici les combinaisons de contrôles pour différents scénarios.

Scénario	identity type	tool permission	secret access	audit log	Application typique
Outil interne à faible risque	service account	whitelist, outils read uniquement	Variables d’environnement	actor/tool/outcome	Génération de rapports internes, synchronisation planifiée
SaaS multi-tenant	delegated token + tenantId	per-tool permission avec filtrage par tenant	secret vault avec isolation tenant	full schema avec tenantId	Agent CRM, assistant e-mail
Transaction financière	user identity + approval	scope minimization + approval	secret reference avec token court	full schema + approvalId	Approbation de transaction, opération de fonds
Opération sur données sensibles	delegated token + approval	whitelist + approval + guardrails	secret vault avec révocation d’urgence	full schema + masquage	Export de données, recherche client

L’OWASP AI Agent Security Cheat Sheet recommande des separate tool sets selon le trust level et une explicit authorization pour les opérations sensibles. Le point clé de cette table est la composition : les scénarios à haut risque exigent plusieurs couches de contrôle, pas un seul mécanisme présenté comme solution universelle.

Checklist de dépannage : symptômes fréquents des problèmes de permissions

Voici les symptômes, causes probables, vérifications et corrections fréquents.

Symptôme	Cause probable	Vérification	Correction
L’agent reçoit 403 Forbidden lors de l’appel d’un outil	actor n’a pas la tool permission, ou subject n’a pas la target permission	Vérifier le permission_level de actor et les droits resource de subject	Confirmer le mapping d’identité, ajuster la matrice de permissions
Les logs montrent un actor vide ou un subject confus	Les champs de mapping d’identité ne sont pas transmis correctement	Vérifier que l’agent context contient actor/subject/tenantId	Transmettre les champs d’identité dans toute la chaîne d’appel
L’appel d’outil réussit, mais l’audit log manque des champs nécessaires	Audit Log Schema incomplet	Vérifier que la logique de journalisation inclut tous les champs	Compléter le schema, ajouter traceId/approvalId
La requête de l’utilisateur A lit les données de l’utilisateur B	tenantId ou subject n’est pas isolé, ou un token administrateur est partagé	Vérifier l’usage des delegated tokens et la valeur de tenantId	Passer aux delegated tokens, imposer la validation tenantId
Après secret rotation, l’agent utilise encore l’ancienne key	Secret reference non mise à jour, ou rotation inactive	Vérifier que le vault renvoie le nouveau secret et que l’agent le récupère à nouveau	Faire mettre à jour automatiquement la reference par la rotation
Après approbation, l’appel d’outil échoue encore	Guardrails en échec, par exemple paramètre hors limites ou détection PII	Vérifier les logs tool_input_guardrails	Ajuster les paramètres ou les règles de guardrails

Checklist de mise en œuvre : construire un modèle de permissions Agent de 0 à 1

Voici les 5 étapes clés pour mettre en place le modèle d’autorisation.

Étape 1 : définir les règles de mapping d’identité

Points de décision : faut-il une isolation multi-tenant, donc un champ tenantId ? Y a-t-il des tâches de fond, donc un service account ? Y a-t-il des workflows automatisés, donc des delegated tokens ?

Pseudo-code :

interface IdentityContext {
  actor: string;        // Entité qui déclenche l'appel
  subject: string | null;  // Entité représentée
  delegatedBy?: string;  // Source de la délégation
  tenantId?: string;    // Identifiant du tenant
}

Étape 2 : concevoir la matrice de permissions d’outils

Points de décision : faut-il une approbation, donc needs_approval=true ? Faut-il un filtrage dynamique, donc une logique is_enabled à l’exécution ? Faut-il valider les paramètres, donc tool_input_guardrails ?

Exemple de code :

interface ToolPermission {
  name: string;
  permission_level: 'read' | 'write' | 'admin';
  required_scope: string[];
  needs_approval: boolean;
  is_enabled: (context: IdentityContext) => boolean;
}

Étape 3 : connecter un secret vault

Points de décision : faut-il des credentials courts, donc une secret reference ? Faut-il une révocation d’urgence, donc un vault capable de désactiver immédiatement ?

Exemple de code :

async function getSecret(secretRef: string, context: IdentityContext): Promise<string> {
  // Vérifier l'identité
  await vault.authenticate(context.actor);
  // Vérifier l'autorisation
  await vault.authorize(context.actor, secretRef);
  // Obtenir un token court
  const token = await vault.getToken(secretRef, expiresIn: '15m');
  // Enregistrer l'audit
  await auditLog.record({
    actor: context.actor,
    action: 'get_secret',
    resource: secretRef,
    outcome: 'success'
  });
  return token;
}

Étape 4 : implémenter les audit logs

Points de décision : faut-il masquer les données, donc des règles de redaction ? Faut-il un traceId, donc réutiliser le trace/runId de N156 ?

Exemple de code :

interface AuditLogEntry {
  traceId: string;
  timestamp: Date;
  actor: string;
  subject: string | null;
  tool: string;
  action: 'read' | 'write' | 'delete';
  resource: string;  // Masqué
  outcome: 'success' | 'failure' | 'denied';
}

Étape 5 : tester les limites de permissions

Points de décision : testez-vous les accès non autorisés, par exemple l’utilisateur A qui accède aux données de l’utilisateur B ? Testez-vous la fuite de token, en simulant la révocation après fuite d’un secret ? Testez-vous la traçabilité, en remontant toute la chaîne par traceId ?

Checklist de test : test d’accès non autorisé (actor=user_A, resource=tenant_B → doit renvoyer 403) ; test de fuite de token (vault.revoke(secretRef) → l’agent ne doit plus pouvoir obtenir de nouveau token) ; test de traçabilité Audit (rechercher la chaîne complète par traceId → elle doit contenir actor/subject/tool/outcome).

Étape suivante : lectures complémentaires

Le modèle d’autorisation d’un Agent touche à l’identité, aux outils, aux Secrets et à l’audit. Voici des lectures utiles pour prolonger.

Articles publiés :

• Guide Agent Sandbox : la sandbox traite l’isolation d’exécution avec conteneurs et Docker. Cet article traite les limites de permissions et de secrets ; les deux se complètent.
• Tool Calling en pratique : les bases du tool calling. Cet article les prolonge avec tool whitelist, per-tool permission et validation d’entrée.
• Monitoring et récupération des AI Agents : bases du monitoring et des alertes. Cet article ajoute les champs d’audit et traceId.