ChatGPT et Copilot : défi d'identité vérifiée en entreprise

L'enjeu de l'identité dans l'intégration IA

Dans le monde des entreprises modernes, l'intégration d'assistants IA dans les systèmes internes est devenue une nécessité pour améliorer l'efficacité et la productivité. Une entreprise a récemment tenté de connecter ses employés à un assistant interne via une plateforme d'IA commerciale qu'ils utilisent quotidiennement. Cet assistant, conçu comme un agent à faible code, est intégré à un index de recherche d'entreprise et à divers flux Power Automate. L'intégration semblait simple : la plateforme hôte appelle un proxy, qui à son tour appelle l'agent, lequel répond aux requêtes. Cependant, un problème majeur est apparu lorsque la question de l'identité des utilisateurs a été soulevée.

Lorsqu'un employé a demandé à l'assistant d'effectuer une tâche réservée à son accès personnel, la question de savoir qui avait réellement fait cette demande est devenue cruciale. Le proxy s'était authentifié auprès de l'agent en utilisant un identifiant d'application unique. Ainsi, chaque appel reçu par l'agent portait le même identifiant, celui du principal de service du proxy. Les véritables utilisateurs, c'est-à-dire les employés posant les questions, n'étaient pas identifiés dans le contexte de l'agent ni dans son historique d'exécution. Cette situation rendait impossible toute personnalisation ou autorisation basée sur l'identité réelle de l'utilisateur. En effet, l'identité était présente à l'entrée mais disparaissait dès le premier saut.

La nécessité d'une revendication d'identité

Pour résoudre ce problème, il est essentiel que lors de l'intégration d'une plateforme d'IA hôte avec un agent d'entreprise via un proxy, ce dernier vérifie l'identité humaine en utilisant le flux délégué du fournisseur d'identité de l'entreprise. Cela implique de résoudre les revendications d'identité canonique à partir de la source de vérité du fournisseur et de transmettre cette identité vérifiée à l'agent en aval comme contexte explicite pour chaque demande. Le chemin du principal de service doit être réservé aux tâches réellement sans utilisateur et enregistré comme une exception. Maintenir l'identité humaine vérifiée à travers ce pont est crucial pour qu'une entreprise américaine puisse adopter un front-end d'IA tiers sur ses systèmes internes sans perdre la responsabilité au niveau utilisateur. Cela détermine également si les organisations réglementées peuvent utiliser des plateformes d'IA commerciales.

Le modèle du Pont d'Identité Vérifiée

Le pont d'identité vérifiée est un composant clé qui authentifie à la fois l'utilisateur humain et communique avec l'agent en aval. Il assure le transport de l'identité à travers le fossé. Cinq contraintes définissent ce modèle :

• Vérification de l'utilisateur au pont avec un flux délégué. Il est crucial d'utiliser le flux de code d'autorisation de l'IdP de l'entreprise avec PKCE, plutôt qu'une session opaque de la plateforme hôte ou une clé API statique partagée entre les utilisateurs. Cela permet au pont de détenir un jeton émis à l'utilisateur réel.

• Résolution de l'identité à partir de la source de vérité de l'IdP. Il est important de ne pas se fier à l'identité auto-affirmée par la plateforme hôte. Le répertoire (tel que Microsoft Graph /me) doit être appelé avec le jeton délégué de l'utilisateur pour lire les revendications canoniques telles que l'identifiant d'objet, le nom principal de l'utilisateur et le nom d'affichage.

• Absence de conservation de crédentiel utilisateur permanent. Les jetons doivent être limités à la portée de la demande. Un jeton d'accès ne doit être mis en cache que pendant sa durée de vie et uniquement associé à son propre utilisateur. Il ne doit jamais être partagé entre utilisateurs ni conservé au-delà de son expiration.

• Affirmation de l'identité vérifiée en aval sous un contrat de confiance explicite. Le pont doit transmettre les revendications résolues à l'agent comme contexte pour chaque demande. Comme l'agent ne peut pas valider lui-même un jeton utilisateur, le canal entre le pont et l'agent doit être authentifié pour que l'agent puisse faire confiance à l'identité affirmée provenant du pont.

• Restriction du chemin du principal de service. En l'absence de jeton utilisateur, il peut être tentant de revenir à des identifiants client uniquement pour l'application. Cela mettrait fin silencieusement à l'identité. Ce chemin doit être réservé aux opérations sans utilisateur, restreint et chaque utilisation doit être enregistrée comme une exception.

Mise en œuvre concrète

Un exemple concret de cette mise en œuvre relie ChatGPT Enterprise à un agent Copilot Studio de Microsoft via un proxy MCP Node.js. ChatGPT Enterprise sert de plateforme d'IA hôte, tandis que le bot Copilot Studio est l'agent en aval à faible code accessible via un flux Power Automate. L'IdP de l'entreprise est Microsoft Entra ID. Ce cas illustre parfaitement la raison d'être du pont d'identité vérifiée : bien que ChatGPT Enterprise vérifie l'employé, l'agent Copilot Studio ne peut pas valider un jeton utilisateur. Le pont doit donc vérifier l'utilisateur humain et affirmer son identité.

Vérification de l'utilisateur au pont

Le processus de vérification commence par l'utilisation de PKCE pour garantir que le code d'autorisation ne puisse pas être rejoué par un intercepteur. Le pont construit l'URL d'autorisation, l'utilisateur se connecte à Entra, et le code retourné est échangé contre un jeton émis à cet utilisateur.

import { randomBytes, createHash } from "crypto";

export function generatePKCE() {
    const codeVerifier = randomBytes(32).toString("base64url");
    const codeChallenge = createHash("sha256").update(codeVerifier).digest("base64url");
    return { codeVerifier, codeChallenge };
}

export function getAuthorizationUrl(scope: string, redirectUri: string) {
    const { codeVerifier, codeChallenge } = generatePKCE();
    const state = randomBytes(16).toString("base64url");
    const params = new URLSearchParams({
        client_id: process.env.CLIENT_ID!,
        response_type: "code",
        // ...
    });
}