ChatGPT and Copilot: The Verified Identity Challenge in Business

Le brief IA que les pros lisent chaque soir
Les 7 actus IA du jour, décryptées en 5 min. Gratuit.
Inclus dès l'inscription : notre sélection des meilleurs guides & comparatifs IA.
Choisis ton rythme
Gratuit · Pas de spam · Désabonnement en 1 clic
The Identity Challenge in AI Integration
In the world of modern enterprises, integrating AI assistants into internal systems has become a necessity to enhance efficiency and productivity. A company recently attempted to connect its employees to an internal assistant via a commercial AI platform they use daily. This assistant, designed as a low-code agent, is integrated with a corporate search index and various Power Automate flows. The integration seemed straightforward: the host platform calls a proxy, which in turn calls the agent, which responds to requests. However, a major issue arose when the question of user identity was raised.
When an employee asked the assistant to perform a task reserved for their personal access, the question of who actually made that request became crucial. The proxy had authenticated itself to the agent using a unique application identifier. Thus, every call received by the agent carried the same identifier, that of the proxy's service principal. The actual users, meaning the employees asking the questions, were not identified in the context of the agent or in its execution history. This situation made it impossible to implement any personalization or authorization based on the real user's identity. Indeed, identity was present at the entry point but vanished after the first hop.
The Need for Identity Assertion
To resolve this issue, it is essential that when integrating a host AI platform with a corporate agent via a proxy, the latter verifies human identity using the delegated flow from the enterprise's identity provider. This involves resolving canonical identity claims from the identity provider's source of truth and transmitting this verified identity to the downstream agent as explicit context for each request. The service principal path should be reserved for truly user-less tasks and logged as an exception. Maintaining verified human identity across this bridge is crucial for a U.S. company to adopt a third-party AI front-end on its internal systems without losing user-level accountability. It also determines whether regulated organizations can use commercial AI platforms.
The Verified Identity Bridge Model
The verified identity bridge is a key component that authenticates both the human user and communicates with the downstream agent. It ensures the transport of identity across the gap. Five constraints define this model:
-
User verification at the bridge with a delegated flow. It is crucial to use the authorization code flow from the enterprise's IdP with PKCE, rather than an opaque session from the host platform or a static API key shared among users. This allows the bridge to hold a token issued to the actual user.
-
Identity resolution from the IdP's source of truth. It is important not to rely on self-asserted identity from the host platform. The directory (such as Microsoft Graph /me) must be called with the user's delegated token to read canonical claims such as object ID, user principal name, and display name.
-
No permanent user credential retention. Tokens should be limited to the scope of the request. An access token should only be cached for its lifetime and only associated with its own user. It should never be shared among users or retained beyond its expiration.
-
Assertion of verified identity downstream under an explicit trust contract. The bridge must transmit the resolved claims to the agent as context for each request. Since the agent cannot validate a user token itself, the channel between the bridge and the agent must be authenticated for the agent to trust the asserted identity coming from the bridge.
-
Restriction of the service principal path. In the absence of a user token, it may be tempting to revert to client-only identifiers for the application. This would silently terminate identity. This path should be reserved for user-less operations, restricted, and each use must be logged as an exception.
Concrete Implementation
A concrete example of this implementation connects ChatGPT Enterprise to a Microsoft Copilot Studio agent via an MCP Node.js proxy. ChatGPT Enterprise serves as the host AI platform, while the Copilot Studio bot is the downstream low-code agent accessible via a Power Automate flow. The enterprise's IdP is Microsoft Entra ID. This case perfectly illustrates the purpose of the verified identity bridge: while ChatGPT Enterprise verifies the employee, the Copilot Studio agent cannot validate a user token. Therefore, the bridge must verify the human user and assert their identity.
User Verification at the Bridge
The verification process begins with the use of PKCE to ensure that the authorization code cannot be replayed by an interceptor. The bridge constructs the authorization URL, the user logs into Entra, and the returned code is exchanged for a token issued to that user.
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",
// ...
});
}
Brief IA — L'actualité IA en français
L'essentiel de l'actualité de l'intelligence artificielle, décrypté et expliqué chaque jour.