Oakallow

Oakallow MCP Server

AI エージェントによるツール実行のランタイム権限、承認、監査ガバナンス。

Oakallow はホスト型のリモート MCP サーバーです。エージェントと、エージェントが実行しようとするアクションの間に位置し、実行時に特定のアクションを確認し、リスクがある場合は人間の承認を必須にし、単回使用の署名付きトークンで認可したうえで、改ざん不可能な監査ログに記録できます。

• ウェブサイト： https://oakallow.com
• MCP エンドポイント： https://api.oakallow.io/mcp（Streamable HTTP）
• OAuth 2.1 準拠： https://oakallow.com/docs/oauth
• MCP プロトコルの詳細： https://oakallow.com/docs/mcp

このコネクターの用途

Oakallow は、ほかのコネクターも使用するワークフローにガバナンスのチェックポイントを組み込みます。エージェントは調査作業（たとえば、別のコネクターを通じたアカウントの照会）を行い、推奨事項をまとめたうえで、Oakallow を呼び出してアクションの承認をリクエストします。その後、人間の承認者が、強制される多要素認証のもとで、Oakallow のダッシュボードまたはモバイルアプリから判断します。

このコネクターはリクエスト元かつ中継役であり、判断を下すものではありません。

• ツールの一覧表示、権限の確認、承認のリクエスト、各判断に対する署名付きレシートの返却ができます。また、OakGuard ゲートウェイを通じて接続されたサーバーでは、承認後に呼び出しを転送できます。
• 人間に代わって承認または拒否することはできません。判断はコネクター経由ではなく、MFA が必須の別の画面（ダッシュボード）で行われます。

標準ツール

ツール	用途	読み取り専用
list_my_tools	指定した組織（org 引数。詳細は以下を参照）で、サインインしているユーザーが利用できるツールを列挙します	はい
check_permission	指定したツール呼び出しが許可されるか、承認が必要か、ブロックされるかを確認します（org 引数を指定。詳細は以下を参照）	はい*
list_pending_approvals	人間の判断を待っている承認リクエストを一覧表示します	はい
check_approval_status	参照番号を使って、保留中の承認リクエストの状態を確認します	はい

* check_permission が返すのは読み取り専用の判定のみです。承認や参照番号は作成されません。（承認とその REF-… は、oakallow を通じて制限対象のツール自体を呼び出したときに作成されます。）ただし、設計上の副作用が1つあります。未登録のツールを確認すると、Oakallow はそのツール用の制限対象のドラフト項目を、保守的なフェイルクローズの既定値で自動作成します。これにより、後続の呼び出しがガバナンスの対象となり、所有者はダッシュボードから対応を検討できます。これは意図された動作です。未知のツールが暗黙のうちに信頼されることはありません。

組織の選択

Oakallow アカウントには複数の組織を設定でき、各組織はそれぞれのツール、権限ルール、承認者、アラート経路を定めます。そのため、アクションは正しい組織に対して確認する必要があります。どの組織を指定するかによって、誰に、どのルールに基づいて承認を求めるかが決まるためです。

check_permission と list_my_tools は、省略可能な org 引数を受け取ります。この引数には組織の外部 ID（例：org_oak_…）を指定します。ルールは次のとおりです。

• アカウントに組織が1つある場合： org を省略してください。コネクターは唯一の組織を使用します。
• アカウントに複数の組織がある場合： アクションの対象となる組織を org に指定してください。省略した場合、誤った組織を推測するのではなく、案内とともに呼び出しが拒否されます。

コネクターに組織の一覧表示を依頼することはできません。組織を列挙するツールはありません。代わりに、その組織のダッシュボードから、組織固有のスキルをダウンロードしてください。 各組織のスキルには、その組織 ID が含まれており、エージェントにその ID を渡すよう指示します。利用する組織ごとにスキルを1つインストールしてください。エージェントは対応するスキルを読み取り、すべての呼び出しで正しい org を渡します。

コネクターは、サインインしているユーザーの身元に照らして、指定された org を認可します。実際に操作できる組織（その組織のチームオーナーまたは管理者であるか、その組織の承認者グループに所属している場合）だけを対象にできます。アクセス権のない組織を指定すると、拒否されます。スキルは利便性のためのものであり、アクセス権を付与するものではありません。

ガバナンス管理下のツールを呼び出す

4 つの標準ツールに加えて、tools/list は組織が定義し、承認したツールを返します。oakallow を通じてそのいずれかを呼び出すことで承認が作成されます。「承認をリクエストする」ための別のツールはありません。直接呼び出すツールでは、以下の 2 つの任意の引数に加えて、前述の org を指定できます。

引数	用途
reason	呼び出しの理由を簡潔にまとめた、機密情報を含まない説明です。人間の承認者はこれを読みます。Oakallow は保存前に、SSN、カード番号、メールアドレス、電話番号、住所のパターンをマスキングします。
agent	呼び出し元のエージェントを識別する値（名前、コード、または番号）です。組織のガバナンスレポートでは、すべての呼び出しをサインイン中のアカウントに帰属させるのではなく、どのエージェントが各呼び出しを送信したかを表示するために使用します。同じ値を一貫して送信してください。呼び出し元が oak_agent_ トークンで認証している場合は無視され、そのトークン自体の ID が使われます。

応答は allowed（独自のコネクターでアクションを実行します）、requires_approval（承認リクエストが作成され、check_approval_status でポーリングするための REF-… が返されます）、または disabled（停止してください。ポリシーによりアクションはブロックされています）のいずれかです。

署名付き判定レシート

承認済みツールに対するすべての権限判定では、判定結果が何であっても、署名付き判定レシートが返されます。allowed、requires_approval、disabled のすべてが同じ方法で署名されます。レシートは、判定、ツール、呼び出しパラメーターのハッシュ、テナント、リソース、メソッド、および組織を対象とする HMAC-SHA256 署名であり、後から判定を再検証できるよう保存されます。disabled のレシートは、oakallow がアクションをブロックしたことを証明します。

判定に署名できない、または記録できない場合、oakallow はフェイルクローズします。証明できない判定を返すことはせず、判定結果を返しません。

OakGuard ゲートウェイ

デフォルトでは、oakallow はツールのそばにあるチェックポイントです。判定を行い、実行はあなたが行います。OakGuard を使うと、組織は独自の MCP サーバーを oakallow に登録できるため、oakallow がそれらのサーバーへの通信を担うようになります。

• 下流で OAuth 2.1 が必須です。 サーバーが OAuth 2.1 の必須要件（S256 PKCE を使う認可コードフロー、RFC 9728 と RFC 8414 のディスカバリー、パスワードグラントを使わないこと）を通知していない場合、登録は拒否されます。oakallow はサーバーの OAuth クライアントとして自身を登録し、下流のトークンを暗号化して保持します。
• ツールは、実際の名前とスキーマで tools/list に表示されます。新たに検出されたツールは、管理者が有効にするまで承認を必要とするドラフトとして登録されます。
• 呼び出しは、権限ルールによって許可されるか、人間が承認した後にのみ 転送されます。承認はそれぞれ、下流に一度だけ適用されます。
• ペイロードは通過しますが、保持されません。 oakallow は両方の経路で TLS を介してリクエストとレスポンスを転送しますが、それらを保存またはログに記録しません。レシートと監査ログには判定が記録され、データは記録されません。

サーバーの登録、一時停止、取り消しは、ダッシュボードの「OakGuard」タブから行います。

リソース

oakallow は、読み取り専用の MCP リソースを 2 つ公開します。これらは、エージェント（または クライアント UI）が oakallow 経由でアクションを実行する前に確認できる事前チェック用のシグナルです。どちらも mcp:read スコープが必要ですが、ツール呼び出しではなく、料金も発生しません。

リソース	返される内容	読み取り専用
oakallow://status	サインイン中のセッションにおけるコネクターの稼働状況：ステータス、エンドポイント、サーバーのバージョン、プロトコルのバージョン、付与されたスコープ。読み取りに成功すれば、それ自体がセッションの有効性の証明になります。アカウントの本人確認情報や個人を特定できる情報は返されません。	はい
oakallow://credits	このセッションが解決する組織について、現在、ガバナンス対象の呼び出しに資金を充てられるかどうかを返します。支払い不能な承認を要求する前に、エージェントがすぐに処理を中止できます。	はい

oakallow://credits は呼び出し元自身の請求先組織に限定され、実際のツール呼び出しと同じ方法で組織を解決するため、can_fund: true という結果は、最終的な承認に確実に資金が充てられることを意味します（チームプールへのフォールバックを含みます）。返されるのは can_fund の真偽値と組織名、および外部 ID のみです。残高の数値は意図的に開示されません。 金額はダッシュボードでチームのオーナーにのみ表示され、コネクター経由では決して開示されません。セッションから組織を特定できない場合、または複数の組織が特定された場合は、どの組織に請求されるかを推測せず、理由とともに can_fund: false を返します。

接続

匿名でのアクセスはできません。 接続には oakallow アカウントが必要です。 エンドポイントは 2 種類の認証情報を受け付けます。人間が操作するクライアント向けの対話型 OAuth 2.1（PKCE）と、 自律型エージェント向けの oak_agent_ ベアラートークンです（下記の 自律型エージェントを参照）。

人間が操作する OAuth の手順では、MCP クライアント（Claude、Claude Desktop、Cowork、ChatGPT、または Streamable HTTP 対応の MCP ホスト）に、カスタムコネクターとして https://api.oakallow.io/mcp を追加します。Oakallow へのサインインと、要求されたスコープの承認にリダイレクトされます。

• mcp:read：ツールの一覧表示、保留中の承認の確認、権限の確認、アクティビティの読み取り。
• mcp:write：承認リクエストの作成と実行トークンの発行。

これらを手動で設定する必要はありません。認証されていないリクエストは、エンドポイントの RFC 9728 保護リソースメタデータ （/.well-known/oauth-protected-resource）を示す WWW-Authenticate ヘッダー付きの 401 を返します。そのため、仕様に準拠した MCP クライアントは認可サーバーを検出し、OAuth フローを自動的に実行します。

Claude Desktop の設定、OAuth フローの手順、および oak_agent_ トークンの手順については、examples/ を参照してください。標準ツールの正確なスキーマは tools.json に記載されています。

自律型エージェント（oak_agent_ トークン）

OAuth は、人間が対話型のサインインを完了できることを前提としています。単独で動作する自律型エージェントは、代わりに事前発行されたベアラートークンを使い、同じ https://api.oakallow.io/mcp エンドポイントで認証します。形式は Authorization: Bearer oak_agent_... です。エンドポイントは OAuth プロバイダーより先に oak_agent_ ベアラーを確認するため、同意画面や対話型ログインは必要ありません。

エージェント ID は 1 つの組織に限定され、権限リクエストの送信と確認はできますが、承認はできません。また、ID ごとにレート制限が適用され、SHA-256 ハッシュのみが保存されます（生のトークンが表示されるのは作成時の 1 回のみです）。ダッシュボードの Account → Agents ページから発行してください（オーナー／管理者のみ）。全体の仕組みについては、oakallow.io/info/agents を参照してください。

スキル

SKILL.md は、oakallow ツールを使用するタイミングと方法を説明するエージェントスキルです。リクエスト、承認、ポーリング、実行のワークフロー、承認理由の書き方、および allowed、requires_approval、disabled の判定への対処方法を説明しています。ツールのアクションを適切にガバナンスするため、このファイルをエージェントに参照させてください。

トリガープロンプト

PROMPT.mdには、スキルを参照するようエージェントのシステムプロンプトにそのまま追加できる、短い一行の文が記載されています。スキルは手順であり、トリガープロンプトはエージェントにそれを参照させるものです。「すべてのツール呼び出しを必須にする」ものから「顧客が指定した一連のツールを必須にする」ものまで、3つの選択肢に加え、実際のリクエストで使えるインラインのパターン例もあります。

ガバナンス対象の呼び出しの仕組み

1. エージェントは、認証情報、reason、agent IDを指定して、Oakallow経由でツールを呼び出します。
2. Oakallowは、該当するツール、テナント、リソースに対する権限ルールを解決し、判定を示す署名付きレシートを発行します。
3. アクションが許可された場合、エージェントが実行します。直接ツールの場合はエージェント自身のコネクターで、OakGuardゲートウェイツールの場合はOakallowが転送します。
4. 承認が必要な場合は、承認リクエストが作成され、人間に通知されます。エージェントはポーリング用のREF-…を受け取ります。人間がMFAで承認すると、アクションは1回だけ正確に実行されます。
5. Oakallowは、結果を記録した改ざん不可能な監査行を書き込みます。

直接ツールの場合、Oakallowは実行経路の外部で動作します。報告された内容を管理して記録しますが、ツールを実行することも、PIIを除去したreason以外のツールパラメーターを受け取ることもありません。OakGuardゲートウェイツールの場合、Oakallowは承認済みの呼び出しを転送しますが、ペイロードは保持しません。

MCP以外では、REST API（POST /v1/tokens/mint）を使って、ツールとそのパラメーターをひも付ける、1回限りのHMAC署名付き実行トークンを発行することもできます。バックエンドは実行前にこのトークンを検証できます。

ライセンス

LICENSEを参照してください。

変更履歴

CHANGELOG.mdを参照してください。

---

© Islemonics Studios LLC。特許出願中。