Speedle AI · パターン

AI の構築と運用のためのポリシーパターン

AI システムがデータ、モデル、ツール、他のエージェントと接するあらゆる場面に Speedle の認可エンジンを適用:モデル提供前の構築フェーズ、および提供・動作中の運用フェーズ。これらはソリューションパターンであり、特定の ML やエージェントプラットフォームとの既成連携機能ではありません。

以下の各 SPDL 例は、Speedle ファイルストアを用いてパースされ、許可および拒否ケースに対して評価されています。名称、パス、属性は例示用です。決定を要求する際、アプリケーション側から属性を渡す必要があります。ポリシー執行ポイントは、条件が参照するすべての属性を渡さなければなりません。

構築

モデル提供前:データ、トレーニング、リリース

01 / データとトレーニング

どのパイプラインがどのデータでトレーニングできるか

トレーニングジョブはデータセットを読み取り、コンピュートを使用し、チェックポイントを出力します。アプリケーションは各データセットの読み取り、ジョブ開始、チェックポイントのエクスポート前に、機密性、テナント、同意、地域を属性として渡して問い合わせます。

主体
エンティティとしてのトレーニングパイプライン、ML エンジニアとそのチーム。
リソースとアクション
データセット:read。トレーニングジョブ:start。チェックポイント:export。
執行ポイント
データセットを開く前のデータローダー、コンピュートを割り当てる前のジョブスケジューラ、およびエクスポート前のアーティファクトストア。
training.spdlSPDL 例
[service.ml-training]
[policy]
# Pipelines read only consented data from their own region
grant role training-pipeline read expr:^/datasets/ if consent == true && data_region == job_region
# Restricted datasets never enter training
deny role training-pipeline read expr:^/datasets/restricted/
grant role ml-engineer start /jobs/training if gpu_hours <= 64
grant role ml-engineer export expr:^/checkpoints/
[rolepolicy]
grant entity pipeline-churn training-pipeline
grant group ml-team ml-engineer

データセットごとに同意とリージョンをチェックし、制限付きデータへのアクセスを直接拒否し、ジョブ開始時に GPU 時間制限を適用します。

02 / モデルリリース

誰がモデルをリリースできるか

モデルの登録、承認、プロモート、ロールバックは、別々の担当者が行う独立したアクションです。職務分掌により、モデルをトレーニングした本人がそれを承認することはできません。

主体
ML エンジニア、リリースマネージャー、およびリリースパイプラインのサービス ID。
リソースとアクション
モデルおよびエンドポイント:register、approve、promote、rollback。
執行ポイント
モデルレジストリおよびリリースパイプライン。モデルまたはエンドポイントの状態が変更される前に検証します。
release.spdlSPDL 例
[service.model-registry]
[policy]
grant role ml-engineer register expr:^/models/
grant role release-manager approve, promote, rollback expr:^/models/
# Separation of duties: nobody approves a model they trained
deny role release-manager approve expr:^/models/ if trained_by == request_user
[rolepolicy]
grant group ml-team ml-engineer
grant user dana release-manager

エンジニアは登録できますがプロモートはできません。リリースマネージャーは trained_by がリクエストユーザーであるモデルを承認できません。

運用

AI 提供および動作時:検索、エージェント、ツール、および他のエージェント

03 / 推論と RAG

ユーザーが閲覧可能な情報のみをプロンプトに挿入

ユーザー、アプリ、テナントがモデルを呼び出します。権限を考慮した RAG では、リトリーバーが各ドキュメントまたはコレクションの内容をプロンプトに入れる前に Speedle に問い合わせるため、モデルにはリクエストを行った人物が閲覧可能な情報のみが渡されます。

  1. 1リトリーバーが候補ドキュメントを検索します。
  2. 2ユーザーのテナントとセキュリティクリアランスを添えて、Speedle にドキュメントまたはコレクションごとに問い合わせます。
  3. 3許可されたコンテンツのみがプロンプトに入ります。
主体
リクエストの背後にいるユーザーとそのグループ。エンティティとしてのクライアントアプリケーションとテナント。
リソースとアクション
コレクションおよびドキュメント:retrieve。モデル:invoke。
執行ポイント
ドキュメントがプロンプトに入る前のリトリーバー、およびリクエストをルーティングする前の API ゲートウェイまたは推論サービス。
rag.spdlSPDL 例
[service.rag]
[policy]
# The retriever asks per document, before its content enters the prompt
grant role tenant-user retrieve expr:^/collections/ if doc_tenant == user_tenant && doc_label in user_clearances
# Documents on legal hold never reach a prompt
deny role tenant-user retrieve expr:^/collections/legal-hold/
# Apps call only the model tiers in their tenant's plan
grant role tenant-app invoke expr:^/models/ if model_tier in plan_tiers
[rolepolicy]
grant group acme-staff tenant-user
grant entity acme-helpdesk tenant-app

ドキュメントはユーザーのテナント内で、かつユーザーに許可されたラベルでのみ取得されます。リーガルホールド対象は拒否され、アプリはプラン内のモデルティアのみを呼び出せます。

04 / ユーザーを代理するエージェント

AI エージェントはユーザーを代理して何ができるか

エージェントは独自のアイデンティティを持ち、ユーザーの委任はリクエスト内の自己申告ではなく署名済み委任トークンによって証明されます。執行ポイントはトークンを検証後、Speedle に2回問い合わせ、両方が合格した場合のみ許可します:トークンのスコープ内のエージェント、および現時点における委任ユーザー自身の権限。トークン発行後にユーザーが権限を失った場合、エージェントは次のリクエストで即座にその権限を失います。100 を超える払い戻しには、ユーザー以外の人物による承認記録も必要です。

  1. 1トークンの検証:署名、発行者、有効期限、およびこのエージェント宛に発行されたことを確認。
  2. 2エージェントスコープ:エージェントを主体、トークンのスコープを属性として Speedle に問い合わせ。
  3. 3委任元の最新権限:トークンの sub クレームで指定された委任ユーザーを主体として Speedle に問い合わせ。
主体
スコープ検証用エンティティとしてのエージェント。第2検証用の検証済みトークンから取得した委任ユーザー。
リソースとアクション
チケット:read、update。注文:refund(金額を属性として付与)。すべてトークンスコープ内のアクションとリソースに限定。
執行ポイント
アクションが基幹システムに到達する前のエージェントランタイムまたはアプリケーションバックエンド。トークンを検証し、検証済みクレームのみを Speedle に渡します。
人間による承認
執行ポイントは払い戻しの署名済み承認記録を検証し、第2チェックで承認者を approved_by として渡します。承認者はユーザー自身であってはなりません。
セルフホストでの選択肢
カスタム関数 DelegationValid および DelegatorAllowed を使用してトークンと委任者を一度に評価する単一チェック。Speedle Cloud はカスタム関数を実行しません。
agents.spdlSPDL 例
[service.crm]
[policy]
# Check 1: the agent, only while its verified token covers the request
grant role in-scope read, update expr:^/tickets/
grant role in-scope refund expr:^/orders/
# Check 2: the delegating user (the token's sub), with their roles now
grant role support read, update expr:^/tickets/
grant role support refund expr:^/orders/ if amount <= 100
# Larger refunds: a verified approval by someone other than the user
grant role support refund expr:^/orders/ if approved_by != request_user
[rolepolicy]
# Check 1 in three steps, each role needing the one before:
# the token has not expired,
grant entity triage-agent in-time if request_time < token_expires
# it lists this action,
grant role in-time in-action if request_action in token_actions
# and it lists this resource
grant role in-action in-scope if request_resource in token_resources
# Check 2: the user's own role
grant user alice support

第1チェックはエージェントに3段階でロールを付与し、トークン有効期限内かつ指定されたアクションとリソースに限定します。第2チェックはユーザー自身を検証するため、ユーザーのロールが剥奪されるとエージェントも拒否されます。100 を超える払い戻しは、ユーザー以外の承認者が必要です。

GitHub で両パターンの実行可能サンプルを見る

05 / ツール呼び出し (MCP)

AI エージェントはこの引数でこの MCP ツールを呼び出せるか

すべてのツール呼び出しは実行前に検証されます。ツールがリソース、呼び出しがアクション、引数が属性となり、払い戻し金額の上限などの制約がポリシーの一部となります。

主体
エージェント。それぞれが独自のエンティティ ID とロールを持ち、特権はエージェントごとおよびツールごとに厳格に制限されます。
リソースとアクション
ツール:call(ツールの引数を属性として付加)。
執行ポイント
ツールが実行される前の MCP クライアントホスト、または MCP サーバーの手前にあるゲートウェイ。
mcp.spdlSPDL 例
[service.mcp-gateway]
[policy]
# Tool arguments arrive as attributes and are checked before the tool runs
grant role research-agent call /tools/web-search
grant role billing-agent call /tools/issue-refund if amount <= 100 && customer_verified == true
# Admin tools stay out of reach for research agents
deny role research-agent call expr:^/tools/admin/
[rolepolicy]
grant entity agent-research-1 research-agent
grant entity agent-billing-1 billing-agent

リサーチエージェントへの Web 検索許可、認証済み顧客に対する請求エージェントへの 100 以下の払い戻し許可、およびリサーチエージェントに対する管理者ツールの明示的拒否。

06 / エージェント間呼び出し (A2A)

どのエージェントがどのエージェントを呼び出せるか

委任チェーン内の各ホップが検証されます。被呼出側は呼出側が既に保持しているスコープのみを受け取ることができ、ホップ数制限も適用されるため、委任によって権限が拡大することはありません。

主体
エンティティとして識別される呼出側エージェント。
リソースとアクション
他のエージェントとそのスキル:call(要求されたスコープ、呼出側のスコープ、ホップ数を属性として付加)。
執行ポイント
タスクを送信する前の呼出側エージェント、またはタスクを受信する前の受取側エージェント。アプリケーションは受け取った委任から呼出側のスコープを導出します。
a2a.spdlSPDL 例
[service.a2a]
[policy]
# A callee gets only scopes the caller already holds, within two hops
grant role planner-agent call /agents/researcher if IsSubSet(requested_scopes, caller_scopes) && hops <= 2
grant role researcher-agent call /agents/writer if IsSubSet(requested_scopes, caller_scopes) && hops <= 2
[rolepolicy]
grant entity planner-1 planner-agent
grant entity researcher-1 researcher-agent

IsSubSet は呼出側が保持していない要求スコープをすべて拒否し、3ホップ目は遮断されます。

07 / 常設特権ゼロ · セルフホスト

ジャストインタイムトークンが常設特権ゼロパターンを支える

適切な発行および管理条件のもとで、短寿命かつ限定スコープのジャストインタイム認証情報と、Speedle のポリシー決定およびアプリケーション側の執行を組み合わせることで、常設特権ゼロパターンを実現できます。この例ではトークンの有効期間、発効前時間、未使用状態を検証します。本番環境には信頼できるコンポーネントも必要であり、トークンの検証、主体・リソース・アクション・タスクスコープへのクレームのバインド、および使い捨て認証情報のアトミックな消費が求められます。

zsp.spdlSPDL 例
[service.zsp]
[policy]
# A just-in-time token: positive lifetime up to 600 s, inside its validity window, unused
# request_time defaults to the ADS clock; attributes passed by the enforcement point take precedence
# 60 s is the explicit clock-skew allowance
grant role agent-runtime invoke /api/orders if expires_at > issued_at && expires_at - issued_at <= 600 && issued_at <= request_time + 60 && not_before <= request_time + 60 && request_time < expires_at && TokenUnused(token_id)
[rolepolicy]
grant entity agent-billing-1 agent-runtime

GitHub で完全な実行可能サンプルを見る

パート 01計画中

AI リスク検出の目標フロー

このアプローチは現在構想および開発段階であり、未リリースです。確定的なポリシー決定の上にさらなる精査を加えるものであり、リスクシグナルによってポリシーの拒否が許可に変わることはありません。

目標フローの概念設計

ポリシー優先、リスクシグナルは2次。拒否権を維持

計画中
  1. 01 / リクエスト

    操作内容の提示

    エージェント、ユーザー、データ、アクション、タスクコンテキストによってリクエストが構成されます。

    実行前
  2. 02 / ポリシー決定

    確定的境界の適用

    ポリシーが厳密な決定を下します。拒否の場合はここで停止し、許可された場合のみ次に進みます。

    拒否権 · 拒否は最終決定
  3. 03 / AI リスクシグナル

    より広範な関係性の精査

    構築中のアプローチでは、より多くの次元や関連性からさらなるリスクを検出します。

    計画中
  4. 04 / 最終決定

    保護の追加のみで権限は拡大しない

    リスクシグナルは監視や保護を追加できますが、ポリシーによる決定とその拒否権は保持されます。

    ポリシーの拒否権を維持

リスクシグナルによってポリシーの拒否が許可に変わることはありません。この図は構築中のアプローチを示すものであり、リリース済みの AI リスク検出機能を表すものではありません。

Speedle AI 日本語ホームに戻る