slug: vinkius-enterprise-ai-questions category: enterprise-ai tags: ["enterprise-ai", "security", "governance", "qa", "isolation", "audit"] date: 2026-09-22 hero: src: /post/hero-enterprise-qa.svg alt: "VinkiusのエンタープライズAI質問回答サーフェス: セキュリティ、財務、プラットフォームチームからの12の厄介な質問。それぞれ特定の強制サーフェスで回答される: V8サンドボックス、サーキットブレーカー、ハッシュチェーン、ケイパビリティロックファイル、検疫スイッチ。"

エンタープライズAI質問: Vinkiusに対する12の厄介な質問とコードレベルの回答

企業はAIエージェントが仕事のやり方を変えるかどうかではなく、Vinkiusが生き残り得るかどうかを問うている。それは、セキュリティチーム、財務チーム、プラットフォームチームがそれぞれ、このプラットフォムが本番トラフィックを実行する信頼をどのように獲得するかを説明を求める会議の会話だ。

私はこれらの質問に、役員会議、セキュリティの戦室、そして各プロジェクトに続く静かなメールスレッドで答えてきた。これは統合されたバージョンである。以下の各回答は、ソースファイル、行番号、そして強制メカニズムを名前を挙げる。スライドデッキに書かれたポリシーではない。各コントロールは関数呼び出し、ソースコード中的常量、またはエージェントが結果を見る前にランタイムがチェックするRedisキーである。

あなたが部屋の前に立って、ツールアクセスを持つ非決定論的主体が社内ネットワーク内で実行される理由を説明しなければならない人であれば、これは話している間に開いておくべきリファレンスである。

---

分離の境界

Q1: 私たちのAIエージェントがサンドボックスから脱し、社内ネットワークに到達することはないというのはどのように証明できますか？

エージェントは、お客様が所有するマシンで実行されることはない。すべてのツール呼び出しは、isolated-vmによって作成された新しいV8アイソレート内で実行される。このライブラリはV8エンジンをNode.jsの外に埋め込み、ホストプロセスへのブリッジを提供しない。明示的に注入しない限りは、アイソレートはホストからブリッジを受け取らない。アイソレートが受け取るのは、私たちが選択して公開するpolyfillsのグローバルだけである。processも、requireも、fsも、fetchもguestの視点からは存在しない。

メモリ上限は固定の常量である。Limits.ts:36はISOLATE_MEMORY_LIMIT_MB = 128を定義する。IsolateRunner.ts:117でコンストラクタはthis.memoryLimit = options.memoryLimit ?? 128を設定し、IsolateRunner.ts:143でnew ivm.Isolate({ memoryLimit: this.memoryLimit })としてアイソレートを作成する。guestが128MBに達すると、V8は計算を終了させるRangeErrorをスローする。これを超える方法はない。

IsolateRunner.ts:132のブートシーケンスは、正確に何がブリッジされるかを示す。ステップ1から12では、ホストから委譲されたプリミティブのみを注入する: consoleブリッジ、timerブリッジ、cryptoブリッジ(getRandomValues)、fetchブリッジ(SSRFガードを通過)、digestブリッジ(SHA-256, SHA-384, SHA-512)、HMACブリッジ(JWT HS256用)、MCP transportブリッジ。生のネットワークソケットは決してguestに渡されない。IsolateRunner.ts:164-183のインターセプターはバンドルからツール定義をキャプチャし、それをホストに返すが、guestは任意のホスト関数を呼び出すことはできない。

SnapshotCache.ts:19のsnapshotは、V8に到達する前にSHA-256で検証される。破損したり改変されたsnapshotは、SnapshotCache.ts:70-71で削除される。

この分離境界の背後にある完全なruntimeアーキテクチャについては、AI Agents Are the New Consumers と How V8 Isolates Power the Vinkius Runtime を参照。

Q2: エージェントが社内サービスを呼び出そうとした場合、何がそれを止めるのですか？

アイソレートからのすべての外向きHTTP呼び出しは、1つの関数を通過する: SsrfGuard.ts:163のsafeFetch。他の出口は存在しない。guestはfetchを呼び出すことができるが、IsolateRunner.ts:161のブリッジがこれをこの関数に専属でルーティングする。

SSRF防御は3つの層を持ち、すべてSsrfGuard.ts内で実装されている:

第一に、宛先の検証。SsrfGuard.ts:27はPRIVATE_RANGESを定義し、127/8、10/8、172.16 to 172.31/12、192.168/16、169.254/16、0/8、およびIPv6の対応物(::1, fc00, fe80)に一致するregexパターンのリストである。接続が許可される前に、すべての解決されたアドレスはこのリストに対してテストされる。

第二に、IPの固定と結合。SsrfGuard.ts:50はDNS_CACHE_MAX_ENTRIES = 4_096を設定する。キャッシュの寿命は、Limits.ts:46のundiciのkeep-aliveソケットの寿命、AGENT_KEEP_ALIVE_TIMEOUT_MS = 65_000と結合されている。検証されたアドレスは、固定を正当化した接続ポリシーの命綱を超えることはできない。これにより、攻撃者が解決と接続の間にAレコードを入れ替えるDNSリバインディング攻撃を防ぐことができる。

第三に、SsrfGuard.ts:110-113のundiciカスタムlookupは、TLSハンドシェイクの前にDNSをIPに解決し、次に同じIPをservernameとして渡して、SNIを実際に接続するホストと一致させる。接続は、プールされたソケットの寿命の間、解決されたIPに固定される。

Q3: ツールがそのレスポンスを通じて機密データを漏洩することを防ぐのは何ですか？

データのクリーニングはResponseGuard.tsで行われ、ホストプロセス内で完全に実行される。V8アイソレート内ではない。ResponseGuard.ts:4のコメントは、セキュリティ境界を明示的に述べている: upstreamデータとエージェント出力の間のマスキング。

このガードはToolExecutionPipeline.ts:422の実行パイプラインのステージ6である。パイプラインステージは以下の順序である: (1) ToolExecutionPipeline.ts:380のクォータ適用、(2) ToolExecutionPipeline.ts:392のハンドラ実行、(3) ToolExecutionPipeline.ts:396のレスポンス正規化、(4) ToolExecutionPipeline.ts:401のFinOpsトランケーション、(5) ToolExecutionPipeline.ts:408のコンパクテーション、(6) ToolExecutionPipeline.ts:422のDLP、(7) ToolExecutionPipeline.ts:426のツールエラー検出、(8) ToolExecutionPipeline.ts:448のテレメトリ。

ResponseGuard.ts:54-57では、ガードは入力パターンを2つのカテゴリに分割する。*.emailのようなパターンは、フィールド名(例:email)に抽出され、レスポンスツリー内の各オブジェクトに対して個別に適用される。これはPresenterパイプラインのstepRedactと同じパターンである。user.ssnのようなパターンは、元のパスを使用し、fast-redactでコンパイルされて、トップレベルの明示的一致を行う。

検閲値は[REDACTED] (ResponseGuard.ts:108-116)。redaction中にエラーが発生した場合、ResponseGuard.ts:177は{ error: '[REDACTED]: DLP redaction failed' }を返す、部分的なデータが漏洩することはない。

すべてのredactionはResponseGuard.ts:122-128でカウントされ、属性付けられる。これにより、AIガバナンスダッシュボードは、どのコネクタがどのredactionをトリガーし、何回行われたかを示すことができる。

Q4: コンプロミスまたはバグのあるコネクタが、同じランタイムで実行中の他のコネクタに影響を与えることはありますか？

いいえ。各接続トークンは独自のアイソレート、独自の資格情報マップ、独自のライフサイクルを取得する。IsolateLifecycle.ts:34は、各トークンが独自の注入された資格情報を持つ独自のIsolateRunnerを取得することを不変条件としている。トークン間で共有されることはない。

IsolateLifecycle.ts:96-104の資格情報注入は、復号化されたサーバー資格情報と呼び出し元の接続トークンをマージするが、vk_live_プレフィックスのトークンのみが注入される。IsolateLifecycle.ts:32はCONNECTION_TOKEN_PREFIX = 'vk_live_'を定義している。

IsolateLifecycle.ts:124-136の高速パスは、スナップショットからアイソレートを復元するが、IsolateLifecycle.ts:62-64の再注入は、ランナーが返される前に資格情報マップを再設定する。アクティブなアイソレートは1回のリクエストを超えて生存する。Legacy SSEは、そのセッション全体で保持し、stateful POSTはそのセッションが開いている間再利用できる。しかし、接続トークンをまだ解決していなかったパスによってブートされている可能性がある。injectSecrets上のフィンガープリントガードは、マップがすでに最新である場合にこれがno-opであることを保証する。

Q5: Vinkiusはどのように支出限界を強制し、それを超えた場合はどうなりますか？

CircuitBreaker.ts:22のサーキットブレーカーは、パイプライン内の最初のチェックとして実行される。Redisに保存されたスライディングウィンドウカウンタである。設定オブジェクトは、サーバー設定からwindow_minutes、max_requests、cooldown_minutesを提供する。

CircuitBreaker.ts:48-56で、カウンタはcb:window:{scopeId}:{windowKey}というスコープのキーにINCRでインクリメントされる。WindowキーはCircuitBreaker.ts:50のMath.floor(Date.now() / 1000 / windowSeconds)から導出され、ウィンドウは決定論的に進み、自動的にリセットされる。

カウントがmax_requestsを超えると、CircuitBreaker.ts:60-62のブレーカーはSETEXでクールダウン期間のcb:tripped:{scopeId}を書き込み、スイッチをオンにする。エラーメッセージは意図的にハードコードされている:

[SYSTEM] CRITICAL: Financial budget ceiling exceeded.
Your account's circuit breaker has tripped to protect your budget.
DO NOT RETRY this request.

これは意図的にリトライ不可のエラーである。429レートリミットとは異なり、クライアントがバックオフでリトライするものではない。サーキットブレーカーは、エージェントに停止し、ユーザーにプランを確認するよう指示する。このメッセージは、エージェントがプロンプトのコンテキストで確認できるように、ツールレスポンスに注入される。

QuotaEnforcer.ts:27は、コンストラクタでサーキットブレーカーを構築し、QuotaEnforcer.ts:48でthis.circuitBreaker.check(config)を呼び出す。クォータロジックが実行される前に。

Q6: 合法的なトラフィックをブロックすることなく、超過料金をどのように処理しますか？

クォータモデルはQuotaEnforcer.ts:154-246でプランによって分岐する:

Marketplaceサブスクリプション (コネクタあたり1席の企業プラン)は、契約されたサブスクリプション上限でハードブロックされる。QuotaEnforcer.ts:163はDECRでカウンタをデクリメントし、QuotaEnforcer.ts:168でSUBSCRIPTION QUOTA EXCEEDEDエラーを返す。

無料プランは、超過オプションなしでハードブロックされる。QuotaEnforcer.ts:186-188はカウンタをデクリメントし、QuotaEnforcer.ts:205でアップグレードリンク付きのREQUEST BLOCKED: QUOTA EXCEEDEDを返す。

有料プランは、クォータに対してハードブロックされることはない。QuotaEnforcer.ts:246はリクエストを許可する。超過料金はQuotaEnforcer.ts:236-243でトリガーされる。newCountがquota.limitを超えた場合、超過金額はnewAmount = newCount - quota.limitとして計算され、creditSlot = Math.ceil(overAmount / 10_000)。スロットが10Kの境界を超えると、QuotaEnforcer.ts:242でfire-and-forgetでtriggerOverageChargeが発火する。請求コールは決してリクエストをブロックしない。

クォータキーのTTLはQuotaEnforcer.ts:15でQUOTA_KEY_TTL_SECONDS = 31 * 24 * 60 * 60(31日)、任意の30日請求サイクルをカバーする。QuotaEnforcer.ts:88-100のINCRリトライループは、指数バックオフ[0, 50, 150]msで最大3回リトライする。

Q7: コネクタが悪意を持ったり、コンプロミスされた場合に利用できる非常脱はありますか？

3つのレベルのキルスイッチが存在する。それぞれ異なるスコープで動作する。

Tier 1: サーバー・クランチネーロ in SoarController.php:50 POST /servers/{server}/soar/kill. Redisにmcp:quarantine:{id}を3600秒のTTLで設定する。すべての3つのトランスポートルートは、このキーをチェックし、legacySse.ts:63、mcpEndpoint.ts:257、streamableHttp.ts:101で403を返す。

Tier 2: サーバー・エマージェンシーハルト in ServerLifecycleController.php:72-100. サーバーを非アクティブ化し、ALLトークンをrevokeする(revoked_at = now, revoked_by = 'server_halt', is_enabled = false at lines 81-86)、Redis pub/subでmcp:kill-serverとmcp:invalidateをブロードキャストする(line 89)。EU AI Act 第14条準拠。

Tier 3: 組織レベル・グローバルハルト in Organization.php:645-666. global_halt_atとglobal_halt_by列をアクティベートし、ランタイムが各リクエストでチェックする。

ランタイム側はserver.ts:96-103でこれらのシグナルを受信する。mcp:kill-serverチャンネルはConnectionTracker.ts:158-194をトリガーし、すべてのSSE接続を終了し、V8アイソレートを解放し、Redisキャッシュエントリをクリアする。

ガバナンス記事のFAQのサーキットブレーカーの質問では、ユーザー向けの動作が説明されている。SOAR統合を含む完全なインシデント対応プレイブックは、その記事のFAQセクションにある。

Q8: 制御不能なエージェントが何千もの同時セッションを開くのを防ぐのは何ですか？

セッション層は、トークンごとにハードリミットを強制する。SessionManager.ts:44はMAX_SESSIONS_PER_TOKEN = 50を定義する。SessionManager.ts:171で次のチェックが実行される: if (meta.token === token && ++count >= MAX_SESSIONS_PER_TOKEN)。51番目の同時セッションは拒否される。

セッションはSESSION_SWEEP_INTERVAL_MS = 15_000(SessionManager.ts:43)によって15秒ごとにスワイープされる。通常のアイドルセッションはSESSION_IDLE_TIMEOUT_MS = 120_000(2分)後にタイムアウトする。メモリプレッシャー時、タイムアウトはSESSION_PRESSURE_TIMEOUT_MS = 30_000(30秒)に短縮される。

Redis内の各セッションエントリはREDIS_SESSION_TTL = 150(2.5分)を取得する。SessionManager.ts:120のアイドルタイムアウトと一致する。SessionManager.ts:89のスワイープはまた、メモリ閾値も強制する: MEMORY_WARN_THRESHOLD = 0.65(65%)で警告を開始し、MEMORY_PRESSURE_THRESHOLD = 0.80(80%)で積極的な2レベルのエビクションをトリガーする。

セッション-to-トークンのマッピングはRedis内のSessionManager.ts:155-163に保存されているため、ランタイムの任意のインスタンスはセッションを解決または拒否できる。これは、水平スケーリングが機能することを意味する。複数のランタイムインスタンスを実行できますが、セッションリミットはフロー全体で大幅に強制される。

100の同時エージェントがセッションを共有するSwarmGatewayレベルのセッション結合メカニズムについては、SwarmGatewayセッション記事を参照。

Q9: 負荷下でエージェントはタイムアウトしませんか？ ガバナンスパイプラインの実際のレイテンシオーバーヘッドは何ですか？

パイプラインは、オーバーヘッドが上流APIのレイテンシではなく、レスポンスサイズに比例するように設計されている。ToolExecutionPipeline.ts:392の生のハンドラ実行は、パイプラインステージから個別にタイムされた。

寒いパスはスナップショットを使用する。IsolateLifecycle.ts:124-136は、まず高速パスを試行する: IsolateRunner.ts:247のbootFromSnapshotは、polyfillsがプリロードされたキャッシュされたスナップショットからアイソレートを作成する。約3から5ミリ秒と文書化されている。IsolateLifecycle.ts:123のコメントは、スナップショットキャッシュが、後続の起動を約15から25ミリ秒で高速化することを述べている。デプロイあたり最初のブートのみが、IsolateLifecycle.ts:138の低速パスを支払う。これは、約50から100ミリ秒で完全なIIFEバンドルを実行する。

BOOT_TIME_BUDGET_MS = 5_000(Limits.ts:33)では、ブートタイムアウトは観測されたレイテンシに対して富裕に設定されている。DISPATCH_TIME_BUDGET_MS = 30_000(Limits.ts:26)では、ディスパッチの上限は、上流APIのレイテンシの長い尾をカバーする。TimeoutClassifier.ts:53の関数は、UPSTREAM_TIMEOUT、COMPUTE_TIMEOUT、MEMORYのエラーを区別する。遅い外部APIがゲストバンドルのせいではない。

マニフェストサーバーはstreamableHttp.ts:66-69でinitialize、tools/list、prompts/listを、V8ブートのオーバーヘッドゼロで提供する:フレームワークコストのない生のMCP SDKハンドラー。tools/callとprompts/getのみが完全なパイプラインに到達する。

接続は、undiciのkeep-aliveでプール化される。Limits.ts:46はAGENT_KEEP_ALIVE_TIMEOUT_MS = 65_000を設定し、これは、ALBの標準的な60秒アイドルウィンドウをわずかに上回っている。Limits.ts:49はAGENT_POOL_MAX = 100を、同時プールアウトバウンドエージェントのハードリミットとして設定する。

Q10: 私たちの接続トークンが他人に使われていないかを確認するにはどうすればよいですか？

トークンは、ランタイムキャッシュ内のraw値として保存されたり、検索されることはない。ProxyRegistry.ts:385-406では、無効化関数はプレーンテキストトークンとトークンハッシュの両方を受け入れる。ランタイムにはAPP_KEYがなく、Redisキャッシュを直接アドレス指定できない。キャッシュ無効化は、ランタイムではなく、Laravelからpub/sub経由で流れてくる。これは意図的なアーキテクチャ上の制約:ランタイムは純粋な受信者である。

ProxyRegistry.ts:200-218のトークン解決は、呼び出し元の接続トークンをLaravel APIに照らして解決し、結果をTTL付きでキャッシュする。ProxyRegistry.ts:385のinvalidate関数は、直接トークンとHMACハッシュの両方の取り消しをサポートする。Laravelは、pub/subを通じてrawトークンを送信することなく、トークンIDハッシュで無効化できる。

ConnectionTracker.ts:19はIDLE_TIMEOUT_MS = 30 * 60_000(30分)を、LRUスワイープのアイドルタイムアウトとして設定する。ConnectionTracker.ts:356-394は、2レベルのエビクションを実行する:通常のアイドル状態は30分、メモリプレッシャーはTASK_MEMORYの75%(デフォルト1GB)である。

Q11: デプロイ間でケイパビリティサーフェスが変更されていないことをどのように検証しますか？

mcpfusion.lockファイルは、コネクタの行動的サーフェス全体の信憑性のある情報源である。CapabilityLockfile.ts:54はLOCKFILE_VERSION = 1を定義し、CapabilityLockfile.ts:57はLOCKFILE_NAME = 'mcpfusion.lock'を設定する。

CapabilityLockfile.ts:256-313では、generateLockfile()は、すべてのツール、プロンプト、リソース、インポート、およびモジュール依存関係の、決定論的なコンパイル時スナップショットを生成する。各LockfileToolは、CapabilityLockfile.ts:100-111で、ツールごとにentitlements(filesystem, network, subprocess, crypto, codeEvaluation)とcognitiveGuardarounds(agentLimitMax, egressMaxBytes)を宣言し、CapabilityLockfile.ts:140-143で設定する。

CapabilityLockfile.ts:388のcheckLockfile()はCIゲートである。高速パスは整合性ダイジェストの一致をチェックする。遅いパスはCapabilityLockfile.ts:404-484で、各ツールの比較を行い、各変更をadded、removed、changed、unchangedのいずれかに分類する。CapabilityLockfile.ts:324-336のシリアライズ出力は、ソートされたキーを使用するため、入力が同じ場合は常に同じ出力を生成し、lockfileをgitで比較可能にする。

lockfileが対応するレビューなしにデプロイ間で変更された場合、CIゲートはビルドを失敗させる。ランタイムがlockfileにないツールを検出した場合、ディスパッチ前に拒否される。

Q12: 監査イベントを偽造または削除できないようにするにはどうすればよいですか？

2つの独立したハッシュチェーンが異なるサーフェスをカバーする:

ランタイムツール実行チェーンはChainForge.tsによって構築される。ChainForge.ts:26では、GENESIS_HASH = '0'.repeat(64)がチェーンをアンカーする。各監査イベント:

chain_input  = raw_base64 || previous_hash || sequence_number
current_hash = SHA-256(chain_input)
signature    = Ed25519_Sign(sessionPrivateKey, chainInput)

これはChainForge.ts:56-66にある。チェーンの状態(lastHash, lastSeq)は、StreamingDaemon.ts:309-317のMULTI/EXEC HSET + XACKでRedisにアトミックにチェックポイントされる。デーモン自体はStreamingDaemon.ts:31でCONSUMER_GROUP = 'audit-group'を使用し、シングルスレッドである。ChainForge.ts:12は、これがStreamingDaemonによってのみ呼び出されることを述べている。並行性なし、競合条件なし。

デプロイメント監査証跡はDeployAuditLog.php:144-147によって管理される。各レコードはHMAC-SHA256でチェーンされる: H(prev_hmac || id || event || payload)。静的方法verifyChain()はDeployAuditLog.php:175-214でUUID v7で順序付けられたレコードを歩き、HMACを再計算し、hash_equals()と比較する。

DeployAuditLog.php:95-99では、delete()メソッドはRuntimeExceptionをスローする。ログは不変で、delete()やupdate()のパスはない。これは、EU AI Act 第26条第5項および第73条に準拠している。

セッショントークンはChainForge.ts:110-113( rotateSessionKey)で24時間ごとにローテーションされる。セッショントTLはStreamingDaemon.ts:35でSESSION_KEY_TTL_MS = 24 * 60 * 60 * 1000で強制される。

Q13: 封印された Vault には何が入っており、鍵は実際にどのように管理されますか？

VaultはAESデータではなく、Ed25519キーペアを保存する。VaultProvider.ts:10-52はインターフェースを定義する: getMasterKey、generateSessionKey、sign、verify、crossSignRotation。

SoftwareVaultProvider.ts:59-116は、SETNXでレース安全に、mcp:vault:{workspaceId}でマスターキーを生成する。SoftwareVaultProvider.ts:138-143のセッショント証明書は、マスタープライベートキーでセッショントのパブリックキーに署名し、ワークスペースと有効期限にバインドする。

VaultProvider.ts:23はgenerateSessionKey(24h)でセッションキーペアを生成する。24時間のTTLは、StreamingDaemon.ts:35のChainForgeローテーションと一致する。sign関数はVaultProvider.ts:34で、セッションのプライベートキーを使用してEd25519署名を実行する。

SoftwareVaultProvider.ts:188は、90日のマスターキーローテーションのcrossSignRotation()を実装する。これにより、古いキーが新しいパブリックキーに署名し、逆も可能になる。これにより、ダウンタイムなしの移行が可能になる。

より広範な監査アーキテクチャとの接続は、AIガバナンス記事にある。これは、これらのキーを消費する12のサーフェスをカバーしている。

Q14: エージェントが未知の外部宛先に不審なツール呼び出しを行っているのを検出し、停止するにはどうすればよいですか？

アイソレートからのすべての外向きHTTP呼び出しは、safeFetch in SsrfGuard.ts:163に導かれる。これはguestに公開される唯一の出口である。IsolateRunner.ts:161のブリッジは、guestのfetch呼び出しをこの関数に専属でルーティングする。

TimeoutClassifier.ts:53は、ディスパッチ障害をUPSTREAM_TIMEOUT、COMPUTE_TIMEOUT、MEMORY、INTERNAL_ERRORに分類する。30%以上のDispatch予算がI/Oに費やされた場合。TimeoutClassifier.ts:66では、upstreamShareThresholdMs = Math.max(1_000, Math.floor(ctx.dispatchTimeoutMs * 0.3))。エラーは、guestバンドルではなく、アップストリームサービスに対して報告される。最も遅い3つの呼び出しはMAX_LISTED_CALLS = 3 (TimeoutClassifier.ts:46)で表示される。

ResponseGuard.tsのDLPパターンは、 egressレスポンスに表示されるべきではない機密フィールド名をカバーする。デフォルトのredactionパターンには、email、password、secret、credit_card、ssn、api_key、token、ibanなどのワイルドカードが含まれる。各redactionはResponseGuard.ts:122-128でカウントされ、属性付けられる。特定のコネクタのredactionの急墑は、AIガバナンスダッシュボードでシグナルをトリガーする。

Q15: リクエストの途中でランタイムプロセスがクラッシュした場合、接続はどうなりますか？

POSTリクエストは設計上、statelessである。streamableHttp.ts:15では、POSTリクエストはstatelessで提供される。各リクエストは、ephemeralなMcpServer + Transportを作成し、リクエストを処理し、すべてを破棄する。streamableHttp.ts:62のコメントは、stateless HTTPは、ランタイムの任意のインスタンスが任意のリクエストに対応できることを示す。

SSE接続はstatefulであるが、メタデータはRedisに存在する。ConnectionTracker.ts:61-67はSSE接続メタデータをRedisに保存(ElasCache互換)する。クラッシュからの復旧は、新しいインスタンスが同じメタデータを読み取ることによって行われる。

server.ts:19では、ランタイムは空でブートする。最初のClient接続で、lazyに構成をロードする。起動時にeagerにロードしない。pub/subのSubscriberはserver.ts:71-90で、mcp:invalidate、mcp:kill-server、mcp:update-quota、mcp:tools-changed、mcp:streaming-reloadに購読する。

server.ts:47-52では、未処理のrejectionとuncaught exceptionハンドラーは致命的なエラーをログに記録するが、プロセスを維持する。ランタイムは設計上、プロセスをダウンさせることなく、個々のリクエストの失敗を生き延るように設計されている。

SnapshotCache.ts:202のSnapshotキャッシュは、起動時にすべてのキャッシュされたスナップショットを検証する起動パージを実行する。破損したスナップショットによるクラッシュが再起動時に再発することはない。

---

これらの質問に答える12のサーフェス

上記の技術的機能は、Vinkiusガバナンスモデルの12のサーフェスに対応している。8つは報告し、4つは決定する。

報告するサーフェス (可視性のある場所) :

1. Crypto Audit PathはChainForge.ts:26-80のランタイムハッシュチェーン、DeployAuditLog.php:144-214のデプロイ整合性。
2. DLPテレメトリーはResponseGuard.ts:122-128で、トークンごとにすべてのRedactionをカウントする。
3. FinOpsテレメトリーはQuotaEnforcer.ts:236-243で使用状況を追跡し、10Kの境界でオーバー課金をトリガーする。
4. 接続ログはAuditLogger.ts:19-55で、SOC 2コンプライアンスのためにLPUSHでRedisに接続イベントをプッシュする。
5. SIEMディスパッチはStreamingDaemon.ts:83-153で、XREADGROUPを使用してRedis Streamsを消費し、チェックポイントを復元し、SIEM宛にディスパッチする。
6. スナップショット整合性はSnapshotCache.ts:95-101で、V8に到達する前にSHA-256を検証する。
7. タイムアウト分類はTimeoutClassifier.ts:41-80で、障害をアップストリームとコンピュートに帰属させる。
8. ハニートークン検出: デコイ資格情報が使用されると、プロバイダーのWebhookが発火し、コネクターが自動的にBANされる。

決定するサーフェス (実施のある場所) :

1. コネクターポリシーはCapabilityLockfile.ts:100-143で、コンパイル時に機能表面を固定する。
2. DLP保護はResponseGuard.ts:4-177で、ホストプロセス内ですべてのツールレスポンスに対して実行される。
3. FinOpsガードはCircuitBreaker.ts:22-80で、財務予算上限をトリップした際に再試行不可能なエラーを返す。
4. サーキットブレーカーはQuotaEnforcer.ts:154-246で、プラン別に分岐し、Marketplaceとフリー階層を上限でハードブロックし、有料プランのオーバーを許容する。

すべてのサーフェスはコードで強制されており、ポリシードキュメントではない。上記の数値、制限、行参照は実装である。印刷してください。監査してください。信頼を持ってデプロイしてください。

ユーザー向けの簡易なFAQについては、AIガバナンス投稿のFAQセクションを参照してください。100の同時エージェントを処理するスウォームゲートウェイのセッション管理については、SwarmGatewayセッション投稿を参照してください。