Agent Studioのセキュリティ
Agent Studioは、ロールベースのアクセス、確認済みユーザーアクセス、および安全な認証を提供します。 詳細については、次のセクションを参照してください。
ロールベースのアクセス制御
Agent Studioは、Genieとナレッジベースに対してロールベースのアクセス制御(RBAC)を提供します。 これにより、コラボレーター権限を設定し、各ロールに固有のアクセス権限を定義できます。 これらの権限には、次へのアクセスが含まれます:
- 表示、編集、作成、削除などのGenieとナレッジベースの管理
- テストモード
- 会話履歴
プロジェクトレベルでロールを割り当てる
可能な場合は、プロジェクトレベルでコラボレーターロールを割り当てます。IT Genieを保守するビルダーには、ワークスペース所有者アクセスではなく、IT GenieプロジェクトへのProject Adminアクセスを付与する必要があります。 最小権限が管理原則です。
Genieアクセス制御には2つのアクセスレベルがあります。
コラボレーターアクセス:Genieを構築、編集、管理できるユーザーを制御します。 このロールは、組織内のビルダー、Genie所有者、管理者向けに設計されています。 これは、Workatoワークスペースのコラボレーターロールを通じて制御されます。
エンドユーザーアクセス:従業員や、Genieを使用して作業タスクを完了するチームメンバーなど、Chat Interfaceを通じてGenieと対話できるユーザーを制御します。 これは、WorkatoユーザーグループとそのIdPグループマッピングを通じて制御されます。
たとえば、IT Genieを編集できるビルダーはコラボレーターです。 IT Genieにパスワードのリセットを依頼できる従業員はエンドユーザーです。 これらは、別々の設定を持つ別々のロールです。
コラボレーターロール
Agent Studioのワークスペースコラボレーターロールは、ビルダーがプラットフォーム内で実行できる内容を定義します。 Genieデプロイメントに関連するロールには、以下が含まれます。
Project Admin:割り当てられたプロジェクト内のすべてのアセット(Genie、スキル、ナレッジベース、App Events、Data tablesを含む)を作成、編集、削除します。 これは、特定のGenieまたは一連のGenieを保守するGenieビルダーの標準ロールです。
Operator:レシピとジョブの履歴を表示します。 このロールでは、レシピやGenie設定を編集できません。監視やデバッグの目的でGenieアクティビティを把握する必要があるチームメンバーに適しています。
Workspace Owner:すべてのプロジェクトにわたるすべてのアセットへのフルアクセス。 このロールは、少数のプラットフォーム管理者に限定する必要があります。 このロールは、個々のGenieビルダーには適していません。
Conversation Historyアクセス:コラボレーターがGenieのConversationsページを表示できるかどうかを制御する、コラボレーターロール内の特定の権限です。 このロールは、デバッグのために必要なビルダーと、QAのために必要なGenie所有者に明示的に付与する必要があります。 このロールは、すべてのコラボレーターにデフォルトでは付与されません。
Test Modeアクセス:コラボレーターがTest Modeを使用して、分離されたテストセッションでGenieと対話できるかどうかを制御します。 通常、ビルダーにはこの権限が必要です。 この権限はエンドユーザーには推奨されません。
詳細については、Genieおよびナレッジベースのコラボレーター権限を参照してください。
エンドユーザーグループ
エンドユーザーグループは、特定のGenieにアクセスできる従業員を制御します。 各グループは、アイデンティティプロバイダーの1つ以上のIdPグループにマッピングされ、Genieのエンドユーザーアクセス設定で1つ以上のGenieに割り当てられます。
エンドユーザーグループは、プロジェクト構造とは独立して動作します。 これは、ユーザーグループを異なるプロジェクト内のGenieに割り当てられることを意味します。 プロジェクト構造は、ビルダーアセットの保存場所を管理します。 ユーザーグループ構造は、それらのビルダーが作成するGenieを使用できるユーザーを管理します。 Workatoでは、ユーザーグループをプロジェクト構造に合わせないことを推奨しています。
Genieの対象者と必要なアクセスレベルに基づいてユーザーグループを設計します。
単一階層アクセス: ほとんどのGenieは、すべての従業員がIT Genieを使用する場合や、営業チームがSales Genieを使用する場合のように、均一なアクセス権を持つ単一のユーザー集団に提供されます。 この設定では、Genieごとに1つのユーザーグループで十分です。
複数階層アクセス: 一部のGenieは、HR Genieに質問してリクエストを送信できる従業員や、さらにリクエストをレビューして承認できるHRマネージャーなど、異なる機能を持つ複数のユーザー集団に提供されます。 各アクセス階層に個別のユーザーグループを作成し、各階層で利用可能なSkillsとKnowledge Basesを適宜割り当てます。
Genie横断グループ: ITサポートチームがITヘルプデスクGenieとITインシデント管理Genieの両方にアクセスする必要がある場合など、一部のユーザー集団は複数のGenieにまたがります。 Genieごとに個別のグループを作成するのではなく、ITサポートチーム用に1つのユーザーグループを作成し、両方のGenieに割り当てます。
ユーザーグループの命名規則
ユーザーグループには、ユーザー層とアクセスレベルを反映した名前を付けます。 曖昧なグループ名は、大規模になると管理が困難です。
推奨される命名例
- IT Genie:全従業員
- Sales Genie:アカウントエグゼクティブ
- HR Assistant:全従業員
- HR Assistant:HRマネージャー
推奨されない命名例
- グループ1
- ユーザー
- Genieアクセス
検証済みユーザーアクセス
確認済みユーザーアクセスは、ランタイムユーザーコネクションを通じて機能し、スキルの実行時に各エンドユーザーが自分の認証情報で認証できるようにします。 これにより、スキルが個々のユーザーのIDと権限を使用してアクションを実行することが保証されます。 この機能は、次の機能を提供します:
- ユーザースコープのコネクション:Genieはランタイムでアクションを認証し、Workato Identity内の親コネクション、Environment、ユーザーIDにリンクするユーザーコネクションを作成します。
- Genieチャットでのキーワード管理:Genieは
! list_connectionsキーワードをサポートしており、チャットに直接入力してランタイムユーザーコネクションを管理できます。
マネージャーは、異なるユーザーグループが異なるスキルにアクセスできるGenieで、従業員が送信したリクエストを承認できます。 これにより、検証済みユーザーアクセスはアクセス差別化の追加レイヤーを提供できます。
検証済みユーザーアクセスを使用するスキルは、ターゲットシステム内の個々のユーザー自身の認証情報で実行されます。 Salesforceロールで商談フィールドの更新が許可されているマネージャーは、Update Opportunityスキルを実行できます。 Salesforceロールでその更新が許可されていない従業員は、Genieでそのスキルを呼び出せる場合でも、同じスキルを実行できません。
つまり、ターゲットシステム自体の権限モデルが、検証済みユーザーアクセスを使用するスキルのアクセス制御の追加レイヤーになります。 Workatoでのユーザーグループの割り当てにより、ユーザーがアクセスできるGenieが制御されます。 接続されたシステムでのユーザーの権限により、それらのGenieがユーザーに代わって実行できる内容が制御されます。
Guardrails
Agent Studioは、Genieが信頼性高く適切に動作するようにするセキュリティと安全性の制御として、Guardrailsを提供します。 常に有効で無効にできないシステムガードレールが2つあります。
- Prompt Attack検出は、Genieの動作を操作したり、システム設定を抽出したりする試みをブロックします。 - Harmful Contentフィルタリングは、危険な素材が処理または生成されることを防ぎます。
ビルダーは、次のような追加の保護も設定できます。
- PII検出
- 不適切表現フィルター
- カスタム単語フィルター
- 拒否トピック
これらの制御により、ビルダーがセキュリティをゼロから実装する負担が軽減されるとともに、組織がデータ保護とAIガバナンスに関するコンプライアンス要件を満たすのに役立ちます。
詳細については、Guardrailsを参照してください。
安全な認証
Genieのアクション、レスポンス、データアクセスは、ビルダーが設定したコネクション、またはエンドユーザーのIDと権限のいずれかに依存します。 これにより、セキュリティポリシーへの準拠が保証されます。
Agent Studioのセキュリティは、次の機能を提供します:
- 既存の認証システムとの統合
- ロールベースのアクセス制御(RBAC)
- 実行されたすべてのアクションの監査証跡
- 組織のセキュリティポリシーへの準拠
詳細については、Workato Identityを参照してください。
AIガバナンスポリシー
正式なAIガバナンスポリシーを持つ組織でGenieをデプロイする前に、デプロイメントがポリシー要件を満たしていることを確認します。
ドキュメント要件:想定される用途、トレーニングデータ、制限事項など、AIシステムの正式な説明がポリシーで求められているかどうかを確認します。 この情報は通常、Agent Studioで使用されるモデルプロバイダーから入手できます。 ポリシーで求められる開示事項については、プロバイダーのドキュメントを確認してください。
リスク評価:重大なアクションを実行するAIシステムをデプロイする前に、ポリシーでリスク評価が求められているかどうかを確認します。 アクセスをプロビジョニングする、財務リクエストを送信する、または個人に影響するアクションを実行するGenieは、正式なリスク評価要件の対象となる場合があります。
開示義務:AIシステムと対話している個人に対して、その対話がAI製品とのものであることを通知する必要がポリシーで定められているかどうかを判断します。 Chat InterfaceでGenieのAIとしての性質が明確でない場合は、明示的な開示がポリシーで求められているかどうかを確認します。
パフォーマンス監視:AIシステムの動作に関する継続的なパフォーマンス監視と定期レビューがポリシーで求められているかどうかを判断します。
Genieのガバナンス記録を作成する
すべてのプロダクションGenieには、主要なガバナンス上の決定を記録し、監査、コンプライアンスレビュー、AIガバナンスポリシー評価に必要な情報を提供するガバナンス記録が必要です。 このドキュメントを維持し、ガバナンスに関連する設定が変更された場合は更新してください。 ガバナンス記録により、組織はGenieデプロイメントが適切な注意を払って設計され、責任を持って管理されていることを示せます。
完全なガバナンス記録には、以下が含まれます。
- AIガバナンスポリシー
- Genieの名前、目的、想定ユーザー層
- 使用中のAIモデルと、それを選択した根拠
- データレジデンシー設定と、それが該当する要件を満たす方法
- 会話の保持期間と、その根拠
- 該当する規制に関連する、承認済みモデルプロバイダーのドキュメント
- アクセス制御設定。Genieを使用できるユーザー、管理できるユーザー、会話履歴を表示できるユーザーを含みます。
- デプロイメント前に実施されたリスク評価
- AIシステムとの対話についてユーザーに提供された開示
- 監視アプローチとレビューのスケジュール
- 前回のガバナンスレビューの日付と実施者
承認済みAIモデルプロバイダー
規制対象業界でプロダクションGenie用のモデルを選択する前に、AIモデルプロバイダーが組織の該当するコンプライアンスフレームワークで承認されていることを確認します。例:
金融サービス:多くの金融サービス規制当局は、規制対象の活動で使用されるAIシステムについて、適切なデータ処理契約を締結し、インフラストラクチャが指定されたセキュリティ基準を満たすモデルプロバイダーを使用することを求めています。 選択したモデルプロバイダーが、組織と関連する契約を締結しており、該当する基準を満たしていることを確認します。
医療:HIPAAでは、保護対象保健情報を処理するベンダーにBusiness Associate Agreement(BAA)の締結を求めています。 Genieがスキルの出力またはナレッジベースのコンテンツを通じてPHIを直接または間接的に処理する場合、モデルプロバイダーが組織とBAAを締結していることを確認します。 すべてのモデルプロバイダーがBAAを提供しているわけではありません。
政府および公共部門:多くの法域における政府調達フレームワークでは、AIシステムの承認済みベンダーリストまたはセキュリティ認証要件が指定されています。 政府関連のコンテキストでGenieをデプロイする前に、選択したモデルプロバイダーが該当する政府調達要件を満たしていることを確認します。
一般企業:ほとんどの大規模組織には、データ処理契約、セキュリティレビュー、法務承認を含むベンダー承認プロセスがあります。 プロダクションにデプロイする前に、AIモデルプロバイダーが組織のベンダー承認プロセスを完了していることを確認します。
コンプライアンス要件を満たすために、独自のLLMを使用できます。 コンプライアンスフレームワークで承認されたモデルプロバイダーに、Agent Studioでネイティブに利用可能なモデルが含まれていない場合、カスタムOAuthコネクションを通じて、承認済み、セルフホスト、または別途契約済みのモデルに接続できます。
最終更新日: