Teradata AI Security、エージェントのアクセス拡大に伴いプライバシー管理を追加
Teradataは10月20日、自律型エージェントによる企業システムへのアクセス拡大に伴う機微データの露出を対象として、新たなAIセキュリティ対策を発表した。Teradata AI securityのアップデートは、プライバシー保護とセキュリティおよび復旧機能を組み合わせるものだ。中核となる課題は、自動化システムが特定・実行できる範囲を制限しつつ、有用なデータの関係性を維持することにある。
これにより、企業の購買担当者は相反する要件の間で判断を迫られる。エージェントが有用な業務を完了するにはコンテキストが必要だが、アクセスを広げればミスの影響も拡大する。基盤となる情報の保護は役立つものの、誰が行為を承認したのか、あるいはその行為を進めるべきかという問題までは解決しない。
Snowflakeはすでに、ガバナンスの効いたデータアクセスをエージェントプラットフォームの一部として位置付けている。そのためTeradataには、顧客が既存環境全体にどの程度の保護を展開できるかという実務的な購買上の問いがある。セキュリティチームにとって、この発表は露出を抑える機会であると同時に、高度化するソフトウェアを取り巻く権限を見直す契機にもなる。
Teradata AI Security、プライバシーを運用上の復旧と結び付ける
Teradataの発表は、アイデンティティ保護、暗号化、イミュータブルバックアップ、データベース可用性に及ぶ。イミュータブルバックアップとは、改変や削除から保護された復旧用コピーを指す。同社は、企業向けAIの稼働を維持するため、これらの機能を相互に関連する要件として提示している。
TeradataはAnonomaticを通じて、個人を特定できる情報、すなわちPIIを安定した識別子に置き換えつつ、元となるアイデンティティを分離するPoly-Anonymizationを提供する。同社によれば、これにより分析に必要な関係性を保持できるという。同社のフォーマット保持暗号化は、下流アプリケーションが期待する構造を維持したまま値を保護する。
データ保護機能には、将来の量子コンピューターによる従来型暗号への脅威を想定した耐量子トランスポート保護も含まれる。機能や導入形態によって利用可否は異なる。購入者は、現在利用可能なクラウド機能と、他の環境向けに計画されている機能を区別すべきだ。
この発表の実務的な価値は、顧客が実際のワークロードにどの保護機能を適用できるかに左右される。
例として、顧客分析のワークフローを考えてみる。エージェントは、繰り返し発生するサービス上の問題を特定するために、購入履歴、サポート対応、アカウント履歴を結び付ける必要があるかもしれない。このタスクは、顧客名を受け取らなくても完了できる可能性がある。
この区別により、プライバシーチームはデータセット全体を承認または拒否する以外に、より具体的な判断を下せる。すなわち、そのタスクに必要な関係性は何か、どの識別フィールドが必要か、そして両者の要件がどこで分かれるかを問える。
同じ区別は復旧にも当てはまる。有用な回答には利用可能な情報が必要だが、復旧可能なデータベースが自動的に復旧可能な業務プロセスを意味するわけではない。組織は、停止前にどの行為が発生したかも把握しなければならない。
あるエージェントがサービス提案を準備中にデータ接続を失ったケースを想像してみよう。基礎となるレコードを復元すれば復旧には役立つ。だが、そのエージェントがすでに提案を送信したかどうかの判断には、行為に関する別の記録が必要になる。
これらの例は、Teradata顧客における文書化された成果ではなく、評価シナリオを示したものである。プライバシーとレジリエンスが購買の議論に含まれるべき理由を示す一方、各機能については別々の受け入れ基準を維持している。
プライバシーのテストでは、エージェントが不要な識別情報を受け取ったかを問う。復旧のテストでは、信頼できる状態から運用を再開できるかを問う。組織がワークフロー全体を検証しない限り、どちらか一方のテストに合格しても、もう一方について語れることはほとんどない。
これらの機能を結び付けることの運用上の意義はそこにある。顧客は、プライバシー、アプリケーションの挙動、復旧をそれぞれ別に評価してきたチーム間の依存関係を見直す理由を得る。
ただし、調達上の議論を統合しても、証拠まで一体化すべきではない。各保護機能には、明確な適用範囲、責任を持つ担当者、機能したかどうかを確かめる手段が必要だ。
セキュリティチームはエージェント開発者だけでは決められない判断を引き継ぐ
直接的な圧力は、機微情報へのアクセスを承認する企業チームにかかる。エージェント開発者はタスクを定義できるが、基盤となるデータのあらゆる許容利用を独自に決めることはできない。
開発者が、エージェントの回答を改善するために十分な情報を求めるのは合理的かもしれない。プライバシー担当者は、その情報を公開する正当な目的が組織にあるかを検討しなければならない。運用チームは、障害が及ぼす影響を考慮する必要がある。
こうした責任は導入時に交差する。デモは、慎重に選ばれた入力と広範な権限で成功することがある。本番環境では、変化する利用者、不慣れな要求、回答画面の外側にまで影響を及ぼす業務プロセスが導入される。
エージェントへのアクセス付与は、技術統合を委任された権限に関する判断へと変える。
委任された権限とは、他者に代わって行動する許可を意味する。企業向けエージェントにとっては、各リクエストに誰の権限が伴うのかという直接的な問いにつながる。
NISTは2026年2月、エージェントアイデンティティに関する取り組みでこの問題を取り上げた。同機関のコンセプトペーパーは、ソフトウェアエージェントの識別、認可、監査、説明責任について意見を募った。この取り組みは、特定製品を認定するものではなく、ベンダーの主張を評価する文脈を提供する。
購入者にとっての示唆は明快だ。エージェントを承認済みアプリケーションとして認識しても、そのアプリケーションが実行すべきすべての行為が説明されるわけではない。承認は、行為者、タスク、関係する情報を結び付ける必要がある。
例として、アカウントサポートのエージェントを考える。取引パターンへのアクセスはトラブルシューティングを支援し得る。一方、アイデンティティ記録へのアクセスは、別途承認された本人確認ステップにおいて適切となる場合がある。
両方の操作が同じ広範な認証情報を使用する場合、その分離を強制することは難しくなる。現在のタスクが必要としていない場合でも、システムは技術的にはアイデンティティの取得を許可してしまう可能性がある。
逆に、制限が粗すぎれば、従業員は正当な業務を完了できなくなる。その結果、例外を求めたり、情報を管理の緩いワークフローへ移したりする圧力に直面する。
これは組織上のトレードオフを生む。セキュリティチームには実際のタスクを反映する制限が必要であり、アプリケーションチームには、その制限が適用される際の予測可能な挙動が必要だ。
したがって、拒否されたリクエストは理解可能であるべきだ。従業員は、制限が権限の不足、データの利用不能、またはサポートされていない操作のどれによるものかを知る必要がある。そうでなければ、セキュリティ境界は製品の欠陥のように見える可能性がある。
この影響は、文書や業務記録を横断してAIを利用するナレッジワーカーにも及ぶ。個人向けナレッジベースと共有された企業リポジトリでは、アクセスに対する期待が異なる。どちらを自動化に接続する場合でも、誰の情報が利用可能になるのかを明確にする必要がある。
Teradataの発表は、こうした判断をデータプラットフォームに関する議論へ近づける。顧客は、エージェントが到達できる範囲を広げる前に、プライバシー、セキュリティ、事業チームの間で合意を得る必要がある。
データの関係性を維持することはプライバシー上のトレードオフを生む
中心となるトレードオフは、エージェントが有用であり続けるために必要な情報にある。アイデンティティを取り除けば露出を減らせる一方、関係性を維持すれば分析を継続できる。その関係性自体が機微情報であり続ける場合もある。
例として、ある小売エージェントが店舗と購入履歴をまたぐ繰り返し返品を調べるとする。安定した識別子により、顧客名を表示せずに反復的な活動を認識できる。
この設計は、直接的なアイデンティティ露出を制限する。しかし、それによって得られるすべてのパターンが、すべての従業員、アプリケーション、目的にとって適切になるわけではない。詳細な行動履歴は、明白な識別子がなくても機微な意味を持ち得る。
有用な関係性と許容できる開示には、別々の判断が必要である。
このため、プライバシーに関する主張は、想定されるワークロードに照らして評価する必要がある。企業は、エージェントが受け取るフィールドと、許可されたクエリから導き出せる推論の両方を検討すべきだ。
重要な問いは、名前が消えるかどうかにとどまらない。エージェントが不必要に詳細なプロファイルを組み立てられるか、出力が機微なパターンを明らかにするか、そして誰がその出力を受け取るかも含まれる。
これらはTeradataの実装に欠陥があることを示す証拠ではなく、提案されたアーキテクチャから導かれる分析上の含意である。成功した保護機能であっても、意図された範囲外に判断を残し得るため、重要となる。
たとえば、アイデンティティを分析から分離することは、直接的な特定をめぐる境界を設定する。その後、組織はその境界を越えることが正当な事業目的にかなうのはいつかを決めなければならない。
不正調査では、承認済みのレビュー後にアイデンティティを復元することが正当化される可能性がある。日常的な傾向分析では、そうではないかもしれない。同じ基礎レコードは両方のタスクを支えられるが、認可はそれぞれの異なる目的を反映すべきだ。
ワークフローは部分的な成功にも対応する必要がある。エージェントはパターンを正しく要約しつつ、後続ステップに追加の権限が必要であることを認識できないかもしれない。
その時点で停止するシステムは境界を維持する。より広い認証情報を黙って代用するシステムは、当初の承認の意味を変えてしまう。
この区別は、プライバシー保護をモデルに振る舞いを指示するだけでは完結できない理由を説明する。周辺アプリケーションは、権限がない場合に、許可されていない情報や行為を利用できないようにしなければならない。
また、分析上の有用性を維持することに独自の証拠が必要な理由も示している。プライバシー管理はアイデンティティを保護できる一方、特定タスクの品質を変える可能性がある。購入者には、両方の結果について代表性のある評価が必要だ。
こうした評価は、従業員が実際に尋ねる質問を反映すべきである。一般的なデモでは、保護されたデータセットが特定の調査、予測、顧客サービスのプロセスを支えられるかどうかを確立できない。
目標は、許容可能な能力について明示的な合意を形成することだ。エージェントは、承認されたタスクを実行するために十分なコンテキストを受け取り、その範囲を超えるものを要求する明確なプロセスを備えるべきである。
この合意により、購入者はプライバシーと有用性が常に対立すると仮定せずに、Teradataのアプローチを評価できる。一部のタスクは、既存のワークフローが日常的に公開しているほどの識別情報を必要としない。
機会は、そうしたタスクを認識し、デフォルトのアクセスを変えることにある。残る課題は、エージェントの責任範囲が拡大しても、その規律を維持することだ。
競合各社はガバナンスの効いたアクセスを購買の基準にしている
Teradataは、AIが利用する企業データの保護をめぐる既存の競争的な議論に参入している。同社の発表は、既存顧客に対し、現在のプラットフォームとの関係の中で検討すべき追加機能を提示するものだ。
TechTargetのエンタープライズ・プライバシー分析で、TreeHive Strategyの創業者Donald Farmer氏は、これらの追加機能を意義ある運用面の強化だと評価した。一方で、それらは主としてTeradataを最新のクラウドデータプラットフォームと同水準に引き上げるものだとも指摘している。
BARCのアナリストKevin Petrie氏も、企業の優先課題との整合性を歓迎する一方、類似の機能は他にも存在すると述べた。こうした評価は、慎重な見方を支持する。顧客にとって有用な改善が、必ずしも競争上の優位性を示すわけではない。
購入者は機能名を比較するのではなく、同等のタスクにおいて強制可能な挙動を比較すべきだ。
Snowflakeのドキュメントでは、Cortex Agentsはガバナンスが適用された環境内で動作すると説明されている。データアクセスはプラットフォームの権限と、設定された各ツールの実行コンテキストに依存する。またドキュメントは、回答の正確性や引用は保証されないとも警告している。
これは、両プラットフォームの同等性を示すものではないが、有用な比較基準となる。ガバナンスに関する共通の用語があっても、導入範囲、制御、運用上の責任が同一であることを意味しない。
ベンダーを比較する企業は、同じ業務上の要求から始めるべきである。エージェントには、同等のソース情報、ユーザー権限、許可されたアクションを与える必要がある。そうでなければ、見かけ上の違いは設定の差を反映している可能性がある。
たとえば、制限のないレコードへのアクセスを与えられたエージェントは、限定的な権限内で動作するエージェントよりも高性能に見えることがある。その結果は、エージェントの能力だけでなく、付与されたアクセス範囲も測定している。
比較には、アクセスが変化した際に何が起こるかも含めるべきだ。別の部門へ異動した従業員が、以前の会話が開いたままであるというだけで機密アクセスを保持してはならない。
同様に、エージェントのインターフェースへのアクセスは、接続されたすべてのツールを使用する権限を意味するべきではない。ワークフローには、所有者もルールも異なる複数のシステムが関わる場合がある。
購入者の既存環境は、こうした違いを商業的に重要なものにする。現在のアイデンティティ管理や運用プロセスと統合された機能は、孤立した機能よりも一貫して適用しやすい可能性がある。
ただし、慣れ親しんでいることが検証の代わりになるべきではない。既存顧客であっても、新たに導入された制御機能が自社の展開条件下で期待どおりに動作するという証拠が必要だ。
また、機能差だけでプラットフォーム全体の判断が自動的に決まるべきでもない。顧客は、エージェント機能とともに、データの所在地、アプリケーション依存関係、スタッフの専門性、復旧要件を考慮する。
したがって競争圧力は具体的である。Teradataは、その保護機能が顧客がすでに運用している環境全体で、ガバナンスの効いた業務をどのように支えるのかを示す必要がある。
競合ベンダーにも同じ基準が適用される。ガバナンスに関する主張は、顧客がアイデンティティからデータアクセス、そして実行されたアクションまで要求を追跡できる場合に説得力を持つ。
これにより、購買に関する議論は観察可能な挙動へと移る。最も有力な比較は、各システムが何を許可し、何を阻止し、その後にどのような証拠を残すかを明らかにする。
データ保護だけでは、エージェントが行動すべきかどうかは決まらない
プライバシー、暗号化、復旧は、それぞれ異なる障害モードに対応する。いずれも単独では、エージェントが要求を正しく解釈したか、適切なアクションを選択したかを判断するものではない。
この違いは、エージェントが悪意あるコンテンツに遭遇した際に重要となる。プロンプトインジェクションとは、エージェントがデータとして扱うべき資料に埋め込まれた指示を指す。
NISTによるエージェント乗っ取りに関する取り組みは、このようなコンテンツがエージェントを有害なタスクへ誘導し得ることを説明している。そこでは、適応的な評価と、タスク固有の攻撃結果の検証が重視されている。
レコードを保護することと、エージェントによるそのレコードの利用を制御することは、別個のセキュリティ要件である。
例として、サポートワークフローを考える。エージェントは社内要約を作成するために顧客メッセージを読む。そのメッセージには、無関係なアカウント情報を取得するよう求める指示が含まれている。
暗号化は、送信中の情報を保護できる。アイデンティティの分離は、エージェントが受け取る情報を制限できる。しかし、これらの機能だけでは、埋め込まれた要求に正当な権限があることは示されない。
したがってアプリケーションには、業務中に遭遇した情報と、追加の業務を実行する権限との境界が必要になる。そうでなければ、信頼できないコンテンツが本来の役割を超えて意思決定に影響を及ぼし得る。
これは、10月の発表がすべてのエージェントセキュリティ問題を解決すると主張しているという意味ではない。顧客は、データ保護ポートフォリオを自律的な挙動への完全な回答として解釈すべきではない、という意味である。
Teradataは別途、Tera Harnessを、エージェントワークフロー内にポリシー制御と人間による承認を備えた実行レイヤーとして説明している。同社の9月の発表では、Tera Context Engine、Tera Harness、Agent Skillsを2026年第4四半期に提供予定としていた。
これらの企業声明は、意図された製品の方向性を示す。あらゆる不正なアクションや悪意ある入力に対する保護を、独立して実証するものではない。
発表ごとの区分は重要である。購入者は、どの機能が併用可能か、どの統合がサポートされるか、統合されたワークフローがどのように動作するかを検証すべきだ。
要求は完了前に、プライバシー境界、アプリケーション境界、承認境界をまたぐ可能性がある。ある段階の証拠だけでは、後続するすべての段階が引き続き制御されていることを示せない。
人間による承認にも、具体的な対象が必要である。要約を承認する従業員が、必ずしもアカウント更新、顧客へのメッセージ送信、またはエクスポートを承認したことにはならない。
承認後に提案されたアクションが変わる場合、システムには定義された対応が必要になる。自動的に継続すれば、最終的なアクションがレビュー担当者の理解から乖離しかねない。
復旧は別の問題も提起する。インシデント後にデータを復元しても、すでに送信されたメールや、別のシステムにすでに伝達された判断を取り消すことはできない。
そのため組織は、再試行可能なアクション、レビューが必要なアクション、結果を撤回できないアクションを特定する必要がある。
これらの観点は、根本的な改善を否定することなく、セキュリティ上の主張の限界を定める。不必要な露出を減らすことは、追加の制御が必要な場合でも依然として価値がある。
より限定的で有用な結論は次のとおりである。Teradata AI securityは購入者に評価すべき機能をさらに提供する一方、完全なエージェントワークフローに対する責任は引き続き共有される。
導入の証拠が次の購買判断を左右する
今後数カ月で最も有用な証拠となるのは、導入範囲、実際のワークフローにおける強制、運用条件下での復旧に関するものである。これらのシグナルは、発表内容が実用的な保護へどのように転換されるかを明らかにするだろう。
顧客による受け入れの証拠は、ローンチ説明の広がりよりも重要になる。
最初のシグナルは、具体的な導入範囲である。顧客には、依存関係や利用可能条件を含め、自社環境でどの保護機能が動作するかを示す文書が必要だ。
顧客が意図したワークフロー全体に必要な制御を適用できるという証拠は、拡大導入の根拠を強める。未解決のカバレッジギャップは、適切な利用範囲を狭めることになる。
これは、すべての環境が直ちに同一の機能をサポートすることを求めるものではない。機密情報へのアクセスを承認する前に、購入者が境界を理解できることを求めるものである。
明確な制限は、健全な導入判断を支え得る。曖昧な利用可能性に関する記述は、セキュリティレビュー担当者が確実に評価できない前提をアプリケーションチームに置かせる。
2つ目のシグナルは、観察可能なポリシー強制である。有用なデモンストレーションでは、エージェントが承認済みタスクを完了し、制限された要求に遭遇し、正しい境界で停止する様子が示されるだろう。
証拠には、操作したユーザー、適用された権限、試行された操作を特定する情報が必要である。洗練された最終回答だけでは、その経路が認可されていたことを示せない。
権限が変化する状況でも強制が成功することは、より広範な導入への信頼を高める。広範な権限を持つ認証情報に依存するワークフローは、その信頼を弱める。
同じ評価では、正当な業務も考慮すべきだ。不正な要求を阻止しつつ、承認済みタスクを繰り返し妨げるシステムは、例外を求める運用上の圧力を生む。
この緊張関係により、実際のワークフローの証拠は特に有用になる。従業員が不完全な情報や通常と異なる要求に遭遇した場合に、制限が理解可能かつ実用的なままかを購入者は確認する必要がある。
3つ目のシグナルは、基盤データだけでなくエージェントワークフローも対象とする復旧の証拠である。意味のある演習では、どの情報が復元されたか、どのアクションがすでに実行されていたかを明らかにする。
また組織が、中断された作業を再開するか、レビューするか、放棄するかをどのように判断するかも示すべきだ。関連する権限と前提が依然として有効な場合に限り、自動継続は適切となる。
こうした違いを維持する復旧演習は、レジリエンスに関する主張を強める。アクション履歴が不確実なままレコードだけを復元する場合、運用面での利点はより限定的であることが明らかになる。
これらは、Teradataの予定されたマイルストーンや将来の顧客成果に関する予測ではなく、評価のシグナルである。新たな証拠が得られた際に、それを判断する方法を提供する。
エンタープライズ購入者にとって当面の行動は、代表的なワークフローを選び、アクセス拡大の前にその受け入れ条件を定義することだ。必要な情報、実行可能なアクション、引き続き必要な承認を明確にする。そして、通常利用、拒否される要求、中断の状況で、これらの境界を実演するようベンダーに求める。Teradata AI securityは、そのレベルの詳細さで評価されるに値する。判断は、利用可能な保護機能を、組織が観察し統制できる業務プロセスに結び付けるべきである。チームは、すべての機微な読み取り、重大なアクション、復旧判断を説明できるほど明確に、どのエージェントワークフローを認可できるだろうか。
