{"schema_version":"1.0","service":"Publicasta","type":"article","id":685,"slug":"aws_tolap_object_level_access_control_ai_agent_tools","title":"La version TOLAP d’AWS intègre le contrôle d’accès au niveau des objets dans les outils d’agents IA","excerpt":"Le projet TOLAP d’AWS Labs déplace le point de contrôle vers l’outil qui récupère les données : il peut filtrer les lignes, masquer des champs, limiter les résultats et vérifier les actions ou délégations avant l’entrée dans le contexte de l’agent.","language":"fr","default_language":"en","canonical_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools?lang=fr","image":{"url":"https://publicasta.com/storage/projects/17/pages/685/2026/09/0c39e23c-eced-4768-8478-b862e126dd99.webp","alt":"Un outil sécurisé pour agent d’IA filtre les données de bases et d’API via une couche de contrôle d’accès au niveau des objets avant leur arrivée dans le contexte de l’agent."},"publisher":{"id":17,"slug":"it_today_news","name":"IT Today","url":"https://publicasta.com/it_today_news"},"author":{"name":"Anton R"},"published_at":"2026-09-24T06:49:57+00:00","updated_at":"2026-09-24T06:49:57+00:00","content_markdown":"Le détail le plus important du nouveau projet TOLAP d’AWS n’est pas son acronyme. C’est l’endroit où s’exerce le contrôle.\n\n ![Un outil sécurisé pour agent d’IA filtre les données de bases et d’API via une couche de contrôle d’accès au niveau des objets avant leur arrivée dans le contexte de l’agent.](https://publicasta.com/storage/projects/17/pages/685/2026/09/0c39e23c-eced-4768-8478-b862e126dd99.webp)\n\n AWS Labs a publié TOLAP, ou *Tool-Object Level Access Protocol*, comme couche de sécurité open source pour les outils d’agents IA. Le projet vise à décider quelles données peuvent sortir d’un outil après son invocation par un agent : quelles lignes sont visibles, quels champs doivent être masqués ou dissimulés, quels points d’accès sont autorisés, combien de résultats peuvent être renvoyés et si l’action demandée reste conforme à l’objectif de la délégation. Cette première version publique montre que la sécurité des agents s’éloigne d’une question simple — « cette identité peut-elle appeler cette API ? » — pour s’attaquer à une question plus difficile : « que peut exactement divulguer ou modifier cet appel précis ? »\n\n Cette distinction compte pour les équipes qui construisent des agents au-dessus de bases de données, d’API internes, de bases de connaissances, de stockages d’objets et de serveurs MCP. Un contrôle de permission classique peut autoriser une connexion tout en laissant l’outil renvoyer beaucoup plus de données que nécessaire pour l’utilisateur ou le workflow. La proposition de TOLAP consiste à placer un *wrapper* de politique autour de la fonction qui récupère ou modifie réellement les données, puis à appliquer cette politique avant que le résultat n’entre dans le contexte de l’agent.\n\n Le projet ne remplace ni la gestion des identités, ni les contrôles réseau, ni les permissions de la base de données, ni l’approbation humaine. Il s’agit d’un contrôle plus ciblé, conçu pour réduire l’écart entre l’accès à un outil et l’exposition d’objets précis.\n\n ## Ce qu’AWS a publié\n\n AWS Open Source décrit TOLAP comme une couche d’application des règles au point source. Le dépôt est disponible sous licence Apache 2.0 et comprend un schéma de politiques, des bibliothèques d’application pour .NET, Python et TypeScript, un serveur de politiques de référence, des exemples, de la documentation et des intégrations avec des frameworks d’agents et d’outils courants.\n\n Le modèle central est déclaratif. Une politique peut identifier les objets et actions autorisés, dissimuler certains champs, masquer des valeurs, filtrer des lignes, restreindre des préfixes de stockage ou des méthodes d’API, imposer des limites de résultats et joindre des informations d’audit. Les exemples utilisent un jeu de données de type santé : un agent peut être autorisé à interroger des dossiers de patients sans recevoir les numéros de sécurité sociale ; les adresses e-mail peuvent être renvoyées sous forme de hachages ; et les lignes peuvent être limitées à certaines régions.\n\n Cette approche diffère d’un identifiant de base de données disposant d’un accès en lecture étendu, associé à la consigne de demander au modèle de se comporter correctement. Dans le modèle TOLAP, l’agent peut toujours construire une requête par l’intermédiaire de l’outil, mais le wrapper applique la politique effective au résultat. Les données refusées par la politique sont retirées avant de faire partie du contexte du modèle.\n\n AWS indique que les SDK partagent un schéma de politiques versionné et des jeux de tests communs, afin que les implémentations soient censées se comporter de manière identique dans les différents langages. Le dépôt comprend aussi des intégrations pour les SDK MCP, Strands, LangChain, LangChain.js, Vercel AI SDK, Mastra, OpenAI Agents, Pydantic AI, Semantic Kernel et Bedrock Agents. Ces intégrations ne transforment pas TOLAP en serveur MCP. Le projet enveloppe la fonction utilisée par la couche outil ; l’application reste propriétaire de la récupération des données.\n\n Pour un usage en production, le dépôt inclut un serveur de politiques reposant sur PostgreSQL, des versions de politiques immuables, des opérations de publication et de restauration, une piste d’audit, une administration authentifiée par Cognito et une rotation des clés de signature avec une fenêtre de chevauchement. Ces composants constituent une infrastructure de référence ; ils ne signifient pas que chaque organisation doive déployer la pile complète.\n\n ## Pourquoi l’autorisation ordinaire des outils ne suffit pas\n\n La plupart des architectures d’agents disposent déjà de plusieurs couches de permission. Un utilisateur s’authentifie auprès d’une application. L’application donne à un agent une identité de service ou un jeton délégué. Une passerelle vérifie le jeton. L’outil appelle une base de données ou une API. Chaque couche a son utilité, mais aucune ne répond automatiquement à la question du niveau objet.\n\n Prenons un agent interne d’assistance autorisé à interroger une table de clients. Un contrôle de rôle peut établir correctement que l’application d’assistance peut appeler l’outil de recherche client. Il ne dit pas nécessairement :\n\n - quels clients l’employé demandeur a le droit de consulter ;\n- quelles colonnes doivent être omises ;\n- si le résultat peut contenir des clients situés hors de la région de l’employé ;\n- si une adresse peut être renvoyée intégralement ;\n- si la requête peut renvoyer 5 000 lignes ;\n- si une opération de lecture est devenue discrètement une opération d’exportation.\n\n Une passerelle peut autoriser le point d’accès. La base de données peut appliquer des droits. L’application peut filtrer les réponses. Mais lorsque ces décisions sont dispersées dans du code personnalisé, la frontière effective devient difficile à inventorier et à tester. Plus une organisation ajoute de frameworks, de connecteurs et de moteurs d’agents, plus il devient facile qu’un chemin oublie un contrôle.\n\n L’argument architectural de TOLAP est que l’outil constitue le dernier endroit fiable pour empêcher des données d’entrer dans le contexte de l’agent. Les instructions du prompt ne sont pas une frontière de sécurité. Un modèle peut mal comprendre une règle, suivre une instruction malveillante présente dans un contenu récupéré ou combiner des résultats autorisés individuellement pour produire une divulgation imprévue par le concepteur. Si un champ sensible ne franchit jamais le wrapper, le modèle ne peut pas le récupérer depuis son contexte.\n\n Cela ne rend pas l’outil fiable par magie. Le wrapper doit être le seul chemin vers la source protégée, et l’application doit empêcher des identifiants alternatifs ou du code non enveloppé d’atteindre les mêmes données. L’application au point source n’est utile que lorsque ce point source est réellement contrôlé.\n\n ## La version ajoute davantage que le filtrage des lignes et des champs\n\n Les contrôles au niveau objet de la première version sont la partie la plus immédiatement compréhensible du projet. Les éléments plus récents décrivent aussi des contrôles portant sur l’objectif et la séquence des actions de l’agent.\n\n Les politiques TOLAP peuvent inclure des profils d’objectif qui restreignent la politique applicable à une requête. La validation de l’action vérifie ensuite qu’un appel d’outil appartient à l’ensemble d’actions autorisé. Si une action interdite est présente, elle est rejetée ; si une liste d’actions autorisées existe et que l’action demandée n’y figure pas, elle est également rejetée.\n\n Le projet décrit aussi la validation de la chaîne de délégation. Elle devient importante lorsqu’un agent en appelle un autre ou lorsqu’un workflow transmet une autorité à travers plusieurs services. Un composant en aval ne doit pas recevoir silencieusement une autorité plus large que celle accordée en amont. Dans une chaîne correctement conçue, chaque délégation conserve ou réduit le périmètre, et la décision finale reste attribuable à l’autorité d’origine.\n\n L’ordre des opérations est important. Le filtrage par objectif sélectionne la politique applicable. La validation de l’action vérifie ce que l’outil est invité à faire. L’application au niveau objet contrôle ensuite les données qui peuvent être renvoyées ou modifiées. Chaque étape est présentée comme étant en échec fermé et testable indépendamment.\n\n AWS documente également une couche facultative d’alignement sémantique utilisant un juge LLM. C’est la partie la plus délicate de la conception. Des règles déterministes peuvent vérifier une table, un champ, un filtre de lignes, une action ou un point d’accès. Elles ne peuvent pas toujours déterminer si une suite de requêtes valides individuellement reste conforme à l’objectif déclaré. Un juge peut examiner la description de l’objectif, l’appel d’outil courant et une fenêtre d’historique récente, puis autoriser, bloquer ou demander une escalade selon des seuils de confiance.\n\n Le projet place ce juge après l’application déterministe, et non avant. L’ordre est cohérent : un modèle ne devrait pas pouvoir convaincre un second modèle de révéler un champ déjà interdit par une politique structurelle. Le juge est facultatif et désactivé par défaut, avec un prompt contrôlé par l’administrateur que l’agent ne peut pas modifier.\n\n Les organisations devraient considérer le juge comme un signal supplémentaire, et non comme un substitut au contrôle d’accès déterministe. Sa sortie est probabiliste, sa configuration doit être évaluée et les cas ambigus doivent disposer d’un chemin d’examen explicite. La frontière la plus solide de cette version reste la règle classique : ne pas renvoyer les données interdites par la politique.\n\n ## Ce que cela change pour les équipes MCP et outils d’agents\n\n L’effet pratique est le plus important pour les équipes qui ajoutent des outils plus vite qu’elles ne conçoivent leur modèle d’autorisation.\n\n MCP facilite relativement l’exposition de capacités à un modèle. La question de sécurité n’est pas seulement de savoir si le serveur exige une authentification. Il faut aussi déterminer si chaque outil possède un contrat de données étroit et si le serveur filtre le résultat avant que le client ou le modèle ne le voie. Un outil qui renvoie le résultat sans restriction d’une base de données reste large, même si la connexion MCP utilise un jeton de courte durée.\n\n Le même problème existe en dehors de MCP. Un outil OpenAI Agents, un récupérateur LangChain, un groupe d’actions Bedrock Agent, un point d’accès d’appel de fonction ou un wrapper Python personnalisé peuvent tous devenir une frontière de divulgation accidentelle. L’approche de TOLAP se situe volontairement sous le framework de modèle : placer la politique autour de la fonction qui parle à la source, puis conserver le même modèle d’application lorsque la couche d’orchestration change.\n\n Cette séparation apporte un bénéfice opérationnel. Les équipes peuvent tester le comportement de sécurité sans tester la capacité du modèle à suivre des instructions. Un test de politique peut vérifier qu’une colonne interdite est absente, qu’un filtre de lignes est appliqué, qu’une limite de résultats est respectée et qu’une action interdite échoue. Ce sont des tests ordinaires de logiciel et de sécurité. Le modèle peut ensuite être évalué sur son utilité à partir du jeu de résultats réduit.\n\n Il existe un compromis. Un wrapper placé à la frontière de l’outil voit ce que celui-ci renvoie, mais peut ne pas comprendre toutes les significations métier des données. Une politique peut masquer un champ et filtrer une région. Il peut être plus difficile d’exprimer que « ces cinq requêtes autorisées créent ensemble une inférence interdite » sans conserver un historique ou ajouter une étape de revue sémantique. Les couches déterministe et sémantique doivent donc être comprises comme complémentaires, et non comme interchangeables.\n\n ## Les frontières qui restent du ressort de l’application\n\n TOLAP n’élimine pas la nécessité des contrôles de sécurité classiques.\n\n L’identité reste importante. La politique a besoin d’un sujet, d’un groupe, d’un rôle, d’un compte de service ou d’un principal délégué fiable. Si chaque requête arrive avec la même identité de service surpuissante, les règles au niveau objet peuvent disposer de trop peu de contexte pour prendre une décision pertinente.\n\n La conception des identifiants reste importante. Un outil enveloppé ne devrait pas posséder un identifiant permettant de contourner le wrapper et d’accéder directement à la source. Les identifiants de courte durée, les rôles limités, les restrictions réseau, la rotation des secrets et les identités distinctes pour le développement et la production restent des contrôles de base.\n\n Le système source reste important. La sécurité au niveau des lignes de la base de données, l’autorisation des API, les politiques de stockage et les règles métier de l’application doivent continuer à faire respecter leurs propres limites. TOLAP peut réduire ce qu’un agent reçoit, mais ne devrait pas être l’unique protection d’une base critique ou d’une opération irréversible.\n\n La conception des approbations reste importante. Masquer des champs ne rend pas une action destructive sûre. Supprimer un enregistrement, modifier un paiement, faire tourner une clé ou déployer du code peut nécessiter une approbation humaine, une règle des quatre yeux, un aperçu de transaction ou un workflow réversible. La validation d’action de TOLAP peut rejeter les appels hors périmètre, mais une action autorisée peut tout de même être trop lourde de conséquences pour être exécutée automatiquement.\n\n L’observabilité reste importante. L’événement d’audit utile n’est pas seulement « outil appelé ». Il devrait relier l’humain ou le service ayant délégué l’autorité, l’identité de l’agent, l’objectif, l’outil, la version effective de la politique, le périmètre des données, la taille du résultat, la décision et toute approbation. Sans ce contexte, les enquêteurs savent peut-être qu’une requête a été exécutée, mais pas pourquoi elle a été autorisée.\n\n Enfin, la gouvernance reste importante. Les politiques ont besoin de propriétaires, de dates d’expiration, de déclencheurs de revue, d’un contrôle de version, d’une restauration et de tests exécutés lorsqu’un connecteur change. Un wrapper de politique peut donner une fausse impression de sécurité si personne ne vérifie que l’outil sous-jacent n’a pas gagné un nouveau paramètre ou une nouvelle route contournant la fonction d’application.\n\n ## Un plan d’évaluation raisonnable\n\n Les équipes n’ont pas besoin d’adopter toute la pile TOLAP pour tirer quelque chose de cette version. Sa conception suggère une revue pratique des outils d’agents existants.\n\n Commencez par inventorier les véritables chemins de données. Pour chaque outil d’agent, identifiez la fonction qui lit ou modifie la source, l’identifiant qu’elle utilise, les chemins d’accès alternatifs et le point où le résultat devient visible pour le modèle. Dessinez le parcours depuis la demande de l’utilisateur jusqu’à l’appel de l’outil, puis jusqu’à la réponse de la source. Si l’équipe ne peut pas nommer le point d’application, elle ne peut probablement pas démontrer la frontière.\n\n Séparez ensuite l’autorisation de capacité de l’autorisation des données. « L’agent peut utiliser la recherche client » est une déclaration de capacité. « L’agent peut voir les clients attribués à cet employé, sans date de naissance et avec l’e-mail masqué » est une politique de données. Mettez les deux sous une forme testable.\n\n Créez ensuite des tests négatifs. Vérifiez que le wrapper bloque une table interdite, retire un champ restreint, filtre les lignes hors périmètre, masque les valeurs sensibles, limite les réponses anormalement larges, rejette une action non approuvée et échoue fermé lorsque la résolution de la politique ou la signature échoue. Testez aussi l’accès direct avec l’identifiant de l’outil, en plus du parcours normal de l’agent.\n\n Testez la composition, et pas seulement les appels isolés. Un modèle peut obtenir une information sensible grâce à plusieurs requêtes apparemment inoffensives, ou transmettre une autorité d’un agent à un autre. Enregistrez et examinez les séquences, les changements de délégation et les exportations répétées. Si l’objectif métier compte, définissez les situations où une séquence doit être soumise à une revue humaine au lieu d’essayer d’encoder chaque interprétation dans un prompt.\n\n Enfin, mesurez la friction pour les développeurs. Une couche de sécurité trop difficile à intégrer sera contournée. La bonne question n’est pas de savoir si un wrapper peut exprimer toutes les politiques imaginables, mais si l’organisation peut faire du chemin sûr le chemin le plus simple pour chaque connecteur et chaque framework pris en charge.\n\n ## Pourquoi cette version mérite d’être suivie\n\n TOLAP constitue une première réponse open source à un problème que de nombreux déploiements d’agents traitent encore avec du middleware dispersé et des conventions. Sa contribution la plus utile est conceptuelle : l’accès à un outil n’est pas la même chose que l’autorisation d’accéder à chaque objet que cet outil peut atteindre.\n\n Cette distinction devient plus urgente à mesure que les agents passent de la recherche conversationnelle à des workflows qui interrogent des systèmes de production, résument des dossiers privés, appellent des API et délèguent des tâches à d’autres agents. Les plateformes d’identité existantes restent nécessaires, et les fournisseurs ajoutent des identités d’agents, de l’accès conditionnel et des contrôles de politiques. Mais une identité contrôlée à la couche extérieure ne limite pas automatiquement la forme d’un résultat à la couche intérieure.\n\n Le projet doit être évalué comme une infrastructure, et non comme un label de sécurité prêt à l’emploi. Lisez son modèle de menace. Vérifiez que chaque chemin vers une source est enveloppé. Examinez le schéma des politiques et le comportement en cas d’échec. Exécutez les exemples sur des données représentatives. Vérifiez que la licence, les dépendances, les environnements pris en charge et le modèle opérationnel conviennent à l’organisation. Considérez le juge LLM facultatif comme une aide à la revue qui nécessite sa propre validation.\n\n Le conseil immédiat pour les équipes de plateforme et de sécurité est simple : pour chaque outil d’agent qui manipule des données sensibles, définissez le résultat utile le plus réduit avant que le modèle ne le voie. Faites respecter cette définition en code, à la frontière des données, empêchez l’identifiant de la contourner et enregistrez la politique qui a motivé la décision. La version TOLAP d’AWS fournit un projet open source concret à examiner et rend cette architecture plus facile à discuter.\n\n C’est le changement matériel : la frontière de sécurité d’un agent IA n’est pas seulement l’identité qui démarre une requête. C’est aussi la fonction qui décide de ce qui peut entrer dans le contexte de l’agent.\n\n ## Sources\n\n Cette adaptation s’appuie sur les informations attribuées à l’[AWS Open Source Blog](https://aws.amazon.com/blogs/opensource/introducing-tolap-object-level-access-control-for-ai-agent-tools/), au [dépôt TOLAP d’AWS Labs](https://github.com/awslabs/tolap) et à sa [documentation d’architecture](https://github.com/awslabs/tolap/blob/main/docs/architecture.md). Le contexte mentionné dans l’article provient également des ressources publiques de Microsoft Learn, du NIST NCCoE, d’un article arXiv consacré aux architectures d’autorisation pour les agents utilisant des outils et d’une discussion publiée sur Reddit.","available_translations":[{"language":"ar","title":"إطلاق TOLAP من AWS يضع التحكم في الوصول على مستوى الكائن داخل أدوات وكلاء الذكاء الاصطناعي","html_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools?lang=ar","markdown_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.md?lang=ar","json_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_tolap_object_level_access_control_ai_agent_tools?lang=ar"},{"language":"de","title":"AWS’ TOLAP bringt objektbezogene Zugriffskontrolle in Werkzeuge für KI-Agenten","html_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools?lang=de","markdown_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.md?lang=de","json_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_tolap_object_level_access_control_ai_agent_tools?lang=de"},{"language":"en","title":"AWS’s TOLAP release puts object-level access control inside AI-agent tools","html_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools?lang=en","markdown_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.md?lang=en","json_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_tolap_object_level_access_control_ai_agent_tools?lang=en"},{"language":"es","title":"El lanzamiento de TOLAP de AWS introduce control de acceso a nivel de objeto en las herramientas de agentes de IA","html_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools?lang=es","markdown_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.md?lang=es","json_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_tolap_object_level_access_control_ai_agent_tools?lang=es"},{"language":"fr","title":"La version TOLAP d’AWS intègre le contrôle d’accès au niveau des objets dans les outils d’agents IA","html_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools?lang=fr","markdown_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.md?lang=fr","json_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_tolap_object_level_access_control_ai_agent_tools?lang=fr"},{"language":"pl","title":"Wydanie AWS TOLAP przenosi kontrolę dostępu na poziomie obiektów do narzędzi agentów AI","html_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools?lang=pl","markdown_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.md?lang=pl","json_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_tolap_object_level_access_control_ai_agent_tools?lang=pl"},{"language":"ru","title":"Релиз AWS TOLAP переносит контроль доступа к объектам внутрь инструментов ИИ-агентов","html_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools?lang=ru","markdown_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.md?lang=ru","json_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_tolap_object_level_access_control_ai_agent_tools?lang=ru"},{"language":"zh","title":"AWS 的 TOLAP 发布：把对象级访问控制放进 AI 代理工具","html_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools?lang=zh","markdown_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.md?lang=zh","json_url":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_tolap_object_level_access_control_ai_agent_tools?lang=zh"}],"_links":{"self":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.json?lang=fr","api":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_tolap_object_level_access_control_ai_agent_tools?lang=fr","html":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools?lang=fr","canonical":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools?lang=fr","markdown":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.md?lang=fr","json":"https://publicasta.com/it_today_news/aws_tolap_object_level_access_control_ai_agent_tools.json?lang=fr","channel":"https://publicasta.com/api/public/v1/channels/it_today_news","channel_articles":"https://publicasta.com/api/public/v1/channels/it_today_news/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}