Serveur MCP dans votre monolithe Laravel : authentification double et contrôle d'accès pour vos agents IA

Les agents IA prolifèrent dans nos architectures, et avec eux une tentation récurrente : créer une nouvelle API dédiée, avec son propre système d'authentification, ses propres règles d'accès, sa propre couche de données. Résultat ? Un doublon de votre logique métier, une surface d'attaque supplémentaire, et une base de code qui diverge dès la première semaine.

L'article de Nasrul Hazim Bin Mohamad sur DEV.to propose une approche plus élégante : intégrer un serveur MCP (Model Context Protocol) directement à l'intérieur d'une application Laravel existante. L'idée mérite qu'on s'y attarde, car elle pose une vraie question d'architecture que les équipes Symfony/PHP rencontrent tout autant.

Qu'est-ce que le Model Context Protocol et pourquoi ça change la donne ?

MCP est un protocole ouvert développé par Anthropic pour standardiser la façon dont les agents IA interagissent avec des sources de données et des outils externes. Concrètement, un serveur MCP expose des ressources (données lisibles) et des outils (actions exécutables) qu'un agent comme Claude peut appeler de manière structurée.

Là où une API REST classique répond à des requêtes HTTP génériques, un serveur MCP est conçu pour le dialogue avec des LLM : il décrit ses capacités de façon sémantique, gère le contexte de la conversation, et s'intègre nativement dans les boucles d'inférence des agents modernes.

L'enjeu pour les équipes backend est le suivant : faut-il déployer ce serveur MCP comme un microservice indépendant, ou peut-on l'imbriquer dans l'application existante ?

L'architecture proposée : MCP intégré au monolithe

L'approche décrite dans l'article source consiste à faire cohabiter le serveur MCP avec le code Laravel existant, en réutilisant directement :

• Les modèles Eloquent — pas besoin de re-mapper vos entités
• Les politiques de sécurité (Policies) — vos règles can() s'appliquent aussi aux appels des agents
• La logique métier — vos services et actions existants sont directement appelables

Concrètement, le serveur MCP est enregistré comme un ensemble de routes et de handlers à l'intérieur de l'application Laravel, exposés sur un endpoint dédié (par exemple /mcp). Le protocole de transport peut être SSE (Server-Sent Events) ou stdio selon le contexte d'utilisation.

// Exemple simplifié d'un outil MCP enregistré dans Laravel
class GetUserOrdersTool implements McpTool
{
    public function name(): string
    {
        return 'get_user_orders';
    }

    public function description(): string
    {
        return 'Récupère les commandes d\'un utilisateur authentifié.';
    }

    public function execute(array $params, User $actor): array
    {
        // On réutilise directement la Policy existante
        abort_unless($actor->can('viewAny', Order::class), 403);

        return Order::where('user_id', $actor->id)
            ->latest()
            ->limit(20)
            ->get()
            ->toArray();
    }
}

Ce pattern est immédiatement transposable en Symfony, en s'appuyant sur le Security component et les Voters plutôt que sur les Policies Laravel.

Authentification double : séparer l'agent de l'utilisateur final

C'est le point le plus structurant de l'article : un appel MCP implique deux identités distinctes qu'il faut authentifier séparément.

1. L'agent IA lui-même — identifié par une clé API ou un token de service. C'est l'entité technique qui se connecte au serveur MCP.
2. L'utilisateur pour le compte duquel l'agent agit — l'humain dont les permissions doivent s'appliquer aux actions exécutées.

Cette séparation est critique pour la sécurité. Sans elle, soit l'agent hérite de permissions trop larges (risque d'élévation de privilèges), soit l'utilisateur peut se retrouver à exécuter des actions qu'il n'aurait pas autorisées lui-même.

Dans le middleware MCP, cela se traduit par une double résolution :

// Middleware de double authentification MCP
public function handle(Request $request, Closure $next): Response
{
    // 1. Authentification de l'agent (via header X-MCP-Token)
    $agent = AgentToken::findOrFail($request->header('X-MCP-Token'));
    abort_unless($agent->isActive(), 401, 'Agent token invalide.');

    // 2. Résolution de l'utilisateur contextuel (via header X-User-ID)
    $user = User::findOrFail($request->header('X-User-ID'));
    abort_unless($agent->canActOnBehalfOf($user), 403, 'Délégation non autorisée.');

    // Injection dans la requête pour usage downstream
    $request->merge(['mcp_agent' => $agent, 'mcp_user' => $user]);

    return $next($request);
}

Cette logique de délégation (canActOnBehalfOf) permet de définir précisément quels agents peuvent agir pour quels utilisateurs, et dans quel périmètre.

RBAC sur les outils MCP : pas tous les agents n'ont accès à tout

L'article introduit ensuite un mécanisme de contrôle d'accès basé sur les rôles (RBAC) appliqué aux outils MCP eux-mêmes. Chaque outil peut se voir attribuer un niveau de permission requis, et l'agent doit disposer du rôle approprié pour l'invoquer.

Ce RBAC opère à deux niveaux :

• Niveau agent : quel agent a le droit d'appeler quel outil ? Un agent de support client ne devrait pas pouvoir invoquer un outil de suppression de données.
• Niveau utilisateur : même si l'agent est autorisé, les permissions de l'utilisateur final s'appliquent. Un agent admin ne peut pas contourner les restrictions d'un utilisateur standard.

Cette double grille de contrôle garantit que le principe du moindre privilège est respecté à chaque couche.

// Déclaration des permissions requises sur un outil
class DeleteOrderTool implements McpTool
{
    public function requiredAgentRole(): string
    {
        return 'agent:admin'; // Seuls les agents admin peuvent appeler cet outil
    }

    public function execute(array $params, User $actor): array
    {
        abort_unless($actor->can('delete', Order::find($params['order_id'])), 403);
        // ...
    }
}

Ce que cela implique pour vos projets Symfony/PHP

Bien que l'article source soit centré sur Laravel, la philosophie est directement applicable à un monolithe Symfony :

• Réutilisez vos Voters pour les contrôles d'accès sur les outils MCP
• Intégrez le serveur MCP comme un bundle ou un groupe de routes dans votre application existante
• Externalisez la gestion des tokens d'agents dans une table dédiée, avec rotation et révocation
• Auditez chaque appel MCP dans vos logs applicatifs avec l'identité duale (agent + utilisateur)

L'approche monolithique n'est pas un compromis : elle est souvent la bonne décision en phase initiale, quand la logique métier est encore en évolution et que le surcoût opérationnel d'un microservice dédié n'est pas justifié.

Conclusion

Intégrer un serveur MCP dans votre application existante plutôt que de créer un service isolé, c'est parier sur la cohérence plutôt que sur la fragmentation. Vos modèles de données, vos règles métier et vos politiques de sécurité deviennent immédiatement disponibles pour vos agents IA, sans duplication ni dérive.

La double authentification et le RBAC sur les outils MCP apportent le niveau de contrôle nécessaire pour opérer ces intégrations en production avec confiance. Ce sont des patterns matures, issus des meilleures pratiques de sécurité web, simplement appliqués à un nouveau type de client : l'agent IA.

Source originale : Putting an MCP Server Inside a Laravel App: Dual-Auth and RBAC for AI Tools par Nasrul Hazim Bin Mohamad sur DEV.to.