Architecture de référence IAM de l'agent AI : identité et accès

Séparez les sept limites de contrôle¶

Une connexion réseau réussie prouve l'accessibilité. L'authentification vérifie une identité. L'autorisation résout ce à quoi cette identité peut accéder. La stratégie d’exécution évalue cette action et ce contexte. L'approbation donne à une personne éligible une décision limitée. L'exécution crée l'effet secondaire. Les preuves enregistrent l'unité complète pour examen.

Gardez chaque limite explicite dans l'architecture et le modèle d'événement. Un identifiant valide peut toujours manquer d’autorité pour l’objectif, le montant, les données, l’environnement ou l’heure demandés. Une évaluation politique réussie peut toujours nécessiter un examinateur indépendant. Une approbation ne peut libérer que la demande exacte et le contexte qu’elle couvre.

Contexte système et classes d'identité¶

Traitez l'identité de l'agent comme l'objet métier durable et l'identité de la charge de travail comme l'instance logicielle en cours d'exécution. Une identité de service représente une dépendance ou une passerelle non humaine. L'outil ou le serveur de ressources authentifie l'appelant et applique sa propre autorisation. Un évaluateur utilise une identité humaine avec une autorité décisionnelle actuelle.

Alternative textuelle. Un utilisateur humain délègue un objectif limité à un agent et à une charge de travail. Les services d'identité et de jetons authentifient les parties. L'autorisation et la politique évaluent la demande. Un évaluateur décide des actions retenues. L'outil exécute une action autorisée. Chaque étape envoie des enregistrements au magasin de preuves à l’intérieur de la limite de confiance du locataire et de l’organisation.

Faites défiler horizontalement pour examiner le visuel.

Choisissez une identité dédiée, déléguée ou hybride¶

Une identité dédiée donne à l'agent sa propre identité appartenant à l'entreprise autorité. Une identité déléguée confère l’autorité actuelle d’un utilisateur à la tâche. Un hybride enregistre les deux parties : l’agent reste l’acteur et l’humain reste le sujet ou le sponsor. Cette séparation prend en charge une politique, une révocation et un audit précis.

Les comptes de services partagés affaiblissent l'attribution et offrent souvent un accès étendu. Conservez-les derrière une passerelle médiée par les services lorsqu'un système cible ne peut pas émettre d'informations d'identification d'agent restreintes. Enregistrez l’agent d’origine, le sujet humain, la décision politique et la réception en aval pour chaque appel médiatisé.

Demande et séquence de pouvoirs délégués¶

Liez le sujet humain, l'acteur agent, la charge de travail, la délégation, l'objectif, la cible et l'expiration avant l'émission du jeton. Utilisez un identifiant de courte durée lié à l’audience pour la ressource cible. Résolvez à nouveau l'autorité actuelle au niveau de la limite de l'action, car les rôles, les affectations, les faits de risque et la politique peuvent changer au cours d'une session.

Alternative textuelle. L'utilisateur attribue un objectif à l'agent. L'agent démarre une charge de travail attestée. La charge de travail demande un jeton. Le service de jetons valide l'acteur et le sujet délégué, puis délivre un identifiant de courte durée lié au public. La charge de travail envoie le contexte complet à la stratégie. L'outil reçoit uniquement une demande autorisée ou valablement approuvée et renvoie un accusé de réception d'exécution.

Faites défiler horizontalement pour examiner le visuel.

Posséder toutes les dimensions des droits¶

Le principe du moindre privilège devient vérifiable lorsque chaque dimension a un responsable, un point de décision, un chemin de revue, un chemin de révocation et un champ de preuve. Évaluez le tuple complet pour chaque demande conséquente. Un rôle peut fournir une base de référence, tandis que la finalité, la valeur, les données, l’environnement et le temps maintiennent l’autorisation effective dans un périmètre étroit.

Combiner délibérément les modèles d'autorisation¶

Le contrôle d'accès basé sur les rôles fournit une base de travail ou de service stable. Le contrôle d'accès basé sur les attributs évalue les faits sur le sujet, la ressource, l'action et l'environnement. Le contrôle d'accès basé sur les relations résout les relations de graphique telles que l'affectation, la propriété ou l'appartenance à un cas. L'accès basé sur les capacités comporte un objet d'autorité transférable étroit qui doit rester limité à un objectif, limité dans le temps et révocable.

Utilisez la plus petite combinaison qui exprime la vraie décision. Enregistrez les entrées résolues et l'octroi effectif final afin que les réviseurs puissent reproduire le résultat après des changements de groupes, d'attributs, de relations ou d'état de capacité.

Flux de décision en matière de droits et d'approbation¶

Évaluez l'identité, le locataire, la délégation, l'audience et l'expiration avant de résoudre les droits. Une autorité invalide ou manquante arrête la demande. La stratégie d'exécution sélectionne ensuite autoriser, avertir, require_approval ou bloquer. Une approbation requise contient la demande exacte et ne la libère qu'après la décision d'un évaluateur indépendant éligible avant l'expiration.

Texte alternatif. Le flux vérifie l'identité et le contexte du jeton, puis les neuf dimensions des droits. Blocs de contexte invalides. La politique sélectionne l’un des quatre résultats. Le bloc s'arrête. Exiger l'approbation envoie la demande liée à un réviseur indépendant. Le rejet ou l’expiration s’arrête. Autoriser, avertir ou valider l'approbation s'exécute une seule fois et enregistre le reçu et les preuves.

Faites défiler horizontalement pour examiner le visuel.

Issue short-lived credentials et control impersonation¶

Issue credentials after workload authentication et current authority resolution. Liez chaque identifiant à un public, un domaine de confiance, un environnement, une relation de sujet ou d'acteur, un objectif, une portée et une courte durée de vie. Gardez les privilèges d’actualisation et d’échange plus restreints que ceux de l’autorité d’origine.

OAuth 2.0 Token Exchange définit des jetons de sujet et d'acteur distincts pour la délégation. La revendication « acte » peut exprimer l'acteur actuel. Les indicateurs de ressources lient une demande de jeton à la ressource cible. Les demandes d'autorisation enrichies peuvent contenir des actions structurées et des détails sur les ressources. Chaque protocole s'appuie toujours sur le serveur d'autorisation et le serveur de ressources pour appliquer la politique locale et la révocation.

• Juste à temps : accordez l'accès au démarrage de la tâche, après approbation ou affectation, et faites-le expirer avec la tâche.
• Rotation: automate key et credential replacement, retain generation et overlap evidence, et test le old credential after cutover.
• Limite d'usurpation d'identité : réservez l'usurpation d'identité aux cas explicites où l'acteur devient indiscernable au niveau de la cible ; conserver l’acteur original dans un dossier protégé distinct.
• Limite de délégation : maintient le sujet et l'acteur visibles et réduit l'autorité déléguée pour la tâche.
• Gestion des jetons : exclut les secrets bruts des journaux ; conserver l'émetteur, l'identifiant ou le résumé du jeton, l'audience, les portées, la durée d'effet, l'expiration et le résultat de la révocation.

Politique réutilisable à privilèges minimaux¶

La politique ci-dessous est un exemple de conception indépendant des fournisseurs pour un lecteur de documents de revue de crédit. Elle couvre les neuf dimensions d’habilitation et associe tout contexte manquant ou expiré à un blocage. Téléchargez le fichier JSON pour les ateliers et les tests. Remplacez chaque identifiant et seuil synthétique par un contrat local approuvé.

{
  "schema_version": "1.0",
  "policy_id": "credit-review-document-reader",
  "status": "example",
  "subject": {
    "agent_id": "credit-review-agent",
    "workload_id": "spiffe://bank.example/prod/credit-review",
    "delegated_user_required": true
  },
  "entitlements": {
    "tools": [
      "credit_application.read",
      "credit_memo.draft",
      "credit_decision.propose"
    ],
    "resources": [
      "credit-application:{case_id}"
    ],
    "data": {
      "fields": [
        "declared_income",
        "verified_income",
        "existing_exposure",
        "requested_amount"
      ],
      "denied_fields": [
        "special_category_data",
        "unrelated_household_records"
      ]
    },
    "actions": [
      "read",
      "draft",
      "propose_credit_decision"
    ],
    "purposes": [
      "credit_application_review"
    ],
    "amount": {
      "currency": "EUR",
      "approval_threshold": 25000,
      "authorization_ceiling": 100000
    },
    "environments": [
      "production"
    ],
    "time": {
      "maximum_token_lifetime_seconds": 900,
      "access_window": "case_assignment"
    }
  },
  "decision": {
    "allow_when": [
      "case_id matches the assigned case",
      "delegated user remains assigned and active",
      "all requested fields are allowed",
      "purpose equals credit_application_review",
      "requested amount is at or below EUR 25000",
      "token audience matches the target resource"
    ],
    "require_approval_when": [
      "the agent proposes a credit decision",
      "the requested amount exceeds EUR 25000 and is at or below EUR 100000"
    ],
    "block_when": [
      "identity, delegation, tenant, purpose, or audience is missing",
      "the credential, assignment, entitlement, or policy is expired",
      "the request targets an unassigned case or forbidden field",
      "the requested amount exceeds EUR 100000",
      "the destination or purpose differs from the authorized values",
      "the policy decision service cannot produce the required verdict"
    ]
  },
  "evidence": [
    "principal_id",
    "agent_identity_id",
    "workload_identity_id",
    "delegation_id",
    "tenant_id",
    "tool_id",
    "resource_id",
    "data_boundary_ref",
    "action",
    "purpose",
    "amount",
    "environment",
    "requested_at",
    "expires_at",
    "policy_id",
    "policy_version",
    "authentication_event_id",
    "authorization_decision_id",
    "policy_decision_id",
    "approval_decision_id",
    "reason_codes",
    "approval_id",
    "reviewer_id",
    "execution_receipt"
  ]
}

Run le entitlement review as a control¶

Une revue commence par une population rapprochée d’identités et d’accès, puis teste l’autorité effective et les usages observés. Téléchargez le cahier de travail d’architecture IAM pour la liste de contrôle complète, les tableaux de décision et l’enregistrement de revue.

• Réconciliez la population. Comparez les agents enregistrés et les comptes de service avec les émetteurs de jetons, les principaux cloud, les magasins secrets, les passerelles, la découverte MCP, les identités CI/CD, les dépenses de packages et les appels d'outils observés.
• Résoudre l'accès effectif. Inclut les subventions directes, les rôles, les attributs, les relations, les capacités, les groupes, les délégations, l'accès temporaire, les règles de stratégie et les autorisations en aval.
• Trouver des exceptions de contrôle. Enregistrez l'autorité orpheline, partagée, dormante, en double, expirée, non observée, entre locataires, auto-approuvable et trop large.
• Test d'application. Demandes d'exercice autorisées, d'approbation, bloquées, expirées, sans contexte, révoquées et de relation obsolète.
• Réconcilier les résultats. Joignez chaque échantillon au résultat de la politique, à la décision de l'examinateur, à la réception de l'outil, à l'état de l'entreprise et au dossier de preuves.
• Certifier le résultat de la portée. Enregistrez les critères, la population, la période, l'examinateur, les exceptions, la décision, l'expiration, la prochaine révision et les références de preuves.

Découvrez et auditez les comptes de service¶

Créez la population d'identité non humaine à partir de plusieurs sources indépendantes. Les répertoires d'identités à eux seuls manquent les informations d'identification créées dans les projets cloud, les systèmes CI/CD, les magasins de secrets, les clients MCP locaux, les planificateurs, l'automatisation du navigateur et les applications en aval. Les observations des passerelles et des réseaux révèlent des identités qui contournent le catalogue attendu.

Pour chaque compte de service, enregistrez le processus propriétaire, la personne responsable, les agents et les charges de travail qui peuvent l'utiliser, l'emplacement des informations d'identification, les cibles autorisées, les subventions effectives, la dernière utilisation, l'expiration, la rotation, la méthode de révocation et la source des preuves. Mettez en quarantaine ou révoquez les comptes sans propriétaire actuel ni utilisation approuvée après l'examen de sécurité défini.

Révoquer, arrêter, annuler et récupérer¶

La révocation ferme l'autorité pour une utilisation future. L'arrêt d'urgence contient des travaux actifs et en attente. La restauration restaure une version ou une configuration connue. La récupération après incident concilie les effets en aval, émet de nouvelles informations d'identification, teste l'état de sécurité et utilise une décision de redémarrage distincte.

Texte alternatif. Le propriétaire de l'incident enregistre la portée affectée et active un état de refus. Les contrôles de workflow annulent le travail actif et en file d'attente. Les contrôles d'identité désactivent l'agent et la charge de travail, révoquent les jetons et alternent les informations d'identification. Les passerelles refusent les nouvelles demandes. Les propriétaires d’outils concilient les effets acceptés et engagés. Les preuves enregistrent les accusés de réception et les accès résiduels. La récupération utilise une version connue, de nouvelles informations d'identification, une liste blanche étroite et l'approbation du redémarrage.

Faites défiler horizontalement pour examiner le visuel.

Appliquer les limites du locataire et de l'organisation¶

Traitez le locataire, l'organisation, le domaine de confiance, l'environnement et la région comme des faits d'autorisation avec des émetteurs faisant autorité. Validez-les à chaque limite externe et utilisez-les dans les requêtes de banque de données, les audiences de jetons, le contexte politique, la recherche d'approbation, le routage des outils et la sélection de preuves.

Conservez les identités de production et de non-production dans des domaines de confiance distincts ou des espaces de noms équivalents. Qualifier les attributs et rôles étrangers par leur autorité de délivrance. La fédération établit les informations d'identification qui peuvent être authentifiées dans tous les domaines ; l’autorisation locale décide toujours quelle action et quelle ressource chaque identité étrangère peut utiliser.

• Rejetez un sélecteur de locataire ou d'organisation qui entre en conflit avec le jeton authentifié.
• Liez les identifiants de ressources, les limites des relations, les capacités et les approbations à un seul locataire.
• Utilisez des audiences de jetons spécifiques à une cible et évitez les jetons de support acceptés par plusieurs ressources non liées.
• Testez les lectures, écritures, approbations, délégations, clés de cache, files d'attente et exportations de preuves entre locataires.
• Enregistrez le locataire faisant autorité et le domaine de confiance dans chaque événement d'identité, de stratégie, d'exécution et de preuve.

Attribuez des responsabilités tout au long du cycle de vie¶

Nommez un rôle responsable pour chaque identité, droit, décision, effet et limite de preuve. Les groupes consultatifs peuvent examiner la conception. L'autorité opérationnelle reste attribuée à une personne ou à un rôle avec un délégué, une période d'effet et un chemin d'escalade définis.

Sélectionnez un modèle de déploiement¶

Choisissez le modèle parmi le propriétaire de l'autorité, la capacité du système cible, la conséquence de l'action, le volume d'identité et l'attribution requise. Une seule organisation peut utiliser plusieurs modèles dans ses processus tout en préservant un seul modèle de preuves.

Exemple concret : examen du crédit réglementé¶

Une banque affecte un agent d'examen du crédit au dossier CR-1842. L'agent dispose d'une identité dédiée et s'exécute sous une charge de travail de production attestée. Un souscripteur désigné est le sujet délégué pour ce cas. Le service de jetons émet un identifiant de 15 minutes dont le public est le service de documents.

L'autorisation autorise quatre champs approuvés, trois actions et s'élève à EUR 100,000 dans le but credit_application_review pendant que l'affectation reste active. La politique permet de lire ces champs et de rédiger un mémo. Une proposition de décision de crédit ou une demande supérieure à EUR 25,000 crée un Decision Request. Un nouvel objectif, un champ interdit, un montant supérieur au plafond d'autorisation ou des blocs d'identité, de délégation, de locataire, d'audience ou de politique actuelle manquants. L'agrément s'effectue à l'intérieur du plafond d'autorisation.

Le souscripteur demandeur ne peut pas décider de la demande retenue. Un deuxième évaluateur qualifié voit l'action exacte, les sources de preuve, les raisons politiques, les exigences d'autorité, l'expiration et l'effet attendu. L’approbation libère la même demande liée une fois. La réception en aval et l'état du dossier rejoignent les enregistrements d'identité, de délégation, d'autorisation, de politique, de réviseur et d'exécution.

Comment l'architecture correspond aux contrats KLA actuels¶

Le KLA Control Plane régit les actions des agents instrumentés. L'implémentation actuelle fournit une politique d'exécution, une approbation, une exécution, un traçage et une couche de preuves. Les fournisseurs d'identité d'entreprise, les serveurs de ressources et les systèmes d'identification restent l'autorité en matière d'identités et d'octrois.

Le mappage ci-dessous reflète le code présent dans la source du référentiel lors de la validation a4e8087f. Le comportement de déploiement et de production reste non vérifié. Les liens sources sont épinglés à ce commit. Le statut distingue un contrat en cours d'une cartographie partielle ou d'une abstraction conceptuelle.

Lacunes actuelles de la KLA et abstractions conceptuelles¶

KLA évalue et enregistre l'autorité au niveau de la limite d'action gouvernée. Cela ne relève pas de plusieurs responsabilités IAM d’entreprise dans cette référence. Traitez les champs et les flux ci-dessous comme des exigences d'intégration jusqu'à ce que l'écart indiqué fasse l'objet d'un contrat actuellement mis en œuvre.

• Sujet délégué. La création de l'exécution définit actuellement onBehalfOfSubject sur le sujet initiateur et enregistre le client appelant. Le contrat d'exécution publique complet ne dispose actuellement pas d'un sujet d'utilisateur final et d'une chaîne de délégation attestés séparément.
• Cycle de vie de l'identité. Les fournisseurs d'identité d'entreprise, les autorités d'attestation de charge de travail, les annuaires RH et les systèmes de découverte de comptes de service universel restent des dépendances externes.
• Cycle de vie des informations d'identification. Les connecteurs et les systèmes cibles possèdent leurs propres outils d'émission, de rotation, de révocation, de courtage et d'actionnement des informations d'identification en aval.
• Normalisation des droits. Les contrats actuels prennent en charge le principal, la ressource, l'action, les attributs, les arguments de l'outil, l'environnement et le contexte flexible. Chaque chemin peut représenter l'objectif, le montant, les données et les faits relationnels via des champs flexibles ; le contrat laisse leur normalisation au producteur.
• Modèles d'autorisation. Les modèles RBAC, ABAC, de relation et de capacité dans cette référence sont des choix d'architecture. Le contrat politique actuel de l’KLA est indépendant du modèle.
• Certification. Le produit actuel enregistre les contrôles et les preuves. La certification universelle de l’identité d’un agent ou d’une population ayant droit à des droits reste en dehors du contrat actuel.
• Distribution de révocation. L'annulation de l'exécution est implémentée. La désactivation de l'identité de bout en bout, la révocation des jetons, l'isolation du réseau, l'annulation en aval et la compensation restent des actions externes coordonnées.
• Enregistrement portable. Le Schéma du journal d’audit de l’agent IA normalise plusieurs producteurs KLA en un seul événement indépendant du fournisseur. Les producteurs actuels émettent leurs enregistrements natifs faisant autorité, que la référence mappe dans l'enveloppe publique.

Sources primaires et fraîcheur¶

Cette architecture a été vérifiée le 28 juillet 2026. Les normes d’identité, les spécifications de protocole, les projets de directives et les profils de mise en œuvre peuvent changer. Revérifiez la source active et le déploiement local avant d'utiliser un statut dans une décision d'audit, d'approvisionnement ou de sécurité.

• [Document conceptuel sur l'identité et l'autorisation des logiciels NIST NCCoE et des agents IA] (https://www.nccoe.nist.gov/publications/other/accelerating-adoption-software-and-ai-agent-identity-and-authorization-concept) (projet, publié le 5 février 2026) Sources : source
• NIST SP 800-162, Guide to Attribute Based Access Control
• Projet de contrôle d'accès basé sur les rôles NIST et référence standard actuelle
• NIST SP 800-207, Zero Trust Architecture
• RFC 8693, OAuth 2.0 Token Exchange
• RFC 8707, Indicateurs de ressources pour OAuth 2.0
• RFC 9396, OAuth 2.0 Rich Demandes d'autorisation
• Norme SPIFFE 1.15.2 et spécifications d'identité de charge de travail
• Spécification d'autorisation du modèle de contexte de protocole, 25 novembre 2025
• meilleures pratiques de sécurité du modèle de contexte de protocole