要約

  • draft-smith-opsawg-ai-network-governance-01 は、AIへの制約伝達が独立したprogrammatic enforcementを代替しないと明記する。
  • 許可された提案、成功した管理RPC、発行済みrollbackは別々の事実であり、正しい権限とservice回復を単独では証明しない。

モデルは規則を守った。だから装置変更も規則に従った。

この二つの文の間に、最も重要な実行系が抜けている。

モデルが許可済みactionを提案し、parameterも範囲内だったとしても、executorが参照したAction Registry、operator allow list、protected target、rate counter、degradation state、revocation stateが、promptに投影されたものと同一とは限らない。reloadやfailoverが挟まれば、差は事故時に初めて見える。

2026年9月27日公開の draft-smith-opsawg-ai-network-governance-01 は、この問題に有用な分離を与える。ただしactiveなindividual Internet-Draftであり、RFCでもIETFの承認でもworking-group consensusでもない。RFC streamとformal standingはなく、headerのintended statusはInformationalである。展開済み標準ではなく、評価すべきarchitecture proposalだ。

対象は四条件を全て満たすsystemである。routerやswitch上で動くかmanagement planeへ直接到達し、外部AI serviceに異常分析とremediation proposalを求め、人のaction単位承認なしにconfigurationまたはoperational stateを変え、NETCONF、RESTCONF、gNMI等を使う。人が必ず実行するadvisory toolは対象外だ。

外部AI serviceはcontextを受け取り提案する。ローカルagentがtelemetry収集、検知、guardrail、装置操作を担う。AI serviceには直接のdevice accessを与えない。この境界は望ましいが、local agentがpolicyとcredentialと装置権限の集中点になる。

Action Registryはdeveloperが固定したaction catalogで、parameter、risk、reversibilityを持つ。Operator Allow Listはdeploymentで自律実行を許したsubsetである。catalog外の提案は破棄され、AIは新しいaction typeを作れない。model confidenceが高くてもrange外parameterは拒否される。

draftはallowed/blocked action、protected target、rate limit、risk ceilingをpromptやcontextへ入れるよう求める。提案の無駄を減らし、escalation理由を説明しやすくするためだ。

しかしSection 16は、その伝達がprogrammatic enforcementを置き換えないと明言する。agentは全proposalを独立して検証しなければならない。Section 17もprompt、response parser、safety guardrail、execution pointに防線を分け、単一layerを十分としない。

この原則を監査可能にするには、actionごとのpolicy receiptが要る。人が承認したsnapshot、registryとallow/block listの版、target rule、parameter bound、risk ceiling、rate state、degradation、revocation、proposal、parse result、guardrail verdict、execution直前の再検証、認証済みoperation、pre-state、device reply、fresh telemetry、rollbackまたはescalation結果を一つの因果列へ結ぶ。

prompt hashだけでは足りない。外部service向けprojectionは機密条件を省き、patternを単純化し、問い合わせ時の残量だけを記すことがある。「guardrail passed」だけでも、何が判断を真にしたか分からない。

rate limitはこの問題をstate問題に変える。draftは1時間のremediationをdefault 5、proposed maximum 20、targetごとの24時間actionを3と5にする例を含む。irreversible action、AI query、cooldown、retryにも値がある。これはindividual draftのproposalであり、全networkに有効な実証済み閾値ではない。

「今時間の5件目」は履歴claimである。完全なevent、clock、window semantics、restartとfailoverのcontinuityが要る。cooldown、retry、revocation、degradationも同じだ。

Section 17.3は、可能ならcheckをstatelessにし、volatile memoryでなくpersistent audit trailから入力を得るよう推奨する。restartでcounterを失わないための良い設計だが、stateは消えない。logとprojectionがauthorityになり、integrity、ordering、retention、clock、policy activation、replica convergenceがsafety propertyになる。

fail-safeの例も明快だ。rate dataを読めなければlimit exhausted、target matchが失敗すればprotected、registryに到達できなければunregisteredとしてblockする。unknownをpermissionへ変換してはならない。

次の境界はdevice outcomeである。action前にrestore可能なpre-stateを取得し、action後はfresh telemetryで再検知し、改善しなければrollbackとhuman escalationを行う。cacheやduplicate suppressionで隠れたdataはverificationにならない。

ただしconfiguration snapshotは時間を巻き戻さない。失われたpacket、切れたsession、枯渇したqueue、remote peerのtimerは復元できない。rollbackは変化中systemへの別のforward operationであり、独自のreply、readback、service observationが必要だ。

single targetもsingle impactを意味しない。interfaceやmetric一つの変更が、shared failure domain、routing convergence、traffic shiftを通じて遠方へ届く。文法上のscopeと運用上のscopeを同一視できない。

prompt injectionの節はdevice生成logやinterface descriptionがAI reasoningへ影響し得るとする。sanitizeは有効だが、本質的な防線はAIをadvisoryに留め、全outputを独立検証することだ。testはmodelの拒否応答だけでなく、parser、catalog、target、parameter、history、execution、failoverを通す必要がある。

draftはaudit trailを主要なaccountability mechanismと呼び、integrity protectionとexternal retentionを推奨する。policy receiptはここに置くべきだ。startup configuration logだけでは、その後のreloadを経た一件を説明できない。

著者はproduction infrastructureでのoperational experienceに基づくと記すが、これはauthor statementであり、独立studyやbenchmarkではない。deployment規模、incident rate、結果は示されない。数値は各環境で検証すべき仮説である。

Heng LuのMinimum Initial Specificationは共通minimumを硬くする。AIはaction vocabularyを拡張しない。unknown policy stateはfail closed。agentは自分のgovernanceを変えない。全mutationはadmission authorityを指す。Reality Layersは「allowed」というsymbolをnetwork realityから分け、Running-Code Primacyはreadbackとservice outcomeを最終判定に置く。

情報源