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 organisations 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'organisation, 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é à ce client, 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 s'assurer 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’organisation. 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 l'API et qui ne sont pas gérés par l'organisation, 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 l'organisation (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 politique d'autorisation, protégeant une ressource, sera consciente de l'existence du client agentique et appliquera des autorisations plus strictes si nécessaire.
Par exemple, supposons une politique 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 avec boucle humaine
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 politique 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 politique 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
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.