AWS déplace les contrôles de mémoire de l'agent vers la couche passerelle

AWS a ajouté un contrôle d'accès précis à la mémoire Amazon Bedrock AgentCore, offrant ainsi aux développeurs un moyen géré d'isoler la mémoire de l'agent par utilisateur ou locataire via AgentCore Gateway. La version du 28 août déplace une partie sensible de la conception de l'agent dans la politique d'infrastructure : qui peut lire, écrire, récupérer ou modifier la mémoire qu'un agent IA utilise au cours des sessions.

La fonctionnalité utilise l'authentification OAuth JWT et les politiques Cedar, selon AWS. Un connecteur de mémoire géré expose 12 opérations de mémoire en tant qu'actions Cedar, afin que les équipes puissent exprimer des règles d'accès autour des opérations de mémoire au lieu de s'appuyer uniquement sur le code d'application pour filtrer les enregistrements avant ou après chaque appel.

Cela peut ressembler à une petite mise à jour d'autorisation. Ce n'est pas. La mémoire persistante est l'une des principales différences entre une simple interface de discussion et un produit d'agent à long terme. Une fois que les agents se souviennent des préférences utilisateur, du contexte du compte, de l’historique du projet, des décisions antérieures, des cas de support ou de l’état des processus métier, la mémoire devient une limite de sécurité. AWS le traite désormais de cette façon.

Ce qui a changé

La mémoire Amazon Bedrock AgentCore fait partie de la pile d'infrastructure d'agent d'AWS. Il est conçu pour aider les agents à stocker et récupérer le contexte lors des interactions, plutôt que d'obliger chaque équipe d'application à créer sa propre couche de mémoire à partir de zéro.

La nouvelle fonctionnalité de contrôle d'accès permet aux constructeurs d'appliquer une isolation par utilisateur et par locataire via AgentCore Gateway. AWS indique que la fonctionnalité fonctionne avec l'authentification OAuth JWT et Cedar, le langage de politique également utilisé dans d'autres systèmes d'autorisation AWS. La documentation d'AgentCore décrit la stratégie dans AgentCore comme un mécanisme basé sur Cedar pour contrôler l'accès aux outils de passerelle.

Le changement pratique est que l'autorisation de mémoire peut désormais se rapprocher de la passerelle et de la couche d'outils. Au lieu d'écrire des vérifications personnalisées autour de chaque appel de mémoire dans l'application, les équipes peuvent définir des politiques qui déterminent quel appelant peut effectuer quelle action de mémoire dans quel espace de noms ou contexte de locataire.

Pour les logiciels multi-locataires, il s'agit d'un changement architectural significatif. Un assistant IA pour un cabinet d'avocats, une agence, une équipe d'assistance ou un service d'entreprise peut servir de nombreux utilisateurs via le même code d'agent. Le mode d’échec dangereux ne réside pas seulement dans le fait que le modèle donne une mauvaise réponse. Il s’agit du fait que la mémoire d’un locataire est récupérée dans la session d’un autre locataire ou qu’un agent écrit un état sensible dans la mauvaise portée. L'application précise des politiques vise à réduire cette classe d'erreurs.

Pourquoi l'isolation de la mémoire est désormais importante

La mémoire des agents crée un nouveau problème de persistance pour les plates-formes d'IA. Les journaux d'invite, les documents récupérés, les sorties des outils, les préférences utilisateur et l'état du flux de travail peuvent tous faire partie du raisonnement futur. Cela rend la mémoire utile, mais cela rend également plus difficile le raisonnement sur les limites des données.

L'autorisation API traditionnelle se concentre généralement sur une requête : cet appelant peut-il accéder à cette ressource maintenant ? La mémoire des agents étend la question dans le temps. Un enregistrement stocké au cours d'une session peut être récupéré des semaines plus tard par un autre appel d'outil, un autre modèle ou une autre version de l'agent. Si la plate-forme n'intègre pas de contexte d'identité et d'autorisation dans ces opérations de mémoire, la couche mémoire peut devenir une source discrète de fuite entre utilisateurs.

L'utilisation de Cedar par AWS est également importante car elle pointe vers une politique en tant qu'infrastructure pour les systèmes d'agents. Les créateurs d'agents ont de plus en plus besoin de contrôles couvrant les outils, la mémoire, les environnements d'exécution, les clés API et les journaux d'audit. Le fait de placer ces contrôles dans une couche de passerelle donne aux équipes de plate-forme un endroit où appliquer les politiques de manière cohérente, même lorsque les équipes d'application expérimentent différents modèles ou cadres d'agents.

Ceci est directement pertinent pour la conception de passerelles d'API IA. Une passerelle qui achemine uniquement les invites vers les modèles n'est plus suffisante pour les déploiements d'agents sérieux. Le plan de contrôle doit comprendre les identités, les locataires, les outils, les étendues de mémoire, les limites de débit et les pistes d'audit. Model Gate et les plateformes similaires suivent la même direction : l'accès unifié n'est utile que s'il est accompagné de limites applicables.

Qui est concerné

Le public immédiat est constitué des clients AWS qui créent des agents sur Bedrock AgentCore, en particulier les équipes travaillant sur des produits SaaS, des assistants d'entreprise internes, l'automatisation du support client, les agents de recherche et les flux de travail destinés aux partenaires. Tout produit destiné à plusieurs organisations ou équipes à partir d'une infrastructure partagée doit répondre à la même question : comment l'agent sait-il quelle mémoire il est autorisé à utiliser ?

Les développeurs peuvent en bénéficier car ils peuvent s'appuyer sur des contrôles de stratégie gérés au lieu de disperser la logique d'autorisation dans le code de l'application. Cela ne supprime pas la nécessité d'une conception minutieuse, mais cela peut réduire le nombre d'endroits où une erreur peut exposer des données erronées.

Les équipes de sécurité et de plateforme sont également affectées.La mémoire des agents doit désormais être revue comme une base de données, un index de documents ou un magasin de secrets. Le modèle d'accès doit être explicite. La piste d'audit doit montrer quelle identité a accédé à quelle opération de mémoire. L'isolation des locataires doit être testée directement, et non déduite du routage des applications.

Pour les entreprises qui achètent ou créent des systèmes d'agent, cette version constitue une base de référence pour les questions des fournisseurs. Il ne suffit plus de se demander si un assistant a de la mémoire. Les acheteurs doivent se demander comment la mémoire est partitionnée, si l'autorisation est appliquée en dehors du modèle, comment les politiques sont mises à jour et comment l'accès à la mémoire apparaît dans les journaux.

Conséquences pratiques pour les constructeurs

La conséquence la plus évidente est architecturale. Les équipes qui créent des agents à long terme doivent séparer le routage des capacités du modèle des autorisations d'exécution et de mémoire. Un modèle puissant peut être autorisé à raisonner sur une tâche, mais cela ne signifie pas que chaque appel d'outil ou recherche de mémoire doit hériter d'un accès large.

Deuxièmement, les passerelles et les plates-formes d'agent doivent traiter les opérations de mémoire comme des événements de première classe. Les lectures, écritures, recherches, suppressions et mises à jour présentent toutes des profils de risque différents. L'analyse de l'utilisation ne doit pas s'arrêter au nombre de jetons. Pour les charges de travail des agents, les analyses doivent de plus en plus montrer l'utilisation des outils, l'accès à la mémoire, la portée du client, l'identité de l'utilisateur et les résultats des politiques.

Troisièmement, les produits multi-tenant doivent éviter de s'appuyer sur des instructions rapides pour imposer la séparation des données. On peut dire à un modèle de ne pas récupérer le contexte d’un autre client, mais une isolation durable doit être appliquée sous le modèle. Cela signifie des informations d'identification étendues, une politique de passerelle, une conception d'espace de noms et des tests qui prouvent l'échec de l'accès entre locataires.

Enfin, les plates-formes partenaires et revendeurs doivent y prêter attention. Si une API IA pour les agences ou une couche d'automatisation de l'API partenaire permet aux clients en aval de créer des agents, la gouvernance de la mémoire devient partie intégrante du contrat de produit. La plate-forme doit offrir aux partenaires suffisamment de flexibilité pour créer des automatisations utiles sans leur permettre de créer des chemins de partage de données invisibles entre les clients.

Ce qui reste incertain

AWS a décrit le modèle de contrôle et son utilisation des JWT OAuth, des politiques Cedar, de la passerelle AgentCore et des opérations de mémoire gérée. Ce qui reste moins clair dans l'annonce publique est la manière dont les équipes concevront ces politiques dans des déploiements de production complexes, la facilité de débogage des politiques et la quantité de détails opérationnels que les clients obtiendront par défaut dans les journaux.

L'orientation plus large, cependant, est claire. La mémoire des agents devient une infrastructure. Lorsque cela se produit, l’autorisation, l’observabilité et la facturation doivent suivre jusqu’à la couche passerelle. Les entreprises qui créent des plates-formes d'agents fiables seront celles qui pourront rendre l'accès aux modèles, les autorisations des outils et l'état de la mémoire visibles et gouvernables en un seul endroit.