AIを単なるSaaSアプリのように扱うのをやめる

リスクが発生する場所、すなわちプロンプト、出力、およびアクションにおいてAIを保護します。

従業員はAIを活用して、生産性を向上させ、習得に何年もかかるようなスキルを身につけている。これには、コンテンツの草案作成、コードの記述、自動化されたワークフローの構築などが含まれます。このような利用の一部は承認されています。しかし、その多くは承認されていません。

多くのセキュリティチームにとって、最初の直感は、このリスクを他のSaaSリスクと同様に扱うことです。つまり、アプリを発見し、アクセスを許可またはブロックし、DLPルールを適用し、利用状況をレポートすることです。このモデルは従来のSaaSには有効ですが、AIは異なります。

AIリスクは、常にアプリ、ファイル、または構造化されたデータフィールド内にきれいに収まるわけではありません。それはプロンプト、応答、およびAIシステムが実行できるアクションに現れるため、それを保護するには異なる種類の制御が必要です。

従来のコントロールがAIに対して不十分となる領域

多くのAIセキュリティツールは、CASBやDLPの技術を応用しています。従業員が使用しているAIアプリケーションを特定してアクセスを制御するためのCASBと、クレジットカード番号、認証情報、規制対象データ、ソースコードなどの既知の機密データを検知するためのDLPです。

これらのコントロールはSaaSにおけるリスクを軽減しますが、AI向けに構築されたものではありません。

AIリスクはコンテキスト的かつセマンティック（意味論的）です。コンテキスト的というのは、ユーザーが何を求めているか、およびそのビジネスコンテキストに依存するためであり、セマンティックというのは、人間がどのように話すかを理解する必要があるためです。ユーザーが完全な形のクレジットカード番号、APIキー、または顧客記録を貼り付けなかったとしても、リスクがないとは言いきれません。区切り文字を削除したり、データを行に分割したり、エンコードしたり、言い換えたり、あるいは部分的な情報から意味を再構築するようモデルに指示したりすることが可能です。

「昨日のエスカレーションの顧客」、「インシデントドキュメントの管理者トークン」、または「取締役会の準備で議論した買収対象」といった言及をするかもしれません。静的なパターンマッチングでは、これらすべてを見逃す可能性があります。

従来のアプリ制御は、誰かがAIツールにアクセスできるかどうかを決定できます。DLPは、認識可能なデータを検索することができます。しかしどちらも、プロンプトの意図や文脈のニュアンスを確実に把握することはできません。

これにより、セキュリティチームは厄介なトレードオフを迫られます。制限を厳しくしすぎると、ユーザーを可視化できないツールへと追いやることになります。許可しすぎると、プロンプト、出力、API、またはエージェントを通じてデータが漏洩する可能性があります。

Top 4 AI Security Challenges CISOs Face | Download the eBook

AIセキュリティには、インタラクションを理解することが不可欠です。

AIを保護するには、インタラクションそのものを検査するコントロールが必要です。

それは、コンテキストの中でプロンプト、応答、およびエージェントのアクションを分析することを意味します。それは、ユーザーがモデルに公開ドキュメントの要約を依頼しているのか、それとも機密扱いのビジネス戦略を露出させようとしているのかの違いを理解することを意味します。また、AIエージェントが不正なアクションを試みた場合や、プロンプトインジェクション攻撃が振る舞いを操作しようとした場合を特定することも意味します。

ここでは、デフォルト拒否（Default-deny）のアプローチはスケールしません。目標は、コンテキストに基づく精度です。

コンテキストがAIリスクをどのように変化させるか

AIインタラクション	安全な利用	リスクを伴う利用	セキュリティが理解すべきこと
コンテンツ作成	マーケターが公開キャンペーンの概要を作成する。	マーケターが未発表のメジャーリリースの詳細を使用して発表の概要を作成する。	ユーザー、データの機密性、宛先、および意図。
ソフトウェア開発	開発者がAIに汎用コードの説明を求める。	開発者がAIに顧客特有のロジックを含む独自のコードの説明を求める。	コードに知的財産（IP）、シークレット、または顧客のコンテキストが含まれているかどうか。
AIエージェント	社内エージェントが承認されたナレッジベースのコンテンツを取得する。	社内エージェントが制限されたナレッジベースのコンテンツを取得し、それを外部と共有する。	アクションが許可されているか、および出力が安全であるかどうか。
プロンプト処理	ユーザーが承認されたコンテンツを要約する。	ユーザーがAIに機密情報の推測または再構築を求める。	プロンプトの意図または応答が露出を生み出すかどうか。

AIネイティブなコントロールは、アプリ自体を超えて、ユーザーが誰であるか、何を求めているか、どのようなビジネスコンテキストが関与しているか、そしてプロンプトが許可されるべきかどうかに基づいて意思決定を行う必要があります。

つまり、ポリシーはインタラクションの内部で機能しなければならないということです。機密データが露出したり、安全でないアクションが実行されたりする前に、プロンプト、応答、およびエージェントのアクションを分析する必要があります。DLPは依然として既知のデータパターンを保護するのに役立ちますが、AIセキュリティは、AIが実際にどのように利用されているかにガバナンスを効かせるために必要なコンテキストを追加します。

Cato AIセキュリティはAIインタラクションの内部でポリシーを施行する

Catoは、CASB、DLP、およびAIセキュリティを1つのプラットフォームに統合し、セキュリティチームが一貫した可視性と制御をもってSaaSおよびAIの利用にガバナンスを効かせるのを支援します。

Cato AIセキュリティは、アプリアクセスのポイントだけでなく、AIインタラクションの内部にコントロールを適用します。ユーザー、アプリケーション、データの機密性、意図などのコンテキストを使用して、プロンプト、応答、およびエージェントのアクションを分析します。

これにより、セキュリティチームはAIがどのように利用されているかを可視化でき、機密データの漏洩を防ぎ、プロンプトインジェクション、モデルの悪用、不正なアクション、データの持ち出しといったリスクからAIアプリやエージェントを保護します。

目標は、制御された導入です。組織は、従業員にAIを利用させ、ワークフローにAIを組み込み、新しいユースケースを試すことを可能にすると同時に、使い慣れたCASBやDLPのガードレールを、AIリスクが実際に現れる場所、すなわちプロンプト、出力、およびアクションへと拡張することができます。

インタラクションを保護し、ビジネスを可能にする

AIをブロックすることは安全に感じるかもしれません。しかし実際には、多くの場合、より多くのリスクを生み出します。

ユーザーは使いたいツールにアクセスできないと、回避策を見つけ出します。ポリシーが融通の利かないものだと、従業員はそれを迂回しようとします。シャドーAIが増加し、可視性が低下し、セキュリティチームは実際に何が起きているのかにガバナンスを効かせる能力を失います。

より良いアプローチは、制御された導入です。

CASBとDLPは、SaaSの検出、アクセス制御、機密データ保護、およびコンプライアンスにとって依然として不可欠です。AIセキュリティは、可視性と施行をAIインタラクションそのものへと拡張することで、それらを補完します。プロンプトが重要です。出力が重要です。エージェントのアクションが重要です。意図が重要です。

セキュリティチームには両方が必要です：アプリケーションとデータにガバナンスを効かせるためのCASBとDLP、そしてAIが実際にどのように利用されているかにガバナンスを効かせるためのAIセキュリティです。

AIを単なるSaaSアプリのように扱っていては、AIを活用することはできません。CASBとDLPの基盤を、インタラクションそのものを保護するAIネイティブなコントロールと組み合わせることで、AIの活用が可能になります。