Agent Egress 制御／Network Policy

Agent egress controlは、private endpointやVPC接続の有無だけで判定せず、Agent runtimeから外部destinationへ出る実際のpathを制御します。

基本はdeny-by-defaultとし、必要なtool/API destinationだけを明示的に許可します。network reachabilityとtool/API authorizationは別controlです。

private endpointは主にinbound/private accessを構成します。private endpointがあること���けを、Agentのinternet egressが閉じている証拠にはしません。

managed Agent runtimeでは、outbound trafficがcustomer VPC/VNetを通るかprovider-managed producer networkから出るかをfeature単位で確認します。

Agent runtime、pod、namespace、subnet等の実際のenforcement対象を特定し、default-deny egressを基準にします。

許可先はtool/API単位でinventoryし、owner、用途、protocol/port、identity、期限を記録します。

open-ended web accessが必要な場合、任意internet egressではなく専用proxy/brokerへの集約を検討します。

default-denyはDNSも停止し得るため、必要なresolver pathを明示的に許可します。

FQDN allowlistはDNS answer、TTL、resolver trust、policy engineのDNS observation/proxyへ依存します。domain名を記述しただけでdestination identityが恒久的に固定されたとは扱いません。

DNS resolver自体を広く許可すると、FQDN policyのtrust boundaryが広がる場合があります。

IP/CIDR、port/protocol、FQDN、HTTP/DNS等のpolicy layerを区別します。

L3/L4で到達可能でも、HTTP path/methodやtool actionまで許可されたことにはなりません。必要な場合のみL7 controlを追加し、proxy dependencyとfailure modeを運用対象にします。

network allowはIAM、OAuth、API key、resource policy、service authを代替しません。

Agentがdestinationへ接続可能でも、実行可能なaction/resourceは最小権限で別途制限します。

network denyとapplication authorizationの双方を通過しなければside effectを許可しない構成を採ります。

managed Agent serviceではprovider/service/featureごとにdefault internet egressとcustomer networkへのroutingが異なり得ます。

Microsoft Foundryではinboundとoutboundが別decisionであり、public egressとprivate endpointを併用できます。managed networkのAllow Only Approved Outboundではprivate endpoint、service tag、FQDN rule等を使用します。

Google Agent PlatformではVPC Service ControlsやPSC interfaceの有無、producer/runtime種別によってinternet egress pathが変わります。PSC/VPC接続だけを全producerのegress denyとして一般化しません。

Kubernetes NetworkPolicyは実装CNIがenforcementを提供していることを前提にします。default-deny egressを置いた場合、DNS等の必要trafficを別途許可します。

CiliumのtoFQDNsはDNS responseからIPを学習しTTLを尊重します。DNS proxy/L7 DNS ruleとruntime stateを確認し、policy YAMLの存在だけでenforcement成功としません。

deployment/change時にAgent runtimeから次を検証します。 - intended destinationへのpositive test - 未許可internet destinationへのnegative test - direct IPへのnegative test - alternate hostnameへのnegative test - DNS resolutionとresolver path - IPv4/IPv6 - proxy/NAT/firewall route - policy realized state - flow/DNS/proxy/service logs - tool/API authorization denial

「許可先へ接続できた」だけではegress controlの検証完了としません。

緊急時のallow-all/public egressは、owner、理由、開始時刻、expiry、監査記録を持つbreak-glassとして扱います。恒久的なfallback ruleとして残しません。

allow-all residual、selector miss、CNI non-enforcement、DNS outage、resolver over-trust、DNS answer change、wildcard overbreadth、direct-IP/IPv6/alternate-host bypass、proxy/NAT bypass、managed producer bypass、perimeter exception、tool credential overreach、dependency omission、redirect/CDN、WebSocket/QUIC、policy propagation delay、failover、break-glass残置、L7/DNS proxy outage、secret-bearing logs、observability gapを想定します。

本項は2026-10-06時点のMicrosoft Foundry networking、Google Agent Platform PSC/VPC Service Controls、Kubernetes NetworkPolicy、Cilium DNS/FQDN/L7 policy、AWS VPC Lattice authorization documentationに基づきます。organization runtimeへのnetwork mutation、live Agent egress/exfiltration testは未実施です。

Agent egress controlは、private endpointやVPC接続の有無だけで判定せず、runtimeごとの実際のoutbound pathにdeny-by-defaultと必要destinationのallowlistを適用します。DNS/FQDN、L3/L4/L7、proxy/NAT、service perimeter、identity/tool authorizationを分離し、許可経路の成功と未許可経路の拒否をAgent runtimeからreadbackします。

organization runtime/provider、actual Agent tools、destination/dependency inventory、CNI/policy engine、DNS topology、IPv6、direct-IP controls、proxy/NAT/firewall、VPC-SC/perimeter、IAM/OAuth/service auth、redirects/CDN、WebSocket/QUIC、failover、break-glass、logging/redaction、cost/quota、tenant-specific managed-runtime routesは未確認です。