Agent Studio セキュリティ ​

Agent Studio はロールベースのアクセス、認証済みユーザーアクセス、安全な認証を提供します。詳細については以下のセクションを参照してください。

ロールベースのアクセス制御 ​

Agent Studio はジーニーとナレッジベースに対してロールベースのアクセス制御（RBAC）を提供します。これにより、コラボレーター権限を設定して各ロールの特定のアクセス権限を定義できます。これらの権限には以下へのアクセスが含まれます：

• ジーニーとナレッジベースの管理（表示、編集、作成、削除）
• テストモード
• 会話履歴

ジーニーのアクセス制御には 2 つのアクセスレベルがあります：

• コラボレーターアクセス：ジーニーを構築、編集、管理できる人を管理します。このロールは組織のビルダー、ジーニーオーナー、管理者向けに設計されています。Workato ワークスペースのコラボレーターロールによって制御されます。

• エンドユーザーアクセス：チャットインターフェースを通じてジーニーとやりとりできる人（作業タスクを完了するためにジーニーを使用する従業員やチームメンバー）を管理します。Workato ユーザーグループとその IdP グループマッピングによって制御されます。

例えば、IT ジーニーを編集できるビルダーはコラボレーターです。IT ジーニーにパスワードリセットを依頼できる従業員はエンドユーザーです。これらは別々の設定を持つ別々のロールです。

コラボレーターロール ​

Agent Studio のワークスペースコラボレーターロールは、ビルダーがプラットフォーム内でできることを定義します。ジーニーのデプロイに関連するロールには以下が含まれます：

• Project Admin：ジーニー、スキル、ナレッジベース、アプリイベント、データテーブルを含む、割り当てられたプロジェクト内のすべてのアセットを作成、編集、削除します。特定のジーニーまたはジーニーセットを管理するジーニービルダーの標準ロールです。

• Operator：レシピとジョブ履歴を表示します。このロールはレシピやジーニーの設定を編集できず、監視やデバッグのためにジーニーアクティビティの可視性が必要なチームメンバーに適しています。

• Workspace Owner：すべてのプロジェクトのすべてのアセットへのフルアクセス。このロールは少数のプラットフォーム管理者に限定する必要があります。このロールは個々のジーニービルダーには適していません。

• 会話履歴アクセス：コラボレーターがジーニーの会話ページを表示できるかどうかを制御するコラボレーターロール内の特定の権限です。このロールはデバッグが必要なビルダーと QA が必要なジーニーオーナーに明示的に付与する必要があります。このロールはデフォルトですべてのコラボレーターに付与されません。

• テストモードアクセス：コラボレーターが孤立したテストセッションでジーニーとやりとりするためにテストモードを使用できるかどうかを制御します。ビルダーは通常この権限が必要です。この権限はエンドユーザーには推奨されません。

ジーニーとナレッジベースのコラボレーター権限の詳細を参照してください。

エンドユーザーグループ ​

エンドユーザーグループは、どの従業員が特定のジーニーにアクセスできるかを制御します。各グループは ID プロバイダーの 1 つ以上の IdP グループにマッピングされ、ジーニーのエンドユーザーアクセス設定で 1 つ以上のジーニーに割り当てられます。

エンドユーザーグループはプロジェクト構造とは独立して動作します。つまり、ユーザーグループは異なるプロジェクトのジーニーに割り当てることができます。プロジェクト構造はビルダーのアセットの配置を管理します。ユーザーグループ構造はそれらのビルダーが作成したジーニーを誰が使用できるかを管理します。Workato はユーザーグループをプロジェクト構造に合わせないことを推奨します。

ジーニーのオーディエンスと必要なアクセスレベルに基づいてユーザーグループを設計します。

• シングルティアアクセス：ほとんどのジーニーは、すべての従業員が IT ジーニーを使用できたり、営業チームが営業ジーニーを使用できたりするなど、均一なアクセスで単一のユーザー集団にサービスを提供します。このセットアップではジーニーごとに 1 つのユーザーグループで十分です。

• マルチティアアクセス：一部のジーニーは異なる機能を持つ異なるユーザー集団にサービスを提供します。例えば、HR ジーニーに質問してリクエストを送信できる従業員と、さらにリクエストのレビューと承認ができる HR マネージャーなどです。各アクセスティアに個別のユーザーグループを作成し、各ティアが利用できるスキルとナレッジベースをそれに応じて割り当てます。

• クロスジーニーグループ：IT サポートチームが IT ヘルプデスクジーニーと IT インシデント管理ジーニーの両方へのアクセスを必要とするなど、一部のユーザー集団は複数のジーニーにまたがります。各ジーニーに個別のグループを作成するのではなく、IT サポートチームに単一のユーザーグループを作成して両方のジーニーに割り当てます。

ユーザーグループの命名規則 ​

ユーザーグループの名前は、ユーザー集団とアクセスレベルを反映するよう命名します。曖昧なグループ名は大規模な管理が困難です。

推奨される命名例

• IT ジーニー: 全従業員
• 営業ジーニー: アカウントエグゼクティブ
• HR アシスタント: 全従業員
• HR アシスタント: HR マネージャー

推奨されない命名例

• グループ 1
• ユーザー
• ジーニーアクセス

認証済みユーザーアクセス ​

認証済みユーザーアクセスはランタイムユーザー接続を通じて機能し、ジーニースキルレシピの実行時に各エンドユーザーが独自の認証情報で認証できるようにします。これにより、スキルレシピが個々のユーザーの ID と権限を使用してアクションを実行することが保証されます。この機能は以下の能力を提供します：

• ユーザースコープ接続：ジーニーは実行時に認証してユーザー接続を作成し、Workato Identity の親接続、環境、ユーザー ID にリンクします。
• ジーニーチャットでのキーワード管理：ジーニーはチャットに直接入力できる ! list_connections キーワードをサポートし、ランタイムユーザー接続を管理します。

異なるユーザーグループが異なるスキルにアクセスできるジーニーで、従業員が送信したリクエストをマネージャーが承認できます。これにより、認証済みユーザーアクセスが追加のアクセス差別化レイヤーを提供します。

認証済みユーザーアクセスを使用するスキルは、ターゲットシステムで個々のユーザー自身の認証情報を使用して実行されます。Salesforce のロールで商談フィールドの更新が許可されているマネージャーは、商談更新スキルを実行できます。その更新が許可されていない Salesforce ロールを持つ従業員は、ジーニーでそれを呼び出せても同じスキルを実行できません。

つまり、ターゲットシステム自体の権限モデルが、認証済みユーザーアクセスを使用するスキルの追加のアクセス制御レイヤーになります。Workato でのユーザーグループの割り当ては、ユーザーがアクセスできるジーニーを制御します。接続されたシステムでのユーザーの権限は、それらのジーニーがユーザーに代わって何ができるかを制御します。

安全な認証 ​

ジーニーのアクション、レスポンス、データアクセスは、ビルダーが設定した接続またはエンドユーザーの ID と権限のいずれかに依存します。これにより、セキュリティポリシーへの準拠が確保されます。

Agent Studio のセキュリティは以下の機能を提供します：

• 既存の認証システムとのインテグレーション
• ロールベースのアクセス制御（RBAC）
• すべてのアクションの監査証跡
• 組織のセキュリティポリシーへの準拠

詳細については、Workato Identity を参照してください。

AI ガバナンスポリシー ​

正式な AI ガバナンスポリシーを持つ組織にジーニーをデプロイする前に、デプロイメントがポリシー要件を満たしていることを確認します：

• ドキュメント要件：ポリシーが AI システムの正式な説明（意図する用途、トレーニングデータ、制限を含む）を必要とするかどうかを確認します。この情報は通常、Agent Studio が使用するモデルプロバイダーに関して利用可能です。ポリシーが必要とする開示についてはプロバイダーのドキュメントを確認してください。

• リスク評価：ポリシーが重大なアクションを実行する AI システムのデプロイ前にリスク評価を必要とするかどうかを確認します。アクセスのプロビジョニング、財務リクエストの送信、個人に影響するアクションを実行するジーニーは、正式なリスク評価要件の範囲に含まれる場合があります。

• 開示義務：ポリシーが AI システムとやりとりする個人に、やりとりが AI 製品と行われていることを通知することを必要とするかどうかを判断します。チャットインターフェースがジーニーの AI 性質を明示していない場合は、ポリシーが明示的な開示を必要とするかどうかを確認してください。

• パフォーマンス監視：ポリシーが AI システムの動作の継続的なパフォーマンス監視と定期的なレビューを必要とするかどうかを判断します。

ジーニーのガバナンスレコードを作成する ​

すべての本番ジーニーは、主要なガバナンス決定を記録し、監査、コンプライアンスレビュー、AI ガバナンスポリシー評価に必要な情報を提供するガバナンスレコードを持つ必要があります。このドキュメントを維持し、ガバナンスに関連する設定が変更されたときに更新してください。ガバナンスレコードにより、組織はジーニーのデプロイメントが適切な配慮を持って設計され、責任を持って管理されていることを示すことができます。

完全なガバナンスレコードには以下が含まれます：

• AI ガバナンスポリシー
• ジーニーの名前、目的、対象ユーザー集団
• 使用中の AI モデルとその選択理由
• データ居住設定と適用要件への適合方法
• 会話保持期間とその理由
• 適用法規に関連する承認済みモデルプロバイダーのドキュメント
• ジーニーを使用できる人、管理できる人、会話履歴を表示できる人を含むアクセス制御設定
• デプロイ前に実施したリスク評価
• AI システムとのやりとりに関するユーザーへの開示
• 監視アプローチとレビュースケジュール
• 最後のガバナンスレビューの日付と実施者

承認済み AI モデルプロバイダー ​

規制された業界の本番ジーニーのモデルを選択する前に、組織の適用コンプライアンスフレームワークの下で AI モデルプロバイダーが承認されていることを確認します。例：

• 金融サービス：多くの金融サービス規制当局は、規制対象の活動で使用される AI システムが適切なデータ処理契約を締結し、特定のセキュリティ標準を満たすインフラストラクチャを持つモデルプロバイダーを使用することを要求します。選択したモデルプロバイダーが組織と関連する契約を締結し、適用標準を満たしていることを確認してください。

• 医療：HIPAA は保護された健康情報を処理するベンダーに対してビジネスアソシエイト契約（BAA）の締結を要求します。ジーニーがスキルの出力やナレッジベースのコンテンツを通じて PHI を直接または間接的に処理する場合、モデルプロバイダーが組織と BAA を締結していることを確認してください。すべてのモデルプロバイダーが BAA を提供しているわけではありません。

• 政府および公共部門：多くの管轄区域の政府調達フレームワークでは、AI システムに承認済みベンダーリストまたはセキュリティ認証要件が指定されています。政府のコンテキストにジーニーをデプロイする前に、選択したモデルプロバイダーが適用される政府調達要件を満たしていることを確認してください。

• 一般的なエンタープライズ：ほとんどの大企業では、データ処理契約、セキュリティレビュー、法的承認を含むベンダー承認プロセスがあります。本番環境にデプロイする前に、AI モデルプロバイダーが組織のベンダー承認プロセスを完了していることを確認してください。

コンプライアンス要件を満たすために独自の LLM を使用できます。これにより、Agent Studio でネイティブに利用可能なモデルがコンプライアンスフレームワークの承認済みモデルプロバイダーに含まれていない場合、カスタム OAuth 接続を通じて承認済み、自己ホスト型、または個別に契約したモデルに接続できます。