Agent Gateways : le control plane que vos agents IA en production ne doivent pas négliger

Tant qu’un agent IA se limite à rechercher de l’information ou à rédiger une réponse, une erreur reste généralement réversible. Le risque change de nature lorsqu’il peut modifier une base de données, déclencher un paiement, envoyer un email, ouvrir un ticket ou appeler un service tiers.

À ce stade, une question d’architecture devient centrale :

qui décide réellement si l’action proposée par le modèle peut être exécutée ?

La réponse ne peut pas reposer uniquement sur le prompt de l’agent. Un modèle probabiliste ne doit pas être seul responsable de l’autorisation d’une action déterministe.

C’est le rôle de l’agent gateway : placer une couche de contrôle entre l’intention produite par l’agent et son exécution dans le système réel.

AWS décrit désormais son AgentCore Gateway comme une couche de connectivité unifiée entre les agents, leurs outils et leurs ressources. Son moteur de politiques peut intercepter les requêtes et évaluer chaque appel avant d’autoriser l’accès à un outil. Google présente également son Agent Gateway comme un point central d’application des politiques pour les appels d’outils et les communications agentiques. (AWS Documentation)

La catégorie est encore en construction. Toutes les plateformes ne donnent pas exactement le même périmètre au terme agent gateway. Mais le besoin architectural, lui, est déjà clair :

Dès qu’un agent peut produire des effets de bord significatifs, une couche de contrôle déterministe doit séparer sa décision de l’exécution.

Qu’est-ce qu’un agent gateway ?

Un agent gateway est un point d’interception et d’application des politiques placé sur le chemin d’exécution des actions d’un agent.

Son rôle n’est pas de rendre le modèle plus intelligent. Il consiste à vérifier que l’action proposée est autorisée, valide, traçable et compatible avec les contraintes opérationnelles du système.

Un flux simplifié fonctionne ainsi :

1. Le modèle propose l’utilisation d’un outil avec des paramètres structurés.
2. L’orchestrateur transmet cette demande au gateway.
3. Le gateway vérifie l’identité, les permissions, les paramètres, les quotas et les règles métier.
4. L’action est autorisée, refusée ou suspendue dans l’attente d’une validation humaine.
5. Le résultat de l’outil est enregistré et renvoyé à l’orchestrateur.

Dans le cas des outils exécutés côté client avec Claude, le modèle ne lance pas lui-même le code métier. Il retourne un bloc tool_use, puis l’application décide d’exécuter ou non l’outil et lui transmet son résultat. Cette séparation fournit précisément le point d’interception nécessaire à l’application des politiques. (Claude Platform Docs)

Un agent gateway peut être :

• un composant développé dans l’orchestrateur ;
• un service indépendant ;
• une couche construite autour d’un API gateway existant ;
• un policy engine branché sur des serveurs MCP ;
• un service managé fourni par une plateforme cloud.

L’essentiel n’est donc pas d’acheter un produit appelé « Agent Gateway ». L’essentiel est de disposer d’un point d’enforcement non contournable avant toute action sensible.

Pourquoi les prompts et les permissions statiques ne suffisent pas

Une instruction comme « ne rembourse jamais plus de 5 000 € » est utile pour guider le modèle. Ce n’est pas une règle de sécurité.

Elle peut être mal interprétée, contournée par une injection de prompt, perdue dans un contexte trop long ou ignorée à la suite d’une erreur de raisonnement.

OWASP classe l’excessive agency parmi les risques majeurs des applications basées sur les LLM : un modèle disposant de fonctionnalités, de permissions ou d’une autonomie excessives peut provoquer des actions dommageables à partir d’une sortie inattendue, ambiguë ou manipulée. Son guide consacré aux agents recommande notamment le moindre privilège, la validation indépendante des actions sensibles et une supervision humaine adaptée à leur impact. (OWASP Gen AI Security Project)

Le problème ne vient pas seulement d’un agent « malveillant ». Un agent peut provoquer un incident tout en poursuivant correctement son objectif :

• il répète une action à cause d’une mauvaise gestion des retries ;
• il interprète incorrectement une réponse d’API ;
• il réutilise une information provenant du mauvais tenant ;
• il choisit un outil trop puissant pour l’opération demandée ;
• il enchaîne plusieurs actions valides produisant collectivement un résultat indésirable ;
• il applique une consigne injectée dans un email, un document ou une page web ;
• il continue une opération alors que la première étape a partiellement échoué.

La protection doit donc se situer hors du raisonnement du modèle, dans une couche capable d’appliquer des règles déterministes.

Les six contrôles d’un agent en production

Un gateway sérieux ne se résume pas à une whitelist d’outils. Il doit répondre à six questions.

1. Contrôle de l’identité

Qui demande l’action ?

Il faut pouvoir distinguer :

• l’agent ;
• l’application ou le workflow qui l’exécute ;
• l’utilisateur final pour lequel il agit ;
• l’organisation ou le tenant concerné ;
• la session ;
• le niveau de délégation accordé.

L’identité de l’agent ne doit pas se limiter à un champ agent_id fourni dans le payload. Elle doit être attestée par un mécanisme d’authentification vérifiable.

Google distingue par exemple l’identité propre de l’agent et sa capacité à agir pour son propre compte ou pour celui d’un utilisateur. Son système Agent Identity s’appuie sur une identité cryptographique et sur le standard SPIFFE. (Google Cloud Documentation)

2. Contrôle de l’autorisation

Cet agent peut-il utiliser cet outil dans ce contexte précis ?

La règle ne doit pas seulement dire :

support-agent → accès CRM

Elle doit pouvoir exprimer :

support-agent
→ lecture des commandes du tenant courant
→ aucune exportation globale
→ aucune suppression
→ modification limitée à certains champs

Le principe du moindre privilège doit s’appliquer aux outils, aux opérations, aux ressources et aux données.

AWS permet par exemple d’associer un moteur de politiques à un gateway afin d’évaluer les appels d’outils avant leur exécution. Les règles peuvent être exprimées sous forme de politiques déterministes, notamment avec Cedar. (AWS Documentation)

3. Contrôle des paramètres

L’action est-elle permise avec ces paramètres particuliers ?

Autoriser l’outil approve_refund ne signifie pas autoriser tous les remboursements.

Le gateway doit notamment pouvoir vérifier :

• les montants ;
• les destinataires ;
• les identifiants de tenant ;
• les tables ou colonnes interrogées ;
• les domaines accessibles ;
• les types et tailles de fichiers ;
• les plages de dates ;
• les schémas de données ;
• les valeurs interdites.

Cette validation doit être déterministe et idéalement fondée sur des schémas stricts, pas sur une seconde instruction en langage naturel.

4. Contrôle comportemental

Le comportement global de l’agent reste-t-il normal ?

Un appel isolé peut être valide alors que la séquence complète ne l’est pas.

Le gateway doit pouvoir détecter :

• les boucles ;
• les rafales d’appels ;
• les retries sans backoff ;
• les coûts anormaux ;
• les changements brusques d’outils ;
• une succession inhabituelle d’actions ;
• un volume de refus révélant un agent bloqué ou mal configuré.

Les rate limits et circuit breakers doivent être calculés par agent, utilisateur, tenant, outil et type d’action, pas seulement par adresse IP.

5. Contrôle des effets

L’action doit-elle être exécutée immédiatement ?

Toutes les actions ne présentent pas le même risque.

Une politique raisonnable peut distinguer :

• les actions en lecture seule ;
• les écritures réversibles ;
• les actions externes visibles par un tiers ;
• les opérations financières ;
• les suppressions ;
• les modifications de permissions ;
• les actions irréversibles.

Pour les opérations critiques, le gateway peut imposer :

• une validation humaine ;
• une authentification renforcée ;
• une confirmation de l’utilisateur ;
• un mécanisme à double approbation ;
• une simulation préalable ;
• une clé d’idempotence ;
• une exécution différée.

Les mécanismes d’approbation proposés par les plateformes d’agents suivent cette logique. OpenAI prévoit notamment des pauses et des validations pour les appels produisant des effets de bord ou considérés comme destructifs. (OpenAI Développeurs)

6. Contrôle post-exécution

Que s’est-il réellement passé ?

Autoriser une action ne suffit pas. Il faut également enregistrer :

• la demande initiale ;
• l’identité et la délégation ;
• la politique appliquée ;
• la décision du gateway ;
• les paramètres validés ;
• l’outil appelé ;
• la réponse de l’outil ;
• l’état final ;
• les éventuelles erreurs ou compensations.

Cette trace permet de reconstruire un incident, de mesurer les performances des agents et de distinguer une mauvaise décision du modèle d’une défaillance du système externe.

Le tracing de l’OpenAI Agents SDK enregistre par exemple les générations, appels d’outils, handoffs, guardrails et événements personnalisés d’un run. Cette observabilité est utile, mais elle ne remplace pas un journal métier durable et adapté aux obligations de l’entreprise. (OpenAI)

Où placer le gateway dans l’architecture ?

La représentation correcte n’est pas forcément :

LLM → gateway → outil

Dans de nombreux systèmes, le modèle ne contacte jamais directement l’outil. Il produit une proposition d’appel structurée, puis l’orchestrateur décide de la suite.

Une architecture plus fidèle ressemble à ceci :

┌────────────────────────┐
│ Utilisateur / événement│
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Agent orchestrator     │
│ LangGraph, n8n, custom │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ LLM                    │
│ Proposition de tool call│
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ AGENT GATEWAY          │
│                        │
│ • identité             │
│ • autorisation         │
│ • validation           │
│ • quotas               │
│ • approbation humaine  │
│ • journalisation       │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Tool executor          │
│ API, MCP, worker       │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Système métier         │
│ CRM, DB, email, ERP    │
└────────────────────────┘

Le gateway est donc un Policy Enforcement Point placé avant l’exécuteur d’outils.

Il doit être impossible de contourner ce point en appelant directement :

• la base de données ;
• un serveur MCP ;
• l’API métier ;
• une fonction cloud ;
• un worker ;
• un service tiers.

Un gateway qui ne contrôle qu’un chemin d’accès tandis que l’agent dispose de credentials directs vers les outils crée une illusion de sécurité.

Agent gateway, API gateway et ai gateway : quelles différences ?

Les trois catégories se recouvrent partiellement, mais elles ne répondent pas exactement au même problème.

Un API gateway comme Kong, Nginx ou un service cloud peut constituer une partie de la solution. Il sait déjà authentifier, limiter et journaliser des requêtes.

Ce qui manque généralement est le contexte agentique et métier :

• quel agent agit ;
• pour le compte de qui ;
• quelle intention ou tâche est en cours ;
• quel outil est invoqué ;
• quels effets l’action peut produire ;
• quelle politique métier s’applique ;
• une approbation humaine est-elle requise ;
• cette invocation fait-elle partie d’une boucle anormale.

La bonne approche n’est donc pas nécessairement de remplacer l’API gateway. Il peut être enrichi ou complété par une couche de politiques dédiée aux agents.

Google définit d’ailleurs son Agent Gateway comme une abstraction réseau gouvernant les interactions client-agent, agent-outil et agent-agent, avec application de politiques de sécurité et de contrôle d’accès. (Google Cloud Documentation)

Trois cas d’usage concrets

Cas 1 : un agent gère les remboursements clients

L’agent analyse une demande et propose un remboursement.

Une politique de gateway pourrait imposer :

Montant ≤ 200 € :
    exécution automatique

200 € < montant ≤ 2 000 € :
    exécution autorisée si le compte remplit les critères métier

Montant > 2 000 € :
    validation humaine obligatoire

Montant > 10 000 € :
    refus automatique pour ce workflow

La décision du modèle reste utile : il peut qualifier le dossier et proposer un montant. Mais l’autorisation financière est contrôlée par une règle indépendante.

AWS utilise précisément un scénario de traitement des remboursements dans sa documentation pour montrer comment des politiques peuvent limiter les montants autorisés. (AWS Documentation)

Cas 2 : un agent interroge des données sensibles

Donner à un agent une connexion SQL générique est rarement une bonne idée.

Une architecture plus sûre expose des outils étroits :

get_customer_orders(customer_id)
get_order_status(order_id)
get_monthly_sales_summary(period)

Le gateway vérifie alors :

• que l’utilisateur peut accéder au client demandé ;
• que le tenant correspond à la session ;
• que seules les colonnes autorisées sont retournées ;
• que les PII inutiles sont masquées ;
• que l’appel reste en lecture seule ;
• que le volume de données est raisonnable.

Le meilleur contrôle d’une requête SQL dangereuse reste souvent de ne jamais donner au modèle la possibilité de générer du SQL arbitraire.

Cas 3 : un agent consomme des APIs payantes

Un agent peut produire une facture importante sans qu’aucun appel individuel soit anormal.

Le gateway peut appliquer plusieurs budgets :

100 appels par minute et par agent
1 000 appels par heure et par tenant
200 € par jour pour le workflow
10 € maximum pour une exécution individuelle

Au-delà d’un seuil, il peut :

• ralentir les appels ;
• ouvrir un circuit breaker ;
• basculer vers un modèle ou un fournisseur moins coûteux ;
• suspendre uniquement l’outil concerné ;
• demander une validation ;
• arrêter le run.

Une implémentation minimale

La première version n’a pas besoin d’être un produit autonome. Un wrapper bien conçu autour de l’exécuteur d’outils peut suffire.

from dataclasses import dataclass
from datetime import datetime, timezone
from decimal import Decimal
from typing import Any, Callable


class GatewayDenied(Exception):
    pass


@dataclass(frozen=True)
class InvocationContext:
    agent_id: str
    user_id: str
    tenant_id: str
    run_id: str


@dataclass(frozen=True)
class ToolPolicy:
    handler: Callable[..., Any]
    write_operation: bool = False
    max_amount: Decimal | None = None
    requires_approval: bool = False


class AgentGateway:
    def __init__(self, policies: dict[str, ToolPolicy], audit_sink):
        self.policies = policies
        self.audit_sink = audit_sink

    def invoke(
        self,
        context: InvocationContext,
        tool_name: str,
        params: dict[str, Any],
        approved_by: str | None = None,
    ) -> Any:
        started_at = datetime.now(timezone.utc)
        decision = "denied"
        result_status = "not_executed"

        try:
            policy = self.policies.get(tool_name)

            if policy is None:
                raise GatewayDenied("Tool not allowed")

            self._verify_identity(context)
            self._check_rate_limits(context, tool_name)
            self._validate_schema(tool_name, params)
            self._enforce_tenant_scope(context, params)

            if policy.max_amount is not None:
                amount = Decimal(str(params.get("amount", 0)))

                if amount > policy.max_amount:
                    raise GatewayDenied("Amount exceeds policy limit")

            if policy.requires_approval and approved_by is None:
                raise GatewayDenied("Human approval required")

            decision = "allowed"

            # Utiliser une clé d’idempotence pour les écritures réessayables.
            result = policy.handler(
                **params,
                tenant_id=context.tenant_id,
                idempotency_key=f"{context.run_id}:{tool_name}",
            )

            result_status = "succeeded"
            return result

        except Exception:
            result_status = "failed"
            raise

        finally:
            self.audit_sink.write({
                "timestamp": started_at.isoformat(),
                "agent_id": context.agent_id,
                "user_id": context.user_id,
                "tenant_id": context.tenant_id,
                "run_id": context.run_id,
                "tool": tool_name,
                "decision": decision,
                "result_status": result_status,
                # Ne pas journaliser aveuglément les secrets ou PII.
                "params": self._redact(params),
                "approved_by": approved_by,
            })

Ce code illustre le principe d’interception. Ce n’est pas un gateway prêt pour la production.

Il manque encore, selon le contexte :

• une authentification cryptographique ;
• un stockage distribué pour les quotas ;
• une politique de délégation ;
• une validation stricte des schémas ;
• la gestion des secrets ;
• la redaction des données sensibles ;
• des journaux durables et protégés ;
• des timeouts ;
• des retries bornés ;
• des mécanismes de compensation ;
• une haute disponibilité ;
• des procédures de révocation ;
• une protection contre les accès directs aux outils.

Roadmap d’implémentation

Phase 1 : inventorier les actions et réduire les permissions

Avant de développer un gateway, listez tous les outils accessibles aux agents.

Pour chaque outil, documentez :

• les ressources accessibles ;
• les opérations possibles ;
• les effets de bord ;
• le caractère réversible ou irréversible ;
• les données sensibles exposées ;
• le coût potentiel ;
• le niveau d’approbation nécessaire.

Commencez ensuite par :

• supprimer les outils inutiles ;
• séparer lecture et écriture ;
• remplacer les outils génériques par des opérations métier étroites ;
• ajouter une validation de schéma ;
• journaliser les appels et leurs résultats.

Phase 2 : centraliser les politiques

Ajoutez un contexte d’exécution structuré :

• identité de l’agent ;
• utilisateur ;
• tenant ;
• run ;
• objectif du workflow ;
• niveau de risque ;
• délégation active.

Puis centralisez :

• les règles d’autorisation ;
• les limites de montant ;
• les quotas ;
• les approbations ;
• les restrictions temporelles ;
• les règles de données ;
• les circuit breakers.

Phase 3 : industrialiser

Lorsque plusieurs équipes, agents ou environnements utilisent les mêmes outils, transformez la couche en service partagé.

Ajoutez :

• un policy engine ;
• une gestion centralisée des identités ;
• un registre d’agents et d’outils ;
• des politiques versionnées ;
• des traces corrélées ;
• des alertes ;
• des tests de politiques ;
• un mode d’observation sans blocage ;
• une procédure d’incident ;
• des contrôles de conformité.

Le NIST AI Risk Management Framework recommande d’identifier les fonctions nécessitant une supervision humaine, de définir les rôles et responsabilités et d’adapter les mécanismes de contrôle au contexte et au niveau de risque. (NIST)

Les erreurs d’implémentation les plus fréquentes

1. Contrôler le nom de l’outil, mais pas ses paramètres

Une whitelist qui autorise send_email sans vérifier le destinataire, le domaine, le contenu ou le volume n’apporte qu’une protection limitée.

Une autorisation utile porte sur :

agent + utilisateur + tenant + outil + opération + ressource + paramètres

2. Laisser un chemin de contournement

Si le workflow peut appeler directement le CRM ou la base de données, le gateway n’est pas un point d’enforcement.

Les credentials des systèmes métier doivent être détenus par l’exécuteur contrôlé, pas exposés directement au modèle ou à un worker alternatif.

3. Journaliser uniquement la requête

Une action peut être autorisée puis échouer partiellement.

Il faut enregistrer :

• la décision ;
• le début d’exécution ;
• le résultat ;
• les retries ;
• l’état final ;
• les compensations éventuelles.

Pour les systèmes asynchrones, utilisez un identifiant de corrélation commun entre le run de l’agent, l’invocation, le job et l’événement métier.

4. Enregistrer des secrets dans les traces

Les outils manipulent souvent des tokens, PII, données financières ou contenus clients.

Un audit trail utile ne signifie pas enregistrer l’intégralité des paramètres et des réponses sans filtrage. La redaction et les règles de rétention doivent être conçues dès le départ.

5. Appliquer les mêmes limites à toutes les actions

Cent lectures de catalogue et cent virements ne présentent pas le même risque.

Les politiques doivent dépendre :

• de l’outil ;
• de l’impact ;
• du tenant ;
• de la valeur financière ;
• du caractère réversible ;
• de la confiance accordée au workflow.

6. Bloquer sans informer l’orchestrateur

Quand une action est refusée, l’agent doit recevoir une erreur exploitable :

{
  "code": "HUMAN_APPROVAL_REQUIRED",
  "message": "Refunds above 2000 EUR require approval.",
  "retryable": false
}

Une réponse vague comme Access denied pousse souvent l’agent à répéter la même action.

7. Confondre observabilité et autorisation

Tracer un appel ne l’empêche pas de s’exécuter.

Le tracing aide à comprendre. Le gateway doit aussi pouvoir :

• autoriser ;
• refuser ;
• modifier ;
• suspendre ;
• demander une approbation ;
• ouvrir un circuit breaker.

Gateway maison ou solution spécialisée ?

Le nombre d’agents n’est pas le bon critère.

Un seul agent capable d’effectuer des virements peut justifier une infrastructure forte. Cinquante agents en lecture seule sur des données publiques peuvent rester derrière un wrapper relativement simple.

La décision doit dépendre de la criticité.

Commencez en interne lorsque :

• vous avez peu d’outils ;
• les workflows sont maîtrisés ;
• les règles sont simples ;
• vous avez déjà une infrastructure IAM et d’observabilité solide ;
• la couche peut rester proche de l’application.

Industrialisez ou achetez lorsque :

• plusieurs équipes dupliquent les mêmes contrôles ;
• les politiques doivent être centralisées ;
• les agents utilisent plusieurs runtimes ;
• les serveurs MCP et outils se multiplient ;
• les obligations d’audit deviennent importantes ;
• maintenir les règles devient une charge cognitive ou opérationnelle.

Comment savoir si votre agent a besoin d’un gateway ?

Attribuez un point pour chaque réponse positive :

• L’agent écrit-il dans un système métier ?
• Peut-il supprimer ou rendre publiques des données ?
• Manipule-t-il des données personnelles ou confidentielles ?
• Peut-il engager une dépense ?
• Peut-il contacter un client ou un tiers ?
• Dispose-t-il de plusieurs outils ?
• Agit-il pour plusieurs utilisateurs ou tenants ?
• Une action peut-elle être irréversible ?
• Une erreur peut-elle produire un incident réglementaire ?
• Le workflow fonctionne-t-il sans supervision humaine directe ?

Interprétation

• 0 à 2 points : un wrapper simple, des permissions étroites et des logs peuvent suffire.
• 3 à 5 points : mettez en place un point d’enforcement explicite et des politiques versionnées.
• 6 points ou plus : traitez le gateway comme un composant critique de votre architecture.

Cette grille n’est pas une norme. Elle sert à éviter une décision fondée uniquement sur la taille du projet ou le nombre d’agents.

Conclusion

Un agent gateway n’est pas un proxy magique qui sécurise automatiquement un système agentique.

C’est un principe d’architecture :

la décision probabiliste du modèle ne doit jamais constituer à elle seule l’autorisation d’une action réelle.

Dès qu’un agent produit des effets de bord, vous devez disposer d’un point de contrôle capable de vérifier son identité, sa délégation, ses permissions, ses paramètres, son comportement et l’impact de l’action.

Trois principes sont à retenir :

1. Le prompt guide ; la politique autorise.
   Une instruction en langage naturel ne remplace pas une règle déterministe.

2. Le contrôle doit être non contournable.
   Tous les accès sensibles doivent passer par le même point d’enforcement.

3. Le niveau de contrôle dépend de l’impact, pas du nombre d’agents.
   Un agent unique peut nécessiter une gouvernance forte s’il manipule des paiements, des permissions ou des données sensibles.

Vous n’avez pas nécessairement besoin d’une plateforme spécialisée dès le premier prototype. Mais vous devez définir très tôt où se trouve la frontière entre ce que l’agent propose et ce que votre système autorise réellement.

response = client.messages.create(
    model=MODEL_NAME,
    max_tokens=1024,
    tools=tool_definitions,
    messages=messages,
)

for block in response.content:
    if block.type != "tool_use":
        continue

    try:
        result = gateway.invoke(
            context=invocation_context,
            tool_name=block.name,
            params=block.input,
        )

        tool_result = {
            "type": "tool_result",
            "tool_use_id": block.id,
            "content": serialize_result(result),
        }

    except GatewayDenied as exc:
        tool_result = {
            "type": "tool_result",
            "tool_use_id": block.id,
            "is_error": True,
            "content": str(exc),
        }

    messages.append({
        "role": "assistant",
        "content": response.content,
    })

    messages.append({
        "role": "user",
        "content": [tool_result],
    })