カスタムエージェントにセキュリティを組み込む方法

カスタムエージェントの立ち上げにおいて重要な要素は、この新しいタイプのAIワークフローが顧客にとってできるだけ安全であることを確認することでした。

今日のほとんどのAIエージェントは、比較的単純な権限のセットを持つ単一のユーザー向けに構築されています。しかし、協力的な環境におけるエージェントは異なるニーズを持っています。すべてを行う権限を与えることは危険であり、何も行う権限を持たないことはほとんど役に立ちません。

私たちのカスタムエージェントでは、協力的な環境で適切な支援を提供するために十分なアクセスを持ちながら（例：タスクの割り当て）、デフォルトではエージェントが危険な行動を取れないように厳格な制約を適用することに細心の注意を払っています（例：すべてのコンテンツを削除する）。これまでの数年間、私たちは顧客がワークスペースを管理するための高度な権限管理とガバナンスコントロールを構築してきました。そして、同じ構造を利用して、ユーザーがエージェントの細かい制御を行えるようにし、ワークスペース内でできるだけ安全に作業できるようにしています。

カスタムエージェントは、エージェントがほとんどのリソースへのアクセスなしで開始する、何もないところから構築されたセキュリティモデルを使用しています。つまり、何も読む、書く、または相互作用する権限がありません。

このアプローチは、多くの個人AIアシスタントとは意図的に対照的で、これらはしばしば広範なアクセスから始まり、ユーザーが安全指示が圧縮されないようにする必要があります。私たちは、安全性をモデルの意思決定に任せたくありません。代わりに、アクセス制御と決定論的レイヤーに安全性を組み込みたかったのです。

このようにして、ユーザーが自分のユースケースに対して適切なセキュリティ決定を行えるように細かい制御を提供し、上級ユーザーが非常に能力の高い自律エージェントを構築できるようにしています。

デフォルトで最も制限的であることは素晴らしいですが、ユーザーがアプリケーションに必要な権限を簡単に構築し理解できることが重要です。

以下は注目すべきいくつかのものです：

• 権限のページレベルの粒度：ユーザーは特定のページに対して表示または編集アクセスを付与でき、広範なワークスペースアクセスだけではありません。

• ファーストパーティのSlack統合：ファーストパーティのSlack統合を提供することで、MCPが提供しない方法で簡単に構成できる細かい権限を持つことができます。

• メール：メールを送信する前に確認するかどうかを選択できます。

• MCP統合: MCP統合を使用する際は、リソースベースではなく、利用可能にしたいツールを指定できます。また、特定の種類のアクションを常に許可するかどうかを尋ねることもできます。

エージェントが実際に作業を行っているときの予期しない動作についても考慮する必要がありました。ここでは、マルチレイヤーのセキュリティアプローチを採用し、権限管理とランタイムプロンプトインジェクションの緩和を意味します。

プロンプトインジェクション保護: プロンプトインジェクション は、AIエージェントにとって最大かつ最もよく知られた課題の一つです。未解決の問題であり続けますが、すべてのプロンプトインジェクションが捕まると仮定してシステムを設計しているわけではありません（多くのものを捕まえていますが）。その代わりに、プロンプトインジェクションの影響をブロックするための層状の制御を持ち、外部データのタグ付けと監視に特に注意を払うように設計しました。何かが疑わしく見える場合や、エージェントが潜在的な攻撃を示すアクションを実行した場合、エージェントを停止し、ユーザーに確認を求めることができます。

警告システム: エージェントが潜在的にリスクのある行動をしようとする際、まずユーザーに確認を求めて一時停止します。これがどのように行われるかは、ユーザーがエージェントを設定しているか実行しているかによります。リスクのある行動をする可能性のあるエージェントを設定する際、ユーザーには単純な確認からワークスペース管理者の承認が必要なものまで、さまざまなポップアップを提供します。エージェントがランタイム中にリスクのある行動を行った場合、カスタムエージェントの所有者にそのアクションを確認させることを強制します。この作業は、プラットフォーム全体での権限とセキュリティに対する多面的なアプローチを反映しています。

修正（つまり、削除ボタン）: エージェントが間違ったことをした場合、例えばSlackに不正確な投稿をした場合、エージェントの所有者はそのメッセージを削除できます。これは簡単に聞こえますが、発生した場合にユーザーが損害を元に戻す方法を提供することが重要です。

このモデルに到達するために、私たちはNotion内部および外部の顧客と共に広範なアルファテストプログラムを実施しました。特に、セキュリティが実際にどのように機能するかをスケールを増してストレステストしたいと考えていました。アルファテスト期間の終わりまでに、Notionには3,000以上の内部カスタムエージェントがあり、アルファ顧客は25,000以上を作成しました。

私たちは非常に早くいくつかの教訓を学びました。例えば、初期の内部バージョンのカスタムエージェントは、ユーザーが潜在的な結果を理解せずに過度に許可することを奨励しました。ユーザーは、エージェントにSlackへの広範な書き込みアクセスを与え、何度かそのエージェントが#generalに投稿することさえありました（エージェントはすべてのSlackワークスペースに#generalがあることを知っています！）、数百人が参加する会社全体のチャンネルです。明らかに、これはユーザーの意図ではありませんでした！これが、エージェントが明示的にトリガーされたスレッドに返信できる新しいカスタム「読み取りおよび返信」権限をSlackに導入することにつながりました。私たちは、ユーザーが「すべてを許可する」ことを強制されるのではなく、安全に作業を完了できるようにするための権限を導入することが私たちの仕事だと考えています。

これにより、MCPに依存するのではなく、いくつかのファーストパーティ統合を構築するという意図的な決定を下しました。すでに議論したように、今日のほとんどのMCPは、シングルプレイヤーのユースケース向けに設計されているため、一般的にリソースベースの権限やトリガーをネイティブに処理しません。ファーストパーティ統合を構築することで、顧客に追加の作業を強いることなく、私たちの権限モデルを強制するためのコントロールを得ることができました。

特に誇りに思っていることの一つは、このプロセスを通じて、私たち自身のセキュリティチームがカスタムエージェントの最も活発な内部ユーザーの一つになったことです。例えば、彼らはセキュリティアラートをトリアージし、強化するためのエージェントScruffを構築し、AppSecの自動化、コード修正の生成、敵対的テストの実行にエージェントを使用しています。これは、私たちのAI製品チームとセキュリティチームとの真のコラボレーションでした。

ローンチは始まりに過ぎず、私たちは製品と全体の分野が前進するにつれて、より良い安全性とセキュリティの保護策に多大な投資をしています。今後数ヶ月のカスタムエージェントのベータ期間は、顧客と共に改善を続けるのにも役立ちます。

今後数週間と数ヶ月で、私たちは以下に取り組むことを期待しています：

• 高度なユースケースのためにワークスペース管理者の承認を必要とするより広範な権限スコープの再導入

• Workersプラットフォーム上に構築された外部統合に対して、詳細な権限機能を拡張する

• さらなるガードレールが整備された後、異なるユースケースのための追加の権限モードを検討する

私たちはまだこの技術を構築する初期段階にあり、改善方法についてコミュニティからのフィードバックを歓迎します。