[Principes fondamentaux de l’identité](https://www.pingidentity.com/fr/resources/identity-fundamentals.html)  

[IA agentique](https://www.pingidentity.com/fr/resources/identity-fundamentals/agentic-ai.html) 

[Considérations clés IAM pour prendre en charge l’IA agentique](https://www.pingidentity.com/fr/resources/identity-fundamentals/agentic-ai/key-iam-considerations.html) 

[Classes et études de cas de l’agent d’IA](https://www.pingidentity.com/fr/resources/identity-fundamentals/agentic-ai/classes-and-use-cases.html) 

[Meilleures pratiques IAM pour les agents d'IA](https://www.pingidentity.com/fr/resources/identity-fundamentals/agentic-ai/iam-best-practices-ai-agents.html) 

[Implémentations de référence et modèles](https://www.pingidentity.com/fr/resources/identity-fundamentals/agentic-ai/reference-implementation-patterns.html) 

[Identité d'exécution](https://www.pingidentity.com/fr/resources/identity-fundamentals/agentic-ai/runtime-identity.html) 

[Identité Headless](https://www.pingidentity.com/fr/resources/identity-fundamentals/agentic-ai/headless-identity.html) 

[Authentification](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication.html) 

[Authentification basée sur un certificat](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication/certificate-authentication.html) 

[Authentification CHAP](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication/chap-authentication.html) 

[Qu’est-ce que l’authentification continue ?](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication/continuous-authentication.html) 

[Gestion des identités fédérées](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication/federated-identity-management.html) 

[L’authentification passwordless](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication/passwordless-authentication.html) 

[Authentification FIDO : explication de WebAuthn, FIDO2 et CTAP2](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication/passwordless-authentication/fido.html) 

[Authentification basée sur le niveau de risque](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication/risk-based-authentication.html) 

[Single Sign-On (SSO)](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication/single-sign-on.html) 

[Authentification à facteur simple, à double facteur et multifacteur](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication/single-factor-two-factor-multi-factor-authentication.html) 

[Authentification basée sur des jetons](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication/token-based-authentication.html) 

[Protocoles d’authentification et d’autorisation](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication-authorization-protocols.html) 

[LDAP](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication-authorization-protocols/ldap.html) 

[SCIM](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication-authorization-protocols/scim.html) 

[WebAuthn](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication-authorization-protocols/webauthn.html) 

[Kerberos](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication-authorization-protocols/kerberos.html) 

[WS-Trust](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication-authorization-protocols/ws-trust.html) 

[Standards d’authentification et d’autorisation](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication-authorization-standards.html) 

[SAML](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication-authorization-standards/saml.html) 

[OAuth](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication-authorization-standards/oauth.html) 

[OpenID Connect (OIDC)](https://www.pingidentity.com/fr/resources/identity-fundamentals/authentication-authorization-standards/openid-connect.html) 

[Autorisation](https://www.pingidentity.com/fr/resources/identity-fundamentals/authorization.html) 

[Méthodes d’autorisation](https://www.pingidentity.com/fr/resources/identity-fundamentals/authorization/authorization-methods.html) 

[Provisioning des utilisateurs et des comptes](https://www.pingidentity.com/fr/resources/identity-fundamentals/authorization/user-account-provisioning.html) 

[Comment le single sign-on fonctionne avec un annuaire](https://www.pingidentity.com/fr/resources/identity-fundamentals/authorization/sso-directory.html) 

[l’Autorisation Dynamique](https://www.pingidentity.com/fr/resources/identity-fundamentals/authorization/dynamic-authorization.html) 

[Gestion centralisée des identités](https://www.pingidentity.com/fr/resources/identity-fundamentals/centralized-identity-management.html) 

[Qu'est-ce que la gestion centralisée des identités ?](https://www.pingidentity.com/fr/resources/identity-fundamentals/centralized-identity-management/what-is-centralized-identity-management.html) 

[Comment fonctionne la gestion centralisée des identités ?](https://www.pingidentity.com/fr/resources/identity-fundamentals/centralized-identity-management/how-does-centralized-identity-management-work.html) 

[Normes liées à l'identité centralisées](https://www.pingidentity.com/fr/resources/identity-fundamentals/centralized-identity-management/authentication-authorization-standards.html) 

[SAML](https://www.pingidentity.com/fr/resources/identity-fundamentals/centralized-identity-management/authentication-authorization-standards/saml.html) 

[OAuth](https://www.pingidentity.com/fr/resources/identity-fundamentals/centralized-identity-management/authentication-authorization-standards/oauth.html) 

[OpenID Connect (OIDC)](https://www.pingidentity.com/fr/resources/identity-fundamentals/centralized-identity-management/authentication-authorization-standards/openid-connect.html) 

[Gestion d’identité décentralisée](https://www.pingidentity.com/fr/resources/identity-fundamentals/decentralized-identity-management.html) 

[Qu'est-ce que la gestion des identités décentralisée ?](https://www.pingidentity.com/fr/resources/identity-fundamentals/decentralized-identity-management/what-is-decentralized-identity-management.html) 

[Comment fonctionne la gestion décentralisée des identités ?](https://www.pingidentity.com/fr/resources/identity-fundamentals/decentralized-identity-management/how-does-decentralized-identity-management-work-.html) 

[En quoi l'identité décentralisée est-elle différente ?](https://www.pingidentity.com/fr/resources/identity-fundamentals/decentralized-identity-management/how-is-decentralized-identity-different.html) 

[Normes d’identité décentralisée](https://www.pingidentity.com/fr/resources/identity-fundamentals/decentralized-identity-management/decentralized-identity-standards.html) 

[Termes courants](https://www.pingidentity.com/fr/resources/identity-fundamentals/decentralized-identity-management/common-terms.html) 

[Gestion des Identités et des Accès](https://www.pingidentity.com/fr/resources/identity-fundamentals/identity-and-access-management.html) 

[Fournisseurs d’identité et fournisseurs de service](https://www.pingidentity.com/fr/resources/identity-fundamentals/identity-and-access-management/identity-providers-service-providers.html) 

[Gestion Centralisée et Décentralisée des Identités](https://www.pingidentity.com/fr/resources/identity-fundamentals/identity-and-access-management/centralized-decentralized-identity-management.html) 

[Orchestration des Identités](https://www.pingidentity.com/fr/resources/identity-fundamentals/identity-orchestration.html) 

[Fournisseurs d'identité et de services](https://www.pingidentity.com/fr/resources/identity-fundamentals/identity-providers-service-providers.html) 

[Sécurité Zero Trust](https://www.pingidentity.com/fr/resources/identity-fundamentals/zero-trust-security.html) 

[Qu'est-ce que la gestion des identités et des accès interentreprises (IAM B2B) ?](https://www.pingidentity.com/fr/resources/identity-fundamentals/b2b-identity.html) 

[Vérification](https://www.pingidentity.com/fr/resources/identity-fundamentals/verification.html) 

[L'authentification des appareils partagés](https://www.pingidentity.com/fr/resources/identity-fundamentals/shared-device-authentication.html) 

Expand All | Collapse All 

# Implémentations de référence et modèles

Cette section fournit des modèles de mise en œuvre concrets et des exemples pratiques qui démontrent comment les entreprises peuvent appliquer efficacement les principes IAM pour prendre en charge les agents d'IA.

## Intégration des agents

L'intégration implique le provisionnement d'un agent d'IA en tant qu'entité unique et non humaine dans le système IAM.

### Intégration des agents gérés

Ce sont les agents gérés par l'entreprise, très probablement des agents interagissant avec des API tels que des chatbots ou des travailleurs numériques.

- **Créez un client ou une application dédié(e) pour l'agent**. L'agent s'identifiera à l'aide de l'identifiant client attribué, même si l'agent est intégré à l'interface utilisateur de l'application client existante.
- **Activez les flux de délégation d'accès pour ce client** (par exemple, appareil-flux, jetons-échange, certification-accord) et l'entreprise que l'agent est adapté au type de flux sélectionné. Appareil-flux est le flux le plus simple et le plus couramment pris en charge dans la plupart des études de cas.
- **Attribuez des champs d'application selon les privilèges minimaux souhaités** à l'agent. Considérez le principe du moindre privilège : attribuez des autorisations minimales par défaut et étendez les autorisations à l'aide d'une authentification et d'un consentement progressifs lorsque c'est nécessaire.
- **Définissez la configuration du jeton**, telle que la durée d'expiration, le jeton d'actualisation, etc., en fonction des besoins de l'agent. Des sessions de courte durée sont recommandées pour les agents.
- **Étiquetez les jetons d'accès de l'agent**. Si le serveur d'autorisation le permet, ajoutez une requête personnalisée au jeton d'accès qui indique clairement que le jeton est délivré à un agent. Si les requêtes personnalisées ne sont pas prises en charge, l'identifiant client dédié de l'agent servira d'étiquette.

### Intégration des agents Bring-Your-Own-Agents (BYOA)

Ces agents ne sont pas gérés par l'entreprise. Au contraire, les utilisateurs individuels peuvent engager des agents pour accomplir des tâches en leur nom.

#### Agents interagissant avec les API

Si vous souhaitez prendre en charge des agents qui interagissent avec les API et qui ne sont pas gérés par l'entreprise, il est recommandé de mettre en place **l'enregistrement dynamique des clients (DCR)**. Les agents devront s'enregistrer eux-mêmes, et chacun d'entre eux recevra un identifiant de client dédié et une configuration d'autorisation conformément aux politiques de règles de l'entreprise (portée, expiration, etc., comme décrit ci-dessus pour les agents gérés).

#### Agents utilisant un ordinateur

Pour les CUA embauchés par des utilisateurs individuels, il n'existe pas de véritable processus d'intégration (puisqu'ils utilisent des agents utilisateurs standard, comme les navigateurs). Au lieu de cela, ces agents seront identifiés de manière similaire à la façon dont vous identifiez les agents utilisateurs contrôlés par des humains, par exemple, l'empreinte digitale de l'appareil.

## Authentification et délégation d'accès

Comme mentionné précédemment, les agents agissant pour le compte des utilisateurs doivent obtenir l'accès pour le compte de l'utilisateur et ne jamais usurper l'identité de celui-ci.

### Agents interagissant avec les API

Utilisez les flux de délégation d'accès OAuth standard tels que configurés pour le client spécifique de l'agent (identifié par l'identifiant client utilisé par l'agent, comme décrit dans la section « onboarding » ci-dessus).

### Agents utilisant un ordinateur

Un CUA qui tente de s'authentifier doit être dirigé vers un flux d'authentification approprié, idéalement automatiquement (en fonction de la détection du CUA), ou comme une option d'authentification disponible dans l'interface utilisateur que l'agent peut sélectionner.

Le flux d'authentification du CUA déclenchera un flux d'accès délégué, comme le flux d'appareil, similaire à celui appliqué aux agents d'interaction de l'API. De cette manière, l'utilisateur humain s'authentifie et délègue explicitement l'accès à l'agent sans exposer ses informations d'identification à l'agent.

## Limiter les autorisations de l’agent

Comme le suggèrent les modèles de mise en œuvre ci-dessus, un agent utilise un jeton d'accès qui indique clairement qu'il s'agit d'un agent et qui peut également inclure un ensemble réduit de champs d'application (par rapport aux champs d'application standard de l'utilisateur lorsqu'il interagit directement).

Une règle d'autorisation, protégeant une ressource, aura connaissance de l'existence du client agentique et appliquera des autorisations plus strictes si nécessaire.

Par exemple, supposons une règle d’entreprise qui exige que les agents aient un accès en lecture seule aux ressources « commandes ». Voici quelques exemples de la manière dont un jeton d'accès pourrait indiquer qu'il a été délivré à un agent :

`// standard client application access token for user-X { "sub": "user-X", "client_id": "app-client-123", "scope": "read:orders write:orders", "aud": "https://api.example.com", "exp": 1712399999 } // API interacting agent access token for user-X { "sub": "user-X", "client_id": "agent-client-456", // different client-id "scope": "read:orders", // limited scopes for read-only "aud": "https://api.example.com", "exp": 1712399999 } // CUA intercting with the standard client application on behalf of user-X { "sub": "user-X", "client_id": "app-client-123", // the client id is of the standard client-app that the agent is interacting with "scope": "read:orders", // limited scopes for read-only "aud": "https://api.example.com", "exp": 1712399999, "act" : {"client_id" : "agent-client-789"} // actor claim pointing to the agent }`

- **Application client standard** : un exemple de jeton d'accès utilisé par l'application standard (par ex. application web) une fois que l’utilisateur s’est connecté

- L'utilisateur est le sujet du jeton (sub claim)
  - L'identifiant client appartient à l'application web
  - La portée mentionne à la fois l'accès en lecture et en écriture
- **Agent d'interaction API** : exemple de jeton d'accès qu'un agent d'interaction API peut obtenir suite à l'authentification de l'utilisateur et à la délégation de l'accès à l'agent.

- L'utilisateur est le sujet du jeton.
  - L'identifiant client appartient à l'agent
  - Le champ d'application ne mentionne que l'accès en lecture seule
- **CUA** : un exemple de jeton d'accès que l'application cliente obtiendra lorsqu'elle est contrôlée par un agent utilisant un ordinateur, après délégation d'accès par l'utilisateur

- L'utilisateur est le sujet du jeton (sub claim)
  - L'identifiant client appartient à l'application web
  - Le champ d'application ne mentionne que l'accès en lecture seule
  - Acte de requête représentant l'acteur qui agit au nom de l'utilisateur, indiquant qu'il s'agit d'un agent basé sur l'identifiant client de l'agent

## Autorisation "human-in-the-loop"

Dans certains cas, au lieu de restreindre les autorisations d'un agent, il peut être autorisé à procéder après une autorisation explicite de l'utilisateur en fonction du contexte (le sujet du jeton d'accès).

Dans ce cas, une règle d'autorisation peut exiger une authentification hors bande et par étapes de la part de l'utilisateur, ainsi qu'un consentement explicite de ce dernier pour approuver les opérations de l'agent en son nom.  

 Considérez, par exemple, la règle illustrative suivante :

`{ "if": { "access_token.client_id": "agent-client-*", "requested_resource": "/orders", "access_token.scope": "!contains:write:orders" }, "then": { "action": "deny", "status": 403, "error": "insufficient_scope", "required_scope": "write:orders", "message": "This operation requires user confirmation via step-up authentication." } }`

Suite à cette réponse, l'agent déclenchera un flux de confirmation utilisateur hors bande qui enverra un OTP à l'utilisateur.

## Surveillance de l’activité des agents

Étant donné que les jetons d'accès des agents sont étiquetés comme tels, il est possible de s'appuyer sur le jeton d'accès comme mécanisme d'étiquetage standard pour indiquer les interactions des agents avec le système IAM et les ressources protégées.

Par exemple, la consultation du journal d'audit sur la base de l'identifiant client (access-token.client-id) permet de scruter les interactions effectuées par l'agent concerné au nom d'un utilisateur.

Sur la base du journal d’audit, il est possible de surveiller l’activité de l’agent et d’alerter sur un comportement anormal ou indésirable de l’agent qui peut être le résultat d’une hallucination, d’un raisonnement erroné ou même de tentatives malveillantes de « jailbreak » de l’agent.

Lancez-vous  
 dès aujourd'hui

Contactez-Nous

[sales@pingidentity.com](mailto:sales@pingidentity.com)

Découvrez comment Ping peut vous aider à offrir des expériences sécurisées aux employés, partenaires et clients dans un monde numérique en constante évolution.