WireCanal の最重要レイヤが転送先の固定です。エージェントは、設定した転送先（既定はループバック）以外へは絶対に接続しません。だからトンネルが社内のオープンプロキシと化して、ほかのシステムへの通り道に使い回される、という事故を構造的に防ぎます。
「オープンプロキシ化しないこと」を、毎リリースの自動テストで必ず証明します（CI の必須ゲート）。設計思想を口約束で終わらせず、リリースのたびに機械で確かめ続けます。
WireCanal の公開入口（Edge）は、正規の呼び出し元の固定 IP からのアクセスだけに限定できます。公開エンドポイントでありながら、実質は専用線。さらに呼び出し元の認証（トークン／証明書）が重なり、二重に守られます。「公開しているのに、公開していないに等しい」入口です。
WireCanal は「fail-closed（迷ったら閉じる）」を前提に、9 層の多層防御で設計されています。
enrollment token（初回）→ クライアント認証で、正規の Agent だけを接続。
テナントごとに専用サブドメイン・ID で構造的に分離。
呼び出し元 → Edge は必ず認証。発信元IPが固定なら入口を専用に絞れる。
WireCanal は認証を終端せず素通し。社内システム自身がリソースサーバー。
公開するMCPツール・HTTPパスは社内 Agent がホワイトリストで管理。
Agent は許可された1宛先のみに接続。接続先を構造的に固定する中核レイヤ。
全リクエストを両端に記録。ハッシュチェーンで完全性を担保。
レート/サイズ制限・多段タイムアウト。管理者はいつでも全切断。
高リスク運用向けには、セッション単位の人手承認を組み込む拡張のご相談に応じます（エンタープライズ）。
canal ごとに、公開側の入口へ 8 種類のアクセス保護をかけられます。全プランで全種類を開放しています。設定はダッシュボードの「アクセス保護」タブから（接続元／認証／公開範囲／防御動作の 4 分類）。
判定できない状況（国が特定できない接続元・設定の形式不正など）は、すべて安全側＝「閉じる」方向に倒します。保護の執行点は 443 終端の直後（canal-gate）で、TCP canal では accept 時に接続元 IP を照合して非許可は即座に切断します。
Claude や ChatGPT などの AI サービスは、リモート MCP サーバーへの接続にOAuth による認証を要求します。 WireCanal はMCP Authorization 仕様（Model Context Protocol の認可仕様）に準拠した認可サーバーを内蔵しており、 canal を作って使う AI を選ぶだけで、標準どおりの認証つき MCP エンドポイントが手に入ります。 OAuth サーバーを自前で建てる必要はありません。Claude / ChatGPT / Grok の実際の画面で接続と動作を確認済みです。
WireCanalclient_secret_post）。リダイレクト先は登録済みの URL だけを受け付けます。接続の許可は canal のオーナーが同意画面で明示的に行い、いつでも取り消せます。OAuth はあくまで「入口の認証」。どのツールを見せるかの許可台帳は、これまでどおりお手元のwirecanal.jsonが握ります（two-key）。ダッシュボードから編集する場合も「提案」止まりで、反映には社内での承認操作が必要です（AI に見せるツールを選ぶに実際の画面つきの解説があります）。詳しくはMCP・AI 連携のページをご覧ください。
アクセスログ：canal ごとに、到達したアクセスをプランに応じて直近 1,000 件（プレミアム / エンタープライズは 10,000 件）までダッシュボード（および公開 API）で確認できます。誰が・いつ・どこから来たかを、あとから追えます。ステルスモード時でも、所有者にはログ上で本来の遮断理由がそのまま記録されます。一覧は CSV でダウンロードでき、手元での集計・保管にも使えます。
認証の透過：WireCanal は認証を終端しません。社内システム自身がリソースサーバーであり続け、認証に使ったAuthorizationヘッダは転送先へ流しません。だから「WireCanal を通したせいで認証が二重になる／すり抜ける」といったことが起きません。
AI（MCP）が・いつ・どのツールを呼んだかの行動監査（改竄検出つき）については、MCP・AI 連携のページをご覧ください。