La sécurité de la Spatial AI est l'ensemble des limites qui empêchent un système sensible à la localisation de traiter comme une autorisation du texte de lieu non fiable, des enregistrements privés, des outils ou des actions cartographiques. Un system prompt peut orienter la réponse. Le prompt ne peut pas décider qui peut voir un enregistrement, quel hôte un outil peut appeler ou quelle réservation peut être validée. Ces contrôles appartiennent à l'extérieur du modèle, là où l'identité, les politiques et les systèmes propriétaires des données peuvent refuser la requête.
Les sections suivantes séparent le prompt du reste de l'architecture, puis couvrent les zones de confiance, les instructions récupérées, l'autorisation avant le contexte, l'autorité des outils, les contrôles d'action, la portée réseau et la mémoire. Kaleidr Enterprise et Kaleidr Chat se placent à côté de ces contrôles du système hôte. Ces produits ne remplacent ni le fournisseur d'identité de l'hôte, ni sa politique de tenant, ni son système transactionnel.
Principes essentiels de sécurité de la Spatial AI
- Garder le prompt hors du chemin d'autorisation : Une instruction de sécurité peut orienter la réponse. Elle ne peut pas accorder l'accès à un enregistrement, à un outil ou à une destination réseau.
- Autoriser avant la récupération : Les contrôles de tenant, d'objet et de champ s'exécutent avant que les lignes privées n'entrent dans le contexte du modèle.
- Séparer l'autorité des outils : Les capacités de lecture, de carte, de brouillon et d'écriture ne partagent pas un même niveau de privilège.
- Distinguer l'accessibilité réseau de l'approbation : Une allowlist située hors du prompt décide quels hôtes un outil peut appeler.
- Donner à la mémoire sa propre barrière : Le texte récupéré ne devient pas une politique pour la session suivante.
Qu'est-ce que la sécurité de la Spatial AI ?
La sécurité de la Spatial AI est le système de contrôle autour d'un produit qui combine une carte avec du contexte privé, du routage, des recommandations et des actions. Une carte traditionnelle peut représenter de la géographie publique. Un produit spatial peut aussi lire un enregistrement fournisseur, calculer un point de collecte le long d'un itinéraire et proposer un planning. Chacune de ces étapes possède une frontière. La question de sécurité est de savoir si une entrée, un enregistrement récupéré, un résultat d'outil ou une autorisation périmée peut franchir une frontière que le produit n'a pas accordée.
L'article OWASP du 9 décembre 2025 sur le Top 10 for Agentic Applications cite, parmi les risques qui apparaissent lorsqu'un système peut agir, le détournement de l'objectif de l'agent, l'abus d'outils, l'abus d'identité et de privilèges ainsi que l'empoisonnement de la mémoire et du contexte (OWASP, 2025). Sur une carte, le même schéma devient géographique. Une description de lieu peut tenter de détourner une recommandation. Un outil de routage doté d'identifiants trop larges peut toucher des emplacements que l'appelant n'est pas autorisé à utiliser. Une mémoire persistante peut transporter une instruction de localisation malveillante vers une session ultérieure. La couverture représente ce parcours : entrées non fiables à gauche, identité jusqu'à l'exécution au centre, puis résultat cartographique à droite. Les déclarations d'impact métier de cette figure sont illustratives et ne constituent pas des résultats mesurés de Kaleidr.
L'invariant utile est étroit. Un utilisateur ne reçoit jamais les enregistrements de localisation privés d'un autre tenant. Un navigateur ne reçoit jamais un secret serveur. Un document récupéré n'accorde jamais une autorisation. Une description de lieu ne réécrit jamais la liste réseau autorisée. Le modèle peut proposer l'étape suivante. La proposition n'est pas l'autorisation.
Pourquoi un system prompt n'est-il pas une frontière de sécurité ?
Un chemin fondé uniquement sur le prompt va de l'utilisateur à une instruction de sécurité, puis au modèle de langage, puis directement à une base de données, des outils et des actions. Ce chemin traite l'obéissance comme le contrôle. Le récapitulatif d'exploits OWASP couvrant du 1er juillet au 30 septembre 2026, publié le 8 octobre 2026, indique que des instructions au niveau du prompt ne suffisent pas à établir une frontière sécurisée (OWASP, 2026). Ce récapitulatif consolide des divulgations sélectionnées. Il ne s'agit pas d'un rapport d'incident Kaleidr.

Le panneau de gauche traite le prompt de sécurité comme l'unique frontière et dirige le modèle de langage directement vers les données, les outils et les actions. Le panneau de droite insère l'identité, l'autorisation, les données approuvées, les outils contraints et la validation avant l'exécution. La portée des outils, la portée réseau, la politique de mémoire et l'observabilité accompagnent ce chemin. Le texte de prompt d'exemple de la figure est illustratif.
Un chemin imposé classe d'abord l'entrée, résout l'identité, autorise les enregistrements et les outils, puis seulement demande au modèle d'interpréter l'intention dans cette portée. Les contrôles transversaux restent hors du prompt : quels outils existent, quelles destinations ces outils peuvent atteindre, ce que la mémoire peut stocker et ce que la trace doit enregistrer. Une réponse manipulée peut toujours être fausse. Cette mauvaise réponse ne devrait pas pouvoir élargir ses propres privilèges.
Où placer les frontières de confiance ?
Dessinez les zones avant d'énumérer les attaques. Une séparation pratique comporte sept frontières : entrée non fiable, identité et politique, systèmes métier, services spatiaux, couche AI, couche d'action et éléments de preuve. Le texte utilisateur, le texte des lieux, les documents et les flux partenaires entrent comme données non fiables. L'identité et la politique déterminent qui appelle, quel tenant s'applique et quels droits de rôle et d'objet existent. Les stocks, réservations, CRM et installations privées restent dans les systèmes métier qui les possèdent. Le routage, le géocodage, la géométrie et la recherche sont des services spatiaux avec leurs propres entrées et sorties.

Le diagramme place une frontière de confiance entre chaque zone, de l'entrée non fiable jusqu'aux éléments de preuve. Les systèmes métier contiennent les stocks, les réservations, le CRM et les installations privées. Les services spatiaux contiennent le routage, le géocodage, la géométrie et la recherche. Les noms de zones et les libellés de systèmes d'exemple sont une esquisse d'architecture, pas un inventaire de produits Kaleidr.
La couche AI peut interpréter l'intention, choisir parmi les outils approuvés et expliquer un résultat. La couche d'action est séparée : une mise à jour de carte, un brouillon, une écriture et une transaction ne sont pas la même opération. Les éléments de preuve enregistrent la trace, le contrôle de politique, le refus et le résultat. Authentification, autorisation, isolation des données et audit s'appliquent à chaque frontière de la figure. Sauter une zone et demander au modèle de « faire attention » réduit ces contrôles à une seule instruction.
Pourquoi un texte de lieu récupéré peut-il transporter une attaque ?
Une prompt injection indirecte arrive par un contenu que l'utilisateur n'a pas saisi. Une description de lieu, un document téléversé, un flux partenaire ou un résultat d'outil peut contenir une instruction demandant une nouvelle autorisation, un nouvel outil ou une autre destination. Le texte peut aussi contenir un fait utile, comme une adresse ou des horaires. L'hôte doit extraire le fait et ignorer l'instruction. Le texte récupéré est une donnée. Le texte récupéré n'est pas une politique.

La colonne de gauche montre quatre sources non fiables, chacune transportant une instruction d'exemple. Le chemin bloqué refuse les demandes d'accorder une autorisation, d'ajouter un outil et de changer de destination. Le chemin autorisé extrait les faits, les valide et reste sur des outils approuvés. Les phrases et l'hôte d'exemple sont illustratifs et ne représentent pas un incident Kaleidr enregistré.
Traitez le contenu public d'un lieu avec la même suspicion qu'un document partenaire. Un fait géographique peut être vrai tout en se trouvant à côté d'une instruction hostile. La sortie d'un outil nécessite le même traitement lorsqu'elle revient dans le système. Un résultat qui affirme que la tâche est terminée est une donnée pour le contrôle suivant. Ce résultat ne peut pas ajouter une destination ni contourner une approbation. Les contrôles structurels assurent le refus : une allowlist d'outils, des contrôles de schéma et une autorisation qui ne lit jamais la phrase récupérée comme une permission.
Pourquoi autoriser les enregistrements avant que le modèle ne les voie ?
Les enregistrements de localisation privés doivent passer des contrôles de tenant, de rôle, d'objet et de champ avant qu'une ligne n'entre dans le contexte du modèle. Le guide Kaleidr sur les données de localisation privées recommande d'authentifier l'utilisateur, de résoudre le tenant et les objets autorisés, de récupérer le minimum d'enregistrements et de champs, et de maintenir le modèle de langage hors du chemin d'accès (Kaleidr, 2026). Le même guide déconseille de récupérer un jeu de données privé complet puis de demander au modèle quelles lignes sont autorisées. L'autorisation est une contrainte de requête. L'autorisation n'est pas un paragraphe dans le prompt.

Le chemin supérieur autorise l'utilisateur, le tenant, le rôle, les objets et les champs avant qu'un ensemble minimal d'enregistrements n'atteigne le modèle. Le chemin inférieur envoie une base privée complète au modèle et lui demande de décider de l'accès, ce que la figure marque comme dangereux. Les libellés d'identité et la carte d'exemple sont illustratifs. Les contrôles de production doivent utiliser le vrai système d'identité et la vraie politique de champs de l'hôte.
Les identifiants de plateforme constituent un contrôle différent de ce chemin utilisateur. Le guide d'authentification Map API de Kaleidr sépare un identifiant publiable pour navigateur d'un identifiant serveur qui reste hors du client, et précise que les scopes de capacité API ne sont pas une autorisation utilisateur ou ligne de l'application (Kaleidr, 2026). Un identifiant d'organisation valide ne signifie pas que le client A peut lire les magasins du client B. Le backend de l'hôte continue de résoudre l'utilisateur final, le tenant, l'objet et le champ. Ne placez pas de secrets serveur dans les prompts, les traces ou le code du navigateur.
Pourquoi les outils ne doivent-ils pas partager la même autorité ?
Donnez au travail en cours le plus petit ensemble d'outils capable de le terminer et ne donnez pas à chaque outil le même privilège. Un outil de lecture peut renvoyer un lieu, une disponibilité ou un itinéraire. Un outil cartographique peut afficher des lieux, dessiner un itinéraire ou sélectionner un lieu sans écrire dans l'état métier. Un outil de brouillon peut préparer une réservation ou une proposition de dispatch et s'arrêter avant le commit. Un outil d'écriture confirme la réservation, envoie le dispatch ou modifie l'enregistrement. Validation, autorisation, confirmation et audit doivent devenir plus stricts à mesure que l'action devient plus difficile à annuler.

Le niveau lecture renvoie des informations de lieu, de disponibilité et d'itinéraire. Le niveau carte affiche les lieux, dessine un itinéraire et sélectionne un lieu. Le niveau brouillon prépare une réservation ou une proposition de dispatch, et le niveau écriture confirme une réservation, un dispatch ou une modification d'enregistrement. Les noms d'outils sont illustratifs. Un catalogue de production ne doit exposer que les opérations réellement approuvées par l'hôte.
L'entrée OWASP sur Excessive Agency, LLM06:2025, décrit des actions dommageables provoquées par des sorties de modèle inattendues, ambiguës ou manipulées et cite comme causes fréquentes une fonctionnalité excessive, des permissions excessives et une autonomie excessive (OWASP, 2025). Des outils étroits réduisent la fonctionnalité. Des identifiants séparés réduisent les permissions. Une étape de confirmation réduit l'autonomie pour les écritures. Les actions cartographiques doivent rester sémantiques. Le guide Kaleidr sur les assistants map-aware recommande un petit vocabulaire comme show places ou fit places, passant par validation et un adaptateur de renderer, plutôt que du code renderer arbitraire (Kaleidr, 2026). Une mise à jour de carte n'est pas une réservation, et un brouillon de réservation n'est pas une réservation confirmée.
Pourquoi une proposition doit-elle passer des contrôles avant son exécution ?
Un modèle peut proposer un appel d'outil avec des arguments. Une proposition n'est pas une autorisation et une autorisation n'est pas une exécution. Le guide Kaleidr sur l'observabilité trace la même séparation : enregistrer le nom de l'outil, le résultat du schéma, la décision d'autorisation, le contrôle de politique et l'état d'exécution, et traiter les sorties de rejet comme une partie de la trace (Kaleidr, 2026). Le résultat côté hôte, comme une réservation terminée, reste dans le système propriétaire de la transaction.

Le pipeline commence par une proposition de modèle non fiable et vérifie le schéma, l'identité, la politique et la fraîcheur avant toute exécution. Les actions à fort impact peuvent nécessiter une confirmation. Chaque barrière possède une sortie de rejet, y compris outil invalide, échec de schéma, autorisation manquante, blocage de politique, données périmées ou confirmation absente. Les arguments d'outil d'exemple de la figure sont illustratifs.
Revalidez immédiatement avant le commit. Disponibilité, prix, affectation et autorisation peuvent changer entre le brouillon et l'écriture. L'écran de confirmation doit montrer l'action exacte et la cible exacte, pas un résumé vague. Après l'exécution, renvoyez un résultat que la trace peut stocker sans copier de secrets ni de coordonnées inutiles. Un contrôle échoué doit arrêter l'action et laisser l'état métier précédent intact.
Pourquoi un hôte joignable n'est-il pas nécessairement autorisé ?
La portée réseau est un contrôle distinct. Un agent peut tenter d'appeler un service de routage, un service de stock, un service de réservation ou une URL arbitraire trouvée dans un texte récupéré. Seules les destinations d'une allowlist appliquée hors du prompt doivent réussir. Un outil capable de récupérer n'importe quelle URL finira par être dirigé vers un hôte que la tâche n'a jamais approuvé. Joignable signifie que le chemin réseau existe. Autorisé signifie que la politique a nommé cette destination pour cet outil.

Les chemins approuvés de la figure vont vers un hôte de routage, un hôte de stock et un hôte de réservation. Les URL arbitraires, API inconnues et autres hôtes externes sont bloqués. Le pied indique d'imposer la portée réseau en dehors du prompt. Les noms d'hôtes, noms internes et adresse d'exemple sont illustratifs, pas une allowlist Kaleidr.
Appliquez la même règle aux résultats d'outils qui recommandent un nouvel endpoint. La recommandation est un contenu non fiable. L'allowlist ne change pas parce qu'un document a demandé un nouveau serveur. Si une destination est nécessaire, un opérateur l'ajoute via le processus de changement qui gère la politique réseau. Le modèle ne modifie pas cette liste depuis l'intérieur d'une exécution.
Pourquoi la mémoire a-t-elle besoin de sa propre frontière ?
Le contexte persistant survit au tour qui l'a créé. Une note de lieu, une préférence ou un itinéraire antérieur peuvent être utiles lors de la session suivante. Une phrase cachée dans du texte récupéré peut aussi tenter de devenir une politique permanente, par exemple une instruction d'ignorer l'autorisation. Les écritures mémoire nécessitent leur propre barrière : un écrivain autorisé, un contrôle de tenant, une source fiable et un enregistrement indiquant qui a stocké l'élément et quand. La politique de sécurité actuelle reste hors de la mémoire. Une mémoire approuvée peut informer la réponse suivante. Elle ne peut pas remplacer le contrôle d'autorisation actuel.

La session un montre du texte récupéré tentant une écriture mémoire et échouant au contrôle de source. L'instruction bloquée reste hors de la mémoire persistante. La session deux combine la politique de sécurité actuelle avec une mémoire approuvée et limitée au tenant. L'instruction et l'adresse d'exemple sont illustratives.
L'article OWASP du 13 mai 2026 traite la mémoire comme une surface d'attaque et décrit comment un travail d'agent ordinaire peut devenir une prompt injection persistante (OWASP, 2026). Les contrôles pratiques sont un ensemble limité d'écrivains, l'isolation tenant, la provenance, la revue et un moyen de supprimer une entrée. Ne laissez pas chaque résultat d'outil s'ajouter lui-même au contexte à long terme. Testez ce chemin avec un enregistrement hostile, un résultat d'outil hostile et une session ultérieure qui doit toujours appliquer la politique d'origine.
Où placer la sécurité de la Spatial AI à côté de Kaleidr ?
Conservez côté hôte l'identité utilisateur, l'autorisation tenant, les données métier privées, la politique réseau, les transactions et la réponse aux incidents. Kaleidr Enterprise est une infrastructure de location intelligence avec inference APIs, systèmes de ranking et analytics pour produits spatiaux (Kaleidr, 2026). Kaleidr Chat est la couche conversationnelle sur une carte déjà rendue par l'hôte. Les API cartographiques et spatiales, les actions cartographiques sémantiques et le contexte analytics sont des capacités de plateforme. Un identifiant publiable navigateur et un identifiant serveur, lorsque l'intégration les utilise, suivent toujours la séparation d'authentification décrite plus haut. Le scope de plateforme ne remplace pas l'autorisation utilisateur final de l'hôte.

La colonne de gauche liste les contrôles appartenant à l'hôte, notamment identité, autorisation tenant, données privées, politique réseau, transactions et réponse aux incidents. La colonne centrale liste Kaleidr Enterprise, Chat, les API cartographiques et spatiales, les actions cartographiques sémantiques et le contexte analytics. Le pied précise que le scope de plateforme ne remplace pas l'autorisation utilisateur final de l'hôte. Le diagramme est une esquisse d'architecture, pas une affirmation selon laquelle Kaleidr opère le fournisseur d'identité ou le système de réservation de l'hôte.
Un rapport NIST du 18 mai 2026 résume les réponses à une demande d'informations sur les considérations de sécurité pour les agents AI (NIST, 2026). Ce rapport est une synthèse des commentaires, citée comme NIST Trustworthy and Responsible AI 800-5. Ce n'est ni une base de contrôles ni une certification Kaleidr. Utilisez-le comme rappel que la sécurité des agents est encore en cours de définition publique et implémentez les frontières dans le produit effectivement livré.
Construisez le chemin d'arrêt avant d'accorder une agence significative. L'hôte doit pouvoir arrêter une exécution, révoquer l'identifiant qu'elle utilise, couper l'egress qu'elle était autorisée à utiliser et annuler une écriture non encore validée. Conservez la trace : qui a appelé, quel tenant s'appliquait, quelle politique s'est exécutée, quels outils ont été proposés, quelles destinations ont été autorisées ou refusées et quel a été le résultat. Laissez les secrets et coordonnées précises inutiles hors de cet enregistrement. Testez l'injection indirecte, les lectures inter-tenant, les hôtes hors scope, l'abus d'outils et l'empoisonnement de mémoire comme des cas proches de la production. Réussir un test de prompt ne prouve pas ces cas.
Explorez Kaleidr Enterprise pour la stack de location intelligence et lisez Map API Authentication pour la séparation documentée entre un identifiant navigateur et un identifiant serveur. Gardez l'autorisation de l'hôte, la politique réseau et les contrôles transactionnels hors du modèle, même lorsque l'action cartographique semble correcte.
Remarque : Kaleidr utilise des outils assistés par AI pour la création d'images, l'amélioration de contenu et la recherche dans ses workflows créatifs et de développement.
FAQ
La prompt injection est-elle le seul risque de sécurité de la Spatial AI ?
Non. Les instructions cachées comptent, tout comme l'identité, l'autorisation des enregistrements privés, la portée des outils, les destinations réseau, la mémoire, les secrets et la capacité d'arrêter une exécution. Un prompt sûr ne couvre pas cette liste.
Un system prompt bloque-t-il une instruction cachée dans une description de lieu ?
Non. Le texte de lieu récupéré, les documents, les flux partenaires et les résultats d'outils peuvent transporter des instructions. Extrayez les faits et imposez permissions, outils et destinations en dehors du modèle.
Kaleidr remplace-t-il l'autorisation de l'hôte ?
Non. Les identifiants de plateforme et les capacités spatiales ne sont pas une autorisation utilisateur final ou tenant. L'hôte décide toujours quelle personne, quel tenant, quel objet et quel champ une requête peut utiliser.
Une URL joignable doit-elle être considérée comme approuvée ?
Non. Un outil ne doit appeler que les destinations permises par une allowlist, et cette allowlist doit être appliquée hors du prompt. Un document qui nomme un nouvel hôte n'ajoute pas cet hôte.
References
- OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications. John Sotiropoulos, December 9, 2025. Names agent goal hijack, tool misuse, identity and privilege abuse, and memory and context poisoning among agentic risks. Accessed October 9, 2026. https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
- OWASP GenAI Security Project. GenAI and Agentic AI Exploit Roundup Q3 2026. October 8, 2026. Coverage period July 1, 2026 through September 30, 2026. States that prompt-level instructions alone do not establish a secure boundary. Accessed October 9, 2026. https://genai.owasp.org/2026/10/08/genai-and-agentic-ai-exploit-roundup-q3-2026/
- Kaleidr. Private Location Data for AI Map Workflows. Authorize the user and retrieve the minimum records before the language model sees private location data. https://kaleidr.com/blog/private-location-data-for-ai-map-workflows
- Kaleidr. Map API Authentication. Separates a publishable browser credential from a server credential, and states that capability scopes are not application user or row authorization. https://kaleidr.com/blog/map-api-authentication
- OWASP GenAI Security Project. LLM06:2025 Excessive Agency. Describes damaging actions that follow unexpected, ambiguous, or manipulated model output, including excessive functionality, permissions, and autonomy. Accessed October 9, 2026. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
- Kaleidr. Map-Aware AI Assistant: How to Build One. Recommends a small semantic map-action vocabulary validated before the renderer runs. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant
- Kaleidr. Spatial AI Observability. Separates a model proposal from authorization and execution, and keeps the host outcome in the system that owns the transaction. https://kaleidr.com/blog/spatial-ai-observability
- OWASP GenAI Security Project. Memory Is a Feature. It Is Also an Attack Surface. May 13, 2026. Treats persistent context as an attack surface. Accessed October 9, 2026. https://genai.owasp.org/2026/05/13/memory-is-a-feature-it-is-also-an-attack-surface/
- Kaleidr. Location Intelligence APIs and Map SDK. Describes location-intelligence infrastructure with inference APIs, ranking systems, and analytics for spatial products. Accessed October 9, 2026. https://kaleidr.com/enterprise
- National Institute of Standards and Technology. Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI Agents. NIST Trustworthy and Responsible AI 800-5, May 18, 2026. An overview of responses, not a control baseline. Accessed October 9, 2026. https://www.nist.gov/publications/summary-analysis-responses-request-information-regarding-security-considerations-ai
@misc{owasp_agentic_top10_2025,
title = {OWASP Top 10 for Agentic Applications},
author = {{OWASP GenAI Security Project}},
year = {2025},
url = {https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/}
}
@misc{owasp_q3_2026_roundup,
title = {GenAI and Agentic AI Exploit Roundup Q3 2026},
author = {{OWASP GenAI Security Project}},
year = {2026},
url = {https://genai.owasp.org/2026/10/08/genai-and-agentic-ai-exploit-roundup-q3-2026/}
}
@misc{kaleidr_private_location_2026,
title = {Private Location Data for AI Map Workflows},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/private-location-data-for-ai-map-workflows}
}
@misc{kaleidr_map_api_auth_2026,
title = {Map API Authentication},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/map-api-authentication}
}
@misc{owasp_llm06_2025,
title = {LLM06:2025 Excessive Agency},
author = {{OWASP GenAI Security Project}},
year = {2025},
url = {https://genai.owasp.org/llmrisk/llm062025-excessive-agency/}
}
@misc{kaleidr_map_aware_2026,
title = {Map-Aware AI Assistant: How to Build One},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant}
}
@misc{kaleidr_observability_2026,
title = {Spatial AI Observability},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/spatial-ai-observability}
}
@misc{owasp_memory_2026,
title = {Memory Is a Feature. It Is Also an Attack Surface},
author = {{OWASP GenAI Security Project}},
year = {2026},
url = {https://genai.owasp.org/2026/05/13/memory-is-a-feature-it-is-also-an-attack-surface/}
}
@misc{kaleidr_enterprise_2026,
title = {Location Intelligence APIs and Map SDK},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/enterprise}
}
@misc{nist_ai_800_5_2026,
title = {Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI Agents},
author = {{National Institute of Standards and Technology}},
year = {2026},
url = {https://www.nist.gov/publications/summary-analysis-responses-request-information-regarding-security-considerations-ai}
}