Présentation des stratégies IAM

Vous pouvez créer des stratégies d'autorisation et de refus IAM qu'Agent Gateway utilise pour régir de manière sécurisée la communication agentique entre vos agents et d'autres services, y compris d'autres agents, des serveurs MCP et des points de terminaison. Agent Gateway utilise Identity-Aware Proxy (IAP) pour appliquer les règles. IAP applique également une sécurité d'authentification et d'autorisation de l'identité de l'agent de bout en bout.

Pour créer une stratégie IAM pour Agent Gateway, consultez Créer des stratégies IAM.

Vous pouvez également créer une limite d'accès des principaux (PAB) sur l'identité de l'agent. Agent Gateway peut utiliser IAP pour appliquer des stratégies Limite d'accès des principaux.

Activer la passerelle d'agent

Pour utiliser des règles de communication agentiques, vous devez configurer Agent Gateway.

Nous vous recommandons de configurer Agent Gateway en mode dry run (DRY_RUN) dans un environnement de préproduction pour vérifier que vos règles fonctionnent comme prévu. En mode simulation, IAP consigne les communications agentiques non autorisées dans Cloud Audit Logs, mais ne les bloque pas.

Lorsque vous êtes certain que les règles fonctionnent correctement, vous pouvez mettre à jour la configuration de la passerelle d'agent pour définir le mode d'application sur ENFORCE. Dans ce mode, les communications agentiques qui enfreignent le règlement ne sont pas autorisées et les communications vers la ressource sont bloquées.

Composants des règles

Les règles se composent des éléments suivants :

• Agents : dans vos règles d'autorisation IAM, les agents sources sont définis par leur identité d'agent (l'identité de l'agent qui initie la communication avec un service). Pour savoir comment les différents types d'agents reçoivent des identités, consultez Identité de l'agent. Les identités d'agent sont représentées par des identifiants de principal qui contiennent l'identité de l'agent au format SPIFFE, par exemple principal://agents.global.org-.... Notez que les identifiants d'agent au format URN (tels que urn:agent:...) sont utilisés uniquement pour la recherche dans l'inventaire et le catalogue, et ne sont pas utilisés dans les liaisons de stratégie IAM. Lorsque vous utilisez la gcloud CLI pour configurer la stratégie IAM, le compte principal de l'agent est le membre auquel vous accordez l'accès.

  Les agents Gemini Enterprise et les instances Agent Runtime se voient automatiquement attribuer une identité d'agent et sont enregistrés dans le registre d'agents.

• Ressource Agent Registry : service Agent Registry pour lequel vous accordez ou refusez l'accès. Dans les stratégies IAM d'autorisation et de refus, les services du registre d'agents sont appelés ressources. La ressource peut être un registre entier dans un projet ou un service individuel, qui peut être un serveur MCP, un agent ou un point de terminaison.

  Les services individuels doivent être enregistrés dans le registre d'agents avant de pouvoir être référencés dans une règle IAM. Cette inscription est validée au moment de la liaison (lorsque la liaison de stratégie est créée ou mise à jour). Si vous faites référence à un service qui n'est pas enregistré, la création de la règle échoue immédiatement et une erreur "Entité demandée introuvable" (NOT_FOUND) s'affiche.

  Lorsque vous configurez des règles à l'aide de gcloud CLI ou de Terraform, les ressources cibles sont spécifiées par leurs chemins ou ID générés par le registre (à l'aide d'indicateurs tels que --agent, --endpoint ou --mcp-server), plutôt que par leurs identifiants URN logiques. Lors de l'exécution, la passerelle sécurisée fait correspondre les destinations du trafic à leur nom d'hôte exact au lieu d'utiliser des URN.

  Si vous régionalisez vos registres d'agents, votre règle d'autorisation IAM ne s'applique qu'aux ressources qui se trouvent dans la région du registre.

• Rôle : les règles de communication agentique accordent toujours le rôle Sortant sécurisé par IAP (roles/iap.egressor) sur la ressource de service.

• Condition : vous pouvez éventuellement configurer une condition sur la stratégie d'autorisation IAM pour restreindre davantage l'accès de l'agent. Dans la consoleCloud de Confiance , vous pouvez utiliser le générateur de conditions pour créer une condition en sélectionnant des éléments d'interface utilisateur. Vous pouvez également utiliser l'éditeur de conditions pour saisir des conditions plus complexes sous forme d'expressions CEL (Common Expression Language).

  Le tableau suivant liste les noms d'attributs que vous pouvez utiliser pour construire des expressions CEL. Étant donné que le style d'accès direct aux champs (tel que request.mcp.toolName) n'est pas pris en charge, vous devez utiliser la fonction api.getAttribute() pour récupérer la valeur de chaque attribut.

  Pour savoir comment configurer des stratégies d'autorisation avec des conditions, consultez Configurer des règles d'agent IAM.

  Nom de l'attribut	Description et exemple CEL
  mcp.toolName	Nom de l'outil spécifique appelé. Par exemple : request.mcp.toolName == 'GetCalendarEvents'
  iap.googleapis.com/mcp.resourceName	Nom de la ressource consultée. Par exemple : api.getAttribute('iap.googleapis.com/mcp.resourceName', '') == 'my-resource'
  iap.googleapis.com/mcp.promptName	Nom de la requête utilisée. Par exemple : api.getAttribute('iap.googleapis.com/mcp.promptName', '') == 'my-prompt'
  mcp.method	Opération MCP spécifique (par exemple, tools/call, resources/read).
  iap.googleapis.com/mcp.tool.isReadOnly iap.googleapis.com/mcp.tool.isDestructive iap.googleapis.com/mcp.tool.isIdempotent iap.googleapis.com/mcp.tool.isOpenWorld	Indicateurs booléens indiquant le type d'opération. Par exemple : api.getAttribute('iap.googleapis.com/mcp.tool.isReadOnly', false) == true
  request.auth.type	Énumération indiquant le protocole (par exemple, "MCP").

Créer des règles

Sur la page Règles de la console Cloud de Confiance , vous créez des stratégies d'autorisation et de refus IAM que l'Agent Gateway utilise pour régir les communications agentiques.

Dans la gcloud CLI, vous pouvez configurer des stratégies d'autorisation et de refus IAM qu'Agent Gateway utilise pour régir les communications agentiques.

Règles dans la console Cloud de Confiance

Pour créer des stratégies IAM à l'aide de la console Cloud de Confiance , consultez Configurer des stratégies IAM.

Règles dans la gcloud CLI

Pour créer des stratégies IAM à l'aide de gcloud CLI, consultez Configurer des stratégies IAM.

Authentification et autorisation de bout en bout

IAP et l'accès contextuel fournissent une authentification et une autorisation par défaut de l'identité de l'agent de bout en bout à l'aide des protocoles suivants :

• TLS mutuelle (mTLS)
• Démontrer la preuve de possession (DPoP)

Les identités d'agent sont provisionnées avec un certificat X.509 et un jeton lié à un certificat. IAP exige que les identités d'agent utilisent le protocole TLS mutuel (mTLS) pour s'authentifier auprès d'Agent Gateway. Lorsque la passerelle autorise l'agent à sortir et à accéder aux API Cloud de Confiance , aux serveurs MCP, aux autres agents et aux points de terminaison, l'agent tente d'accéder en dehors de la limite mTLS. Pour protéger les communications, l'accès contextuel applique une règle d'accès contextuel gérée par Google. La règle exige que DPoP valide le jeton lié au certificat qui est lié à l'identité de l'agent. Pour en savoir plus sur la façon dont l'accès contextuel assure la sécurité mTLS et DPoP de bout en bout, consultez Sécurité de l'agent d'accès contextuel.

Étapes suivantes