Appels API

Sécuriser les appels API d'un agent IA

Hermes appelle les API internes avec un token. OAuth et l'autorisation fine ne s'opposent pas : le premier établit qui appelle et avec quel périmètre général, la seconde juge la requête elle-même, avec ses valeurs.

Un token valide prouve qu'un appel peut être authentifié. Il ne suffit pas toujours à déterminer si cette action précise est légitime.

Voir l'architecture complète

Par Sécurité Agentique · Publié le 28 septembre 2026

Le problème n'est pas uniquement l'accès à l'API

Le token de Hermes porte le scope payments.write. L'API l'accepte : l'agent peut créer un paiement. Le scope ne dit rien de ce que contient la requête.

Montant: N'importe quel montant ?
Destination: Vers n'importe quel compte ?
Moment: À n'importe quelle heure ?
Environnement: Depuis n'importe quel environnement ?

Ces limites sont des valeurs dans le corps de la requête, pas des permissions sur l'API. Elles ne peuvent être vérifiées qu'au moment de l'appel, par un composant qui lit la requête.

API Gateway comme PEP

1. Interception · La gateway reçoit l'appel et vérifie le token : signature, expiration, audience, scope.
2. Extraction · Elle lit l'endpoint, la méthode et les champs utiles du payload, et construit une demande de décision.
3. Décision · Le PDP évalue la politique publiée depuis le PAP, complète avec les attributs des PIP (liste des fournisseurs, plafond du service).
4. Application · La gateway transmet, refuse ou applique l'obligation (validation, limitation). L'API ne reçoit que ce qui a été permis.

La gateway n'est un PEP que si l'API n'est joignable que par elle. Un token accepté aussi en appel direct rend le contrôle contournable.

Exemple concret

Exemple illustratif · paiement fournisseur

Appel 1

Endpoint: POST /payments
Utilisateur: Acheteur France
Agent: Hermes
Scope du token: payments.write
Montant: 2 500 EUR
Destination: Fournisseur approuvé
Environnement: production

✓ PERMIT

Appel 2

Endpoint: POST /payments
Utilisateur: Acheteur France
Agent: Hermes
Scope du token: payments.write
Montant: 250 000 EUR (attribut modifié)
Destination: IBAN inconnu (attribut modifié)
Environnement: production

✕ DENY

Même token, même scope, même endpoint. Selon la politique, l'appel 2 est refusé ou soumis à une validation humaine : un seul des deux changements (montant ou IBAN inconnu) peut suffire à le déclencher.

Ce que le PEP peut contrôler

endpoint
méthode HTTP
payload
paramètres
ressource
montant
volume
destination
headers
contexte
finalité

Chaque élément n'est utilisable que si le PEP sait l'extraire et que la politique l'attend. Un PEP qui ne voit que l'URL ne peut pas appliquer un plafond de montant. Les mêmes principes valent pour un outil MCP qui encapsule l'API : voir sécuriser les MCP.

Authentification, scopes OAuth et autorisation runtime

Authentification

Qui appelle ?

Hermes, pour le compte d'un acheteur, depuis ce workload.

Scope OAuth

Quel périmètre général le token possède-t-il ?

payments.write sur l'API de paiements.

Autorisation runtime

Cette action précise est-elle autorisée maintenant ?

Ce montant, vers cet IBAN, en production, à cette heure.

Chaque couche s'appuie sur la précédente. Le fonctionnement du PDP, des obligations et des politiques est détaillé dans autorisation fine des agents IA.

API security et autorisation

Couche API security: Détecte un payload suspect, une API non inventoriée (shadow API), un schéma anormal, des données sensibles, des menaces runtime. Exemple : AccuKnox.
PDP: Juge la légitimité métier et contextuelle de l'appel. Exemple : Axiomatics, avec la gateway comme PEP.

Un appel au schéma impeccable vers un IBAN inconnu passe l'inspection et doit être refusé par la politique. Un appel autorisé dont le payload contient une injection doit être arrêté par l'inspection. Le reste des chemins de Hermes figure dans l'architecture complète.

FAQ

Questions fréquentes

Comment sécuriser une API appelée par un agent IA ?

Donner à l'agent une identité propre et un token limité, faire passer ses appels par une API Gateway ou un autre PEP obligatoire, soumettre les appels à effet métier à une décision d'autorisation qui voit les paramètres (montant, destination, volume), inspecter les requêtes et réponses, et journaliser la décision avec l'appel.

OAuth suffit-il ?

OAuth établit qu'un client détient un token portant certains scopes. Si les scopes de l'API sont aussi précis que la mission de l'agent, cela peut suffire. Quand la mission dépend de valeurs portées par la requête, comme un montant ou un IBAN, un scope ne peut pas l'exprimer : une décision runtime complète OAuth, elle ne le remplace pas.

Qu'est-ce qu'un PEP API ?

Le composant placé sur le chemin des appels API qui intercepte chaque requête, en extrait le sujet, l'action, la ressource et les paramètres, demande une décision au PDP et applique la réponse avant de transmettre, ou non, à l'API.

Une API Gateway peut-elle être un PEP ?

Oui, à condition que l'API ne soit joignable que par elle et qu'elle sache interroger un PDP et appliquer sa décision, obligations comprises. Si l'agent peut appeler l'API directement avec le même token, la gateway n'est plus un point obligatoire.

Quelle différence entre API security et authorization ?

L'API security qualifie le trafic : payload suspect, schéma anormal, API non inventoriée, données sensibles, menaces runtime. L'autorisation décide si cet appel, avec ces valeurs, est légitime pour ce sujet dans ce contexte. Un appel parfaitement formé peut être illégitime.

Comment limiter les montants exécutables par un agent ?

En exprimant le plafond dans une politique évaluée par le PDP, avec le montant extrait de la requête par le PEP. La politique peut combiner le montant avec la destination, l'utilisateur d'origine et l'environnement, et renvoyer Deny ou une obligation de validation humaine au-delà du seuil.

Comment appliquer ABAC à une API ?

Le PEP transmet au PDP des attributs issus de la requête (endpoint, méthode, champs du payload), du token (agent, utilisateur délégant) et du contexte (environnement, heure). Le PDP complète via les PIP (fournisseur approuvé, plafond du service) et évalue une politique ABAC.

Continuer l'exploration

Où votre agent peut-il réellement agir ?

Cartographions ses modèles, données, outils, API, identités et effets pour identifier les contrôles utiles.

Étudier mon architecture