社外 SaaS の AI に社内システムを操作させたい。その通り道を、社内のセキュリティを一切緩めずに用意するのが canal です。
社内データに AI を活かすには、社外SaaSのために受信経路を開けるか、オンプレでGPUを揃えて自前のLLMを運用するか。どちらも準備と運用の負担が大きい選択でした。
社内に置いた Agent が、自分から外へ常時トンネルを張る。受信経路もVPNもGPUも要らず、Bestllam の先端AIへ接続。許可するツールと宛先は、すべて自社が握ります。
社内データに AI を活かすために必要とされてきた重い前提を、canal はまとめて不要にします。
開けるポートはひとつもなし。Agent が社内から外向きに繋ぐだけ。DMZ もポート開放申請も固定IPも要りません。入口は Bestllam の固定IPだけに限定できます。
拠点間 VPN も専用線も不要。認証された 1 本のトンネルが、許可した口だけを通します。動的IP・複数拠点・回線変更があっても繋がり、VPN の構築・運用から解放されます。
GPU サーバーを自前で構築・運用する必要はありません。GPT-5.5・Claude Opus 4.8・Gemini 3.1 Pro といった先端クラウドAIを、社内システムにそのまま接続できます。
Bestllam からは「ただの MCP サーバーURL」に見える公開窓口へ。その先は社内から張った常時トンネルを通って社内システムに届き、同じ道を結果が戻ります。社内側の Agent が外向きに接続を張るだけなので、受信穴は開きません。

canal は多層防御(9層)と「fail-closed(迷ったら閉じる)」を前提に設計されています。中でも要がegress 固定、そして入口を絞る送信元IP制限です。
canal の公開入口(Edge)は、正規の呼び出し元である Bestllam の固定IPからのアクセスだけに限定できます。公開エンドポイントでありながら、実質は Bestllam 専用線。さらに caller 認証(トークン/証明書)が重なり、二重に守られます。「公開しているのに、公開していないに等しい」入口です。

enrollment token(初回)→ クライアント認証で、正規の Agent だけを接続。
テナントごとに専用サブドメイン・ID で構造的に分離。
Bestllam → Edge は必ず認証。発信元IPは固定なので入口を Bestllam 専用に絞れる。
canal は認証を終端せず素通し。社内 MCP 自身がリソースサーバー。
公開するツールは社内 Agent がホワイトリストで管理。
Agent は許可された1宛先のみに接続。接続先を構造的に固定する中核レイヤ。
全リクエストを両端に記録。ハッシュチェーンで完全性を担保。
レート/サイズ制限・多段タイムアウト。管理者はいつでも全切断。
高リスク運用向けに、セッション単位の人手承認を挟める。
社内に「売上DBを検索する MCP サーバー」があれば、Bestllam の AI にこう聞くだけ。
