Teradata AI Security ajoute des contrôles de confidentialité à mesure que les agents accèdent aux systèmes

Teradata a annoncé le 20 octobre de nouvelles mesures de sécurité IA visant l’exposition de données sensibles, alors que des agents autonomes accèdent aux systèmes d’entreprise. La mise à jour de Teradata AI Security associe des protections de confidentialité à des capacités de sécurité et de reprise. Son enjeu central consiste à préserver des relations de données utiles tout en limitant ce que les systèmes automatisés peuvent identifier et faire.

Les acheteurs d’entreprise se retrouvent ainsi entre des exigences concurrentes. Les agents ont besoin de contexte pour accomplir un travail utile, mais un accès plus large accroît les conséquences des erreurs. La protection des informations sous-jacentes aide, sans toutefois déterminer qui a autorisé une action ni si celle-ci doit être exécutée.

Snowflake positionne déjà l’accès gouverné aux données comme un élément de sa plateforme d’agents. Teradata doit donc répondre à une question d’achat concrète : dans quelle mesure les clients peuvent-ils déployer ces protections dans leurs environnements existants ? Pour les équipes de sécurité, cette annonce offre l’occasion de réduire l’exposition tout en examinant les autorisations entourant des logiciels toujours plus capables.

Teradata AI Security relie confidentialité et reprise opérationnelle

L’annonce de Teradata couvre la protection des identités, le chiffrement, les sauvegardes immuables et la disponibilité des bases de données. Les sauvegardes immuables sont des copies de reprise protégées contre la modification ou la suppression. L’entreprise présente ces capacités comme des exigences complémentaires pour assurer le fonctionnement de l’IA d’entreprise.

Par l’intermédiaire d’Anonomatic, Teradata propose la Poly-Anonymization, qui remplace les informations personnellement identifiables, ou PII, par des identifiants stables tout en séparant l’identité sous-jacente. L’entreprise affirme que cela préserve les relations nécessaires à l’analyse. Son chiffrement préservant le format protège les valeurs tout en conservant les structures attendues par les applications en aval.

Les capacités de protection des données comprennent également une protection des transports post-quantique, conçue pour faire face aux menaces que les futurs ordinateurs quantiques font peser sur la cryptographie conventionnelle. La disponibilité varie selon la capacité et le déploiement. Les acheteurs devraient distinguer les fonctionnalités cloud actuellement disponibles des capacités prévues pour d’autres environnements.

La valeur pratique de l’annonce dépend des protections que les clients peuvent appliquer à leurs charges de travail réelles.

Prenons un flux d’analyse client à titre d’illustration. Un agent peut devoir relier les achats, les interactions avec le support et les historiques de compte afin d’identifier des problèmes de service récurrents. Il pourrait accomplir cette tâche sans recevoir les noms des clients.

Cette distinction offre aux équipes chargées de la confidentialité une décision plus précise que l’approbation ou le rejet d’un jeu de données entier. Elles peuvent demander quelles relations la tâche exige, quels champs identifiants elle exige et où ces exigences divergent.

La même distinction s’applique à la reprise. Une réponse utile requiert des informations disponibles, mais une base de données récupérable n’établit pas automatiquement un processus métier récupérable. Une organisation doit aussi comprendre quelles actions ont eu lieu avant une interruption.

Imaginons un agent préparant une recommandation de service lorsque sa connexion aux données échoue. Restaurer les enregistrements sous-jacents faciliterait la reprise. Déterminer si l’agent a déjà soumis cette recommandation exige un enregistrement distinct de ses actions.

Ces exemples décrivent des scénarios d’évaluation, plutôt que des résultats documentés chez des clients de Teradata. Ils montrent pourquoi la confidentialité et la résilience doivent faire partie de la discussion d’achat, tout en préservant des critères d’acceptation distincts pour chaque capacité.

Un test de confidentialité demande si l’agent a reçu des informations identifiantes inutiles. Un test de reprise demande si les opérations peuvent reprendre à partir d’un état fiable. Réussir l’un de ces tests ne dit guère de chose sur l’autre, sauf si l’organisation examine l’ensemble du flux de travail.

C’est l’importance opérationnelle du regroupement de ces capacités. Les clients ont une raison d’examiner les dépendances entre des équipes qui évaluent autrement séparément la confidentialité, le comportement des applications et la reprise.

Toutefois, réunir la discussion sur l’approvisionnement ne doit pas faire disparaître les éléments de preuve. Chaque protection doit avoir un périmètre clair, un responsable identifié et un moyen d’établir son efficacité.

Les équipes de sécurité héritent de décisions que les créateurs d’agents ne peuvent prendre seuls

La pression immédiate pèse sur les équipes d’entreprise qui approuvent l’accès à des informations sensibles. Les développeurs d’agents peuvent définir une tâche, mais ils ne peuvent pas décider de manière indépendante de chaque utilisation acceptable des données sous-jacentes.

Un développeur peut raisonnablement demander suffisamment d’informations pour améliorer la réponse d’un agent. Un responsable de la confidentialité doit examiner si l’organisation a une finalité légitime pour exposer ces informations. Une équipe des opérations doit considérer les effets d’une défaillance.

Ces responsabilités se croisent lors du déploiement. Une démonstration peut réussir avec des entrées soigneusement sélectionnées et des autorisations étendues. La production introduit des utilisateurs changeants, des demandes inhabituelles et des processus métier dont les conséquences dépassent la fenêtre de réponse.

L’accès des agents transforme une intégration technique en décision sur l’autorité déléguée.

L’autorité déléguée désigne l’autorisation d’agir au nom de quelqu’un d’autre. Pour un agent d’entreprise, cela soulève une question directe : quelle autorité accompagne chaque demande ?

Le NIST a mis en avant cette question dans ses travaux de février 2026 sur l’identité des agents. Son document conceptuel sollicitait des contributions sur l’identification, l’autorisation, l’audit et la responsabilité des agents logiciels. Ces travaux fournissent un contexte pour évaluer les affirmations des fournisseurs, plutôt que de certifier un produit particulier.

L’implication pour les acheteurs est simple. Reconnaître un agent comme une application approuvée n’explique pas chaque action que cette application devrait effectuer. L’approbation doit relier l’acteur, la tâche et les informations concernées.

Un agent de support de compte, à titre d’illustration, rend cette distinction concrète. L’accès aux tendances transactionnelles peut aider au dépannage. L’accès aux dossiers d’identité peut devenir approprié lors d’une étape de vérification approuvée séparément.

Si les deux opérations utilisent les mêmes identifiants étendus, cette séparation devient plus difficile à appliquer. Le système peut techniquement autoriser la récupération d’identité même lorsque la tâche en cours ne l’exige pas.

Inversement, les restrictions peuvent devenir si grossières que les employés ne peuvent pas accomplir un travail légitime. Ils subissent alors une pression pour demander des exceptions ou déplacer les informations vers un flux de travail moins contrôlé.

Cela crée un compromis organisationnel. Les équipes de sécurité ont besoin de restrictions qui reflètent les tâches réelles, tandis que les équipes applicatives ont besoin d’un comportement prévisible lorsque ces restrictions s’appliquent.

Une demande refusée doit donc être compréhensible. L’employé doit savoir si la limitation reflète une autorisation manquante, des données indisponibles ou une opération non prise en charge. Sinon, une limite de sécurité peut ressembler à un défaut du produit.

L’effet s’étend aux travailleurs du savoir qui utilisent l’IA dans les documents et les dossiers métier. Une base de connaissances personnelle et un référentiel d’entreprise partagé impliquent des attentes d’accès différentes. Connecter l’un ou l’autre à l’automatisation exige de préciser quelles informations deviennent accessibles.

L’annonce de Teradata rapproche ces décisions de la discussion sur la plateforme de données. Les clients doivent toujours obtenir l’accord des équipes chargées de la confidentialité, de la sécurité et des activités métier avant d’élargir ce que les agents peuvent atteindre.

Préserver les relations de données crée un compromis de confidentialité

Le compromis central concerne les informations dont un agent a besoin pour rester utile. Supprimer l’identité peut réduire l’exposition, tandis que préserver les relations permet à l’analyse de se poursuivre. Ces relations peuvent également rester sensibles.

Supposons qu’un agent de commerce de détail, à titre d’illustration, étudie les retours répétés dans différents magasins et historiques d’achat. Des identifiants stables lui permettraient de reconnaître une activité récurrente sans afficher le nom d’un client.

Cette conception limite l’exposition directe de l’identité. Elle ne rend pas chaque schéma résultant approprié pour chaque employé, application ou finalité. Un historique comportemental détaillé peut avoir une signification sensible même sans identifiant évident.

Les relations utiles et la divulgation acceptable exigent des jugements distincts.

C’est pourquoi les affirmations en matière de confidentialité méritent d’être évaluées au regard de la charge de travail visée. Une entreprise devrait examiner à la fois les champs qu’un agent reçoit et les inférences que ses requêtes autorisées permettent.

La question pertinente va au-delà de la disparition des noms. Elle comprend la capacité de l’agent à assembler un profil inutilement détaillé, la possibilité que les sorties révèlent des schémas sensibles, et les personnes qui reçoivent ces sorties.

Il s’agit d’implications analytiques de l’architecture proposée, plutôt que de preuves d’un défaut dans l’implémentation de Teradata. Elles comptent, car une protection efficace peut encore laisser des décisions hors de son périmètre prévu.

Par exemple, séparer l’identité de l’analyse établit une limite autour de l’identification directe. Une organisation doit alors décider à quel moment franchir cette limite sert une finalité métier légitime.

Une enquête sur la fraude peut justifier le rétablissement de l’identité après un examen approuvé. Une analyse de tendances de routine ne le peut pas nécessairement. Les mêmes enregistrements sous-jacents peuvent étayer les deux tâches, mais l’autorisation devrait refléter leurs finalités différentes.

Le flux de travail doit également gérer les réussites partielles. Un agent peut résumer correctement un schéma tout en ne reconnaissant pas qu’une étape ultérieure nécessite une autorisation supplémentaire.

Un système qui s’arrête à ce stade préserve la limite. Un système qui substitue silencieusement des identifiants plus étendus modifie la portée de l’approbation initiale.

Cette distinction aide à expliquer pourquoi la protection de la confidentialité ne peut pas résider entièrement dans une instruction demandant au modèle de se comporter correctement. L’application environnante doit rendre les informations et les actions non autorisées indisponibles lorsque l’autorisation est absente.

Elle explique également pourquoi la préservation de l’utilité analytique mérite ses propres éléments de preuve. Un contrôle de confidentialité peut protéger l’identité tout en modifiant la qualité d’une tâche particulière. Les acheteurs ont besoin d’évaluations représentatives des deux résultats.

Ces évaluations devraient refléter les questions que les employés posent réellement. Une démonstration générique ne peut pas établir si un jeu de données protégé soutient une enquête, une prévision ou un processus de service client spécifique.

L’objectif est un accord explicite sur les capacités acceptables. Un agent devrait recevoir suffisamment de contexte pour accomplir sa tâche approuvée, avec un processus clair pour demander tout élément dépassant ce périmètre.

Cet accord donne aux acheteurs un moyen d’évaluer l’approche de Teradata sans supposer que confidentialité et utilité sont toujours en conflit. Certaines tâches nécessitent moins d’informations identifiantes que les flux de travail existants n’en exposent habituellement.

L’opportunité consiste à reconnaître ces tâches et à modifier leur accès par défaut. Le défi restant est de préserver cette discipline à mesure que les responsabilités des agents s’élargissent.

Les concurrents font de l’accès gouverné une référence d’achat

Teradata entre dans une discussion concurrentielle établie sur la protection des données d’entreprise utilisées par l’IA. Son annonce offre aux clients existants des capacités supplémentaires à examiner dans le cadre de leurs relations actuelles avec la plateforme.

Dans l’analyse de la confidentialité en entreprise de TechTarget, Donald Farmer, fondateur de TreeHive Strategy, a qualifié ces ajouts d’améliorations opérationnelles significatives. Il a également estimé qu’ils alignaient largement Teradata sur les plateformes modernes de données cloud.

Kevin Petrie, analyste chez BARC, a lui aussi salué leur alignement sur les priorités des entreprises, tout en relevant l’existence de capacités comparables ailleurs. Ces évaluations invitent à une lecture mesurée : des améliorations utiles pour les clients n’établissent pas automatiquement un avantage concurrentiel.

Les acheteurs devraient comparer les comportements effectivement imposés dans le cadre de tâches équivalentes, plutôt que les noms des fonctionnalités.

La documentation de Snowflake décrit Cortex Agents comme opérant dans son environnement gouverné. L’accès aux données dépend des privilèges de la plateforme et du contexte d’exécution de chaque outil configuré. La documentation avertit également que l’exactitude des réponses et les citations ne sont pas garanties.

Cela fournit un point de comparaison utile sans établir d’équivalence entre les plateformes. Un vocabulaire commun de gouvernance ne signifie pas une couverture de déploiement, des contrôles ou des responsabilités opérationnelles identiques.

Une entreprise comparant des fournisseurs devrait commencer par la même demande métier. L’agent devrait recevoir des informations sources, des autorisations utilisateur et des actions permises équivalentes. Dans le cas contraire, les différences apparentes peuvent refléter la configuration.

Par exemple, un agent ayant accès à des dossiers sans restriction peut sembler plus capable qu’un agent soumis à des autorisations limitées. Ce résultat mesure autant les accès accordés que les capacités de l’agent.

La comparaison devrait également inclure ce qui se passe lorsque les accès changent. Un employé transféré dans un autre service ne devrait pas conserver un accès sensible simplement parce qu’une conversation antérieure est encore ouverte.

De même, l’accès à une interface d’agent ne devrait pas impliquer l’autorisation d’utiliser chaque outil connecté. Un workflow peut faire intervenir plusieurs systèmes, avec des propriétaires et des règles différents.

L’environnement existant de l’acheteur rend ces distinctions commercialement pertinentes. Une capacité intégrée aux processus actuels d’identité et d’exploitation peut être plus facile à appliquer de manière cohérente qu’une fonctionnalité isolée.

Toutefois, la familiarité ne doit pas remplacer la vérification. Même les clients existants ont besoin de preuves que les contrôles nouvellement introduits se comportent comme prévu dans leurs conditions de déploiement.

Un écart fonctionnel ne devrait pas non plus déterminer automatiquement l’ensemble de la décision de plateforme. Les clients évaluent l’emplacement des données, les dépendances applicatives, l’expertise des équipes et les exigences de reprise, en parallèle des capacités des agents.

La pression concurrentielle est donc précise. Teradata doit montrer comment ses protections soutiennent un travail gouverné dans les environnements où ses clients opèrent déjà.

Pour les fournisseurs concurrents, la même norme s’applique. Une affirmation de gouvernance devient convaincante lorsque les clients peuvent suivre une demande, de l’identité à l’accès aux données puis à l’action qui en résulte.

Cela oriente la discussion d’achat vers des comportements observables. La comparaison la plus solide identifie ce que chaque système autorise, ce qu’il bloque et quelles preuves subsistent ensuite.

La protection des données ne détermine pas si un agent doit agir

La confidentialité, le chiffrement et la reprise répondent à différents modes de défaillance. Aucun ne détermine à lui seul si un agent a correctement interprété une demande ou sélectionné une action appropriée.

Cette distinction devient importante lorsqu’un agent rencontre du contenu hostile. L’injection de prompt désigne des instructions intégrées dans un contenu que l’agent devrait traiter comme des données.

Les travaux du NIST sur le détournement d’agents décrivent comment un tel contenu peut rediriger un agent vers des tâches nuisibles. Ils soulignent l’importance d’une évaluation adaptative et de l’examen des résultats d’attaques propres à chaque tâche.

Protéger un enregistrement et contrôler l’utilisation de cet enregistrement par un agent constituent deux exigences de sécurité distinctes.

Un workflow de support illustratif montre la différence. Un agent lit un message client tout en préparant un résumé interne. Le message contient des instructions lui demandant de récupérer des informations de compte sans rapport.

Le chiffrement peut protéger les informations pendant leur transmission. La séparation des identités peut limiter ce que reçoit l’agent. Aucune de ces capacités n’établit à elle seule que la demande intégrée dispose d’une autorité légitime.

L’application a donc besoin d’une frontière entre les informations rencontrées au cours du travail et l’autorisation d’effectuer un travail supplémentaire. Sinon, un contenu non fiable peut influencer des décisions au-delà de son rôle légitime.

Cela ne signifie pas que l’annonce d’octobre prétend résoudre tous les problèmes de sécurité des agents. Cela signifie que les clients devraient éviter d’interpréter un portefeuille de protection des données comme une réponse complète au comportement autonome.

Teradata a décrit séparément Tera Harness comme une couche d’exécution comportant des contrôles de politique et des validations humaines au sein du workflow de l’agent. Son annonce de septembre prévoyait Tera Context Engine, Tera Harness et Agent Skills pour le quatrième trimestre 2026.

Ces déclarations de l’entreprise établissent l’orientation produit envisagée. Elles ne démontrent pas indépendamment une protection contre chaque action non autorisée ou chaque entrée hostile.

La séparation entre les annonces est importante. Les acheteurs devraient vérifier quelles capacités sont disponibles ensemble, quelles intégrations sont prises en charge et comment le workflow combiné se comporte.

Une demande peut franchir une frontière de confidentialité, une frontière applicative et une frontière d’approbation avant d’être exécutée. Les preuves issues d’une étape ne peuvent pas établir que chaque étape ultérieure reste contrôlée.

L’approbation humaine nécessite également un objet concret. Un employé qui approuve un résumé n’a pas nécessairement approuvé une mise à jour de compte, un message destiné à un client ou une exportation.

Si l’action proposée change après l’approbation, le système doit prévoir une réponse définie. La poursuite automatique peut dissocier l’action finale de ce que le réviseur a compris.

La reprise soulève une autre question. Restaurer des données après un incident n’annule pas un e-mail déjà envoyé ni une décision déjà communiquée à un autre système.

Une organisation doit donc identifier les actions qui peuvent être réessayées, celles qui exigent une révision et celles dont les conséquences ne peuvent pas être retirées.

Ces observations définissent les limites de l’affirmation de sécurité sans écarter les améliorations sous-jacentes. Réduire les expositions inutiles reste précieux, même lorsque des contrôles supplémentaires sont nécessaires.

La conclusion appropriée est plus restreinte et plus utile : la sécurité IA de Teradata offre aux acheteurs davantage de capacités à évaluer, tandis que la responsabilité du workflow complet de l’agent reste partagée.

Les preuves de déploiement orienteront les prochaines décisions d’achat

Au cours des prochains mois, les éléments les plus utiles concerneront la couverture de déploiement, l’application des contrôles lors de workflows réels et la reprise dans des conditions opérationnelles. Ces signaux préciseront comment l’annonce se traduit en protection exploitable.

Les preuves d’acceptation par les clients compteront davantage que l’ampleur de la description du lancement.

Le premier signal est une couverture de déploiement précise. Les clients ont besoin d’une documentation identifiant les protections qui fonctionnent dans leur environnement, y compris les dépendances et les conditions de disponibilité.

La preuve qu’un client peut appliquer les contrôles requis tout au long de son workflow prévu renforcerait l’argument en faveur d’une extension. Des lacunes de couverture non résolues limiteraient les cas d’usage appropriés.

Cela n’exige pas que chaque environnement prenne immédiatement en charge des fonctionnalités identiques. Cela exige que les acheteurs comprennent la frontière avant d’autoriser l’accès à des informations sensibles.

Une limitation clairement formulée peut soutenir une décision de déploiement solide. Une déclaration de disponibilité ambiguë laisse les équipes applicatives faire des suppositions que les réviseurs de sécurité ne peuvent pas évaluer de manière fiable.

Le deuxième signal est l’application observable des politiques. Des démonstrations utiles montreraient un agent accomplissant une tâche approuvée, rencontrant une demande restreinte et s’arrêtant à la bonne frontière.

Les preuves devraient identifier l’utilisateur agissant, l’autorisation applicable et l’opération tentée. Une réponse finale soignée ne peut pas établir que le chemin emprunté était autorisé.

Une application réussie malgré l’évolution des autorisations renforcerait la confiance dans un déploiement plus large. Des workflows dépendant d’identifiants bénéficiant de privilèges étendus affaibliraient cette confiance.

La même évaluation devrait prendre en compte le travail légitime. Un système qui bloque les demandes non autorisées mais empêche régulièrement les tâches approuvées crée une pression opérationnelle en faveur d’exceptions.

Cette tension rend les preuves issues de workflows réels particulièrement utiles. Les acheteurs doivent voir si les restrictions restent compréhensibles et pratiques lorsque les employés rencontrent des informations incomplètes ou des demandes inhabituelles.

Le troisième signal est une preuve de reprise couvrant le workflow de l’agent autant que les données sous-jacentes. Un exercice significatif établirait quelles informations ont été restaurées et quelles actions avaient déjà eu lieu.

Il devrait également montrer comment l’organisation décide de reprendre, réviser ou abandonner un travail interrompu. La poursuite automatique n’est appropriée que si les autorisations et hypothèses pertinentes restent valables.

Un exercice de reprise préservant ces distinctions renforcerait l’argument de résilience. Restaurer les enregistrements tout en laissant l’historique des actions incertain révélerait un bénéfice opérationnel plus limité.

Il s’agit de signaux d’évaluation, et non d’échéances Teradata programmées ou de prévisions concernant les résultats futurs des clients. Ils offrent un moyen de juger les nouvelles preuves à mesure qu’elles deviennent disponibles.

Pour les acheteurs en entreprise, l’action immédiate consiste à sélectionner un workflow représentatif et à définir ses conditions d’acceptation avant d’étendre les accès. Précisez les informations dont il a besoin, les actions qu’il peut effectuer et les approbations qui restent nécessaires. Demandez ensuite aux fournisseurs de démontrer ces frontières dans le cadre d’un usage ordinaire, de demandes refusées et d’interruptions. La sécurité IA de Teradata mérite une évaluation à ce niveau de détail. La décision devrait relier les protections disponibles à un processus métier que l’organisation peut observer et gouverner. Quel workflow d’agent votre équipe peut-elle autoriser assez clairement pour expliquer chaque lecture sensible, chaque action conséquente et chaque décision de reprise ?