🧱 技術調査 - AI-Agent-Network-Boundary-NGINX-OTEL

CNCF Blog「Network boundary for AI agents using NGINX and OpenTelemetry」(2026-07-08) が提示した、AI エージェントの外部通信 (egress) を NGINX に単一集約し、iptables で迂回を物理的に塞ぎ、ngx_otel_module で全リクエストを OpenTelemetry span として記録するアーキテクチャの技術調査です。

検証日: 2026-07-09。主な起点は CNCF Blog 2026-07-08 の記事です。コード例は、NGINX / OpenTelemetry / Kubernetes の公式ドキュメントで確認できる範囲に寄せています。

概要

なぜ AI エージェントに network boundary が必要か

AI エージェントは、ユーザーの指示を解釈してツールを自律的に呼び出します。この自律性が、そのまま制御上の課題になります。

• 意図が不透明: エージェントが実際に何をしているかを外部から把握しづらいです。CNCF Blog は、ある登壇者の発言として「we don't know what that thing really does」を引用しています。
• 生成時ガードレールは実行時の通信を止められない: プロンプトやモデル出力を検査するガードレールがあっても、ツール実行フェーズで発生する外部通信そのものは抑制できません。
• exfiltration・プロンプトインジェクション経由の不正 egress: エージェントは .env や API キーなどの認証情報にアクセスできる場合が多く、悪意ある入力に従って認証情報を外部へ送信するリスクがあります。PipeLab は「プロキシがなければ、侵害されたエージェントは認証情報を無制限に外部へ送信できる」と指摘しています。
• 監査証跡の欠如: エージェントがどの外部リソースにアクセスしたかを、後から追跡できる仕組みがない環境が大半です。

このアーキテクチャは、これらの課題に対して「エージェントの外部通信を単一の経路に強制的に集約し、その経路を丸ごと記録する」ことで応えます。

このアーキテクチャの位置づけ

このアーキテクチャは、アプリケーション内のガードレールや利用ポリシーを置き換えるものではありません。defense-in-depth の 1 層として、ネットワーク層に強制点を追加する位置づけです。

CNCF Blog は次のように述べています。

Restricting where an agent can communicate does not guarantee that its decisions are correct or safe.

ネットワーク境界はエージェントの判断の正しさを保証しません。保証するのは「通信できる範囲」だけです。判断の正しさはアプリケーション層の責務のままであり、このアーキテクチャはその外側にもう 1 層、迂回できない制約を足すものです。

「boundary as architecture, not policy」の意味

CNCF Blog のキーフレーズは次の一文に集約されます。

That makes the boundary a property of the architecture, not a policy we hope the application respects.

この一文が指しているのは、次の違いです。

このアーキテクチャでは、NGINX forward proxy をエージェントの唯一の egress 経路とし、iptables でそれ以外の送信トラフィックを遮断します。これにより、境界の実効性がアプリケーションの実装品質から切り離されます。

特徴

• open standards ベース: NGINX (OSS のリバース/フォワードプロキシ) と OpenTelemetry (CNCF の観測標準) という、広く使われるオープンスタンダードの組み合わせで構成します。専用の商用ゲートウェイ製品を新規導入する必要がありません。
• reverse + forward の二役構成: 同じ NGINX インスタンスが、受信方向ではリバースプロキシ兼 TLS 終端、送信方向ではフォワードプロキシとして機能します。エージェントの受信・送信の両方が単一のコンポーネントを経由します。
• iptables による物理的な迂回不能性: NGINX forward proxy 以外の送信トラフィックを iptables ルールでドロップします。エージェントプロセスが直接外部と通信しようとしても、ネットワークレベルで到達しません。
• ngx_otel_module による自動 span 化: NGINX を通過する全リクエストが OpenTelemetry の span として自動生成されます。アプリケーションコード側に計装を追加する必要がありません。
• OTEL Collector を介した監査ログ集約: 生成された span は OTEL Collector に送られ、Jaeger・Grafana・SIEM など既存の観測基盤に統合できます。
• allowlist によるドメイン単位の制御: NGINX の設定 (例: ConfigMap) で許可ドメインを列挙します。CNCF Blog は nginx.org と duckduckgo.com のみ許可する例に触れています。
• ユーザー操作との相関付け: OTEL の相関 ID により、クライアントからのリクエストとエージェントが行った外部呼び出しを紐づけて追跡できます。
• Kubernetes デプロイ可能: CNCF Blog の検証環境は、単一ノードの Kubernetes クラスタ上に NGINX・LLM 推論エンジン・エージェント・OTEL Collector を共存させています。
• NGINX 製品ラインへの継承予定: NGINX Ingress Controller (NIC) や NGINX Gateway Fabric (NGF) が、将来的にこの境界機能を継承する計画が言及されています。

類似アプローチとの比較

構造

C4 model に沿って、このアーキテクチャを 3 段階でドリルダウンします。データモデル (属性) や設定ファイルの具体的な書式は扱わず、コンポーネントの名前と責務、ネットワーク上の経路に焦点を当てます。

システムコンテキスト図

対象システムを 1 つの箱として見たとき、誰がどう関わり、外部の何と通信するかを示します。

コンテナ図

対象システムをドリルダウンし、単一ノード Kubernetes 上のワークロード配置として表現します。CNCF Blog の検証環境は、同一 namespace 内に NGINX・Ollama (LLM runtime)・OpenClaw (AI エージェント)・OpenTelemetry Collector の 4 ワークロードを配置しています。

Kubernetes クラスタ 単一ノード

外部システム

コンポーネント図

forward proxy と OTEL 観測面をさらにドリルダウンします。allowlist によるドメイン制御、ngx_otel_module のディレクティブ、OTLP/gRPC エクスポート、W3C trace context 伝播、Collector のパイプライン構成を示します。

forward proxy 内部構成

OTEL Collector パイプライン

ネットワーク構成図

AI エージェント Pod から発生する全 egress が NGINX forward proxy を通過する経路と、iptables が forward proxy 以外への直接 egress をドロップする経路を示します。

データ

このアーキテクチャが扱うデータは大きく 3 層に分かれます。

CNCF Blog (2026-07-08) 自体は概念レベルの説明にとどまり、具体的な nginx.conf や iptables ルール文面は公開していません。属性名・ヘッダ形式は ngx_otel_module 公式ドキュメントの「Default span attributes」節が実際に自動付与する属性名 (旧世代 semconv)、W3C Trace Context 仕様に整合させて構成しています。

概念モデル

情報モデル

構築方法

捏造防止の注記: CNCF Blog (2026-07-08) 本文には nginx.conf 全文・iptables ルール・Kubernetes マニフェストのコード掲載がなく、「OpenClaw Network Boundary repository」への言及のみで実リンクは確認できませんでした。本セクションのコード例は nginx.org / docs.nginx.com / opentelemetry.io の現行公式ドキュメントで確認できた仕様のみで組み立てています。確認できなかった箇所は「公式ドキュメントで要確認」と注記します。

前提条件

ngx_otel_module の入手・ロード

ngx_otel_module は NGINX 本体に同梱されない動的モジュールです。入手方法は 2 通りあります。

方法 1: 公式パッケージリポジトリからインストール (推奨)

# 1. 前提パッケージ
sudo apt update && \
sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring

# 2. nginx.org 署名鍵の取得
curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
  | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

# 3. 公式 apt リポジトリの追加
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
https://nginx.org/packages/ubuntu $(lsb_release -cs) nginx" \
  | sudo tee /etc/apt/sources.list.d/nginx.list

# 4. NGINX 本体 + otel 動的モジュールをインストール
sudo apt update && \
sudo apt install nginx nginx-module-otel

• OSS 版のプリビルドパッケージ名は nginx-module-otel (nginx.org のパッケージリポジトリで提供)。
• NGINX Plus では nginx-plus-module-otel (NGINX Plus R29 以降、商用サブスクリプションが必要)。

方法 2: ソースからビルド

git clone https://github.com/nginx/nginx.git
cd nginx && auto/configure --with-compat
cd ..
git clone https://github.com/nginx/nginx-otel.git
cd nginx-otel && mkdir build && cd build
cmake -DNGX_OTEL_NGINX_BUILD_DIR=/path/to/nginx/objs ..
make

• ビルドした ngx_otel_module.so はビルドに使った NGINX 本体と同一バージョン・同一 OS でのみ動作します (公式 README に明記)。
• 事前ビルド済みの公式 Docker イメージは、確認した範囲では見当たりませんでした。公式ドキュメントで要確認。Dockerfile で方法 1 または方法 2 を実行してイメージを自前ビルドする運用が現実的です。

ロード (両方法共通): nginx.conf の先頭 (トップレベルコンテキスト) に追加します。

load_module modules/ngx_otel_module.so;

http {
    # ...
}

設定反映は通常の NGINX 運用と同じです。

nginx -t
nginx -s reload

forward proxy として NGINX を構成する方法

重要な制約 (公式ドキュメントで確認済み): NGINX で HTTP CONNECT メソッドを使った HTTPS 向け forward proxy (トンネリング) は NGINX Plus R36 以降の tunnel_pass ディレクティブが必要であり、OSS 版 NGINX には含まれません。OSS で CONNECT を扱いたい場合は、サードパーティモジュール ngx_http_proxy_connect_module を組み込んでビルドする必要があります。CNCF Blog は agent から DuckDuckGo (HTTPS) への到達を許可する例を挙げていますが、forward proxy の実装方式 (CONNECT 対応版か、TLS 終端方式か) の明記はなく、公式ドキュメントで要確認です。

平文 HTTP のリクエストを forward proxy する場合 (OSS NGINX でそのまま利用可能) は、resolver + 絶対 URI の proxy_pass で実現します。

http {
    resolver 127.0.0.11 valid=30s;   # クラスタ内 DNS (例: kube-dns/coredns) を指す

    server {
        listen 8888;

        location / {
            proxy_pass $scheme://$http_host$request_uri;
            proxy_set_header Host $http_host;
        }
    }
}

• resolver は宛先ホスト名を都度解決するために必須です (公式ドキュメントに明記)。
• proxy_pass $scheme://$http_host$request_uri; は、クライアントが送ってきた絶対 URI 形式のリクエストをそのまま宛先へ中継する forward proxy の定石です。

HTTPS (CONNECT) を扱う場合 (NGINX Plus R36+、tunnel_pass) は次の形になります。

server {
    listen 8888;

    location / {
        if ($request_method != CONNECT) {
            return 403 "Forbidden: allows only CONNECT method";
        }
        tunnel_pass;
    }
}

• tunnel_pass はコンテンツ処理ディレクティブのため、server に書いても子の location には継承されません。location 内に明示します。

allowlist の実装

CNCF Blog は ConfigMap で nginx.org と duckduckgo.com のみ許可する例に触れています (記事本文はコンセプト説明のみで設定コード全文の掲載はありません)。以下は公式ドキュメントの map ディレクティブに基づく実装例です。

平文 HTTP forward proxy 向け (map + if):

map $http_host $is_allowed_host {
    hostnames;
    default          0;
    nginx.org        1;
    www.nginx.org    1;
    duckduckgo.com   1;
    www.duckduckgo.com 1;
}

server {
    listen 8888;
    resolver 127.0.0.11 valid=30s;

    location / {
        if ($is_allowed_host = 0) {
            return 403 "destination not allowed by egress policy";
        }
        proxy_pass $scheme://$http_host$request_uri;
        proxy_set_header Host $http_host;
    }
}

HTTPS CONNECT forward proxy 向け (NGINX Plus tunnel_allow_upstream):

map $host $allowed_host {
    hostnames;
    default             0;
    nginx.org           1;
    duckduckgo.com      1;
}

server {
    listen 8888;

    tunnel_allow_upstream $allowed_host;
    tunnel_pass;
}

• map の hostnames; パラメータにより *.example.com のようなワイルドカード指定も可能です (公式ドキュメント記載)。
• 許可対象外は 403 を返す、または tunnel_allow_upstream が 0 を返した場合は接続を拒否します。

iptables で agent の直接 egress を遮断し NGINX 経由に強制する

NGINX と agent を同一 Pod 内のコンテナ (ネットワーク namespace 共有) として配置し、Pod 起動時の initContainer (NET_ADMIN capability 必須) で iptables ルールを注入する構成を想定します。この起動時ルール投入パターンは Linkerd / Istio の sidecar 注入で広く使われている手法です (以下は標準的な netfilter 構文に基づく例)。

# 1. ループバック (NGINX との localhost 通信) は許可
iptables -A OUTPUT -o lo -j ACCEPT

# 2. 確立済み・関連する戻り通信は許可
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# 3. DNS 解決 (NGINX の resolver 用) はクラスタ DNS 宛てのみに限定
#    (宛先無制限の 53/udp を空けると DNS トンネリングで exfiltration される)
iptables -A OUTPUT -p udp -d <cluster-dns-clusterip> --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp -d <cluster-dns-clusterip> --dport 53 -j ACCEPT

# 4. NGINX (forward proxy) 宛てのみ許可 (同一 Pod 内 localhost:8888 を想定)
iptables -A OUTPUT -p tcp -d 127.0.0.1 --dport 8888 -j ACCEPT

# 5. NGINX プロセス自身 (実行 UID) からの直接 egress はループ回避のため個別許可
iptables -A OUTPUT -m owner --uid-owner <nginx-uid> -j ACCEPT

# 6. 上記いずれにも合致しない agent からの直接 egress は全て遮断
iptables -A OUTPUT -j DROP

• ポイントは「NGINX 自身の egress」と「agent からの egress」を UID (--uid-owner) または送信元プロセスで区別し、agent には NGINX 宛て以外への OUTPUT を許可しないことです。
• DNS は宛先を絞る: --dport 53 を宛先無制限で許可すると、任意の外部 DNS サーバーへの問い合わせを使った DNS トンネリング (帯域外 exfiltration) が残ります。クラスタ内 DNS (kube-dns/coredns の ClusterIP) 宛てのみに限定します。
• IPv6 も塞ぐ: 上記は IPv4 (iptables) のみです。Pod が IPv6 を持つ環境では同等の ip6tables ルールを併記するか、Pod の IPv6 を無効化しない限り IPv6 egress が迂回経路として残ります。
• Kubernetes 上では initContainer にこのスクリプトを実行させ、securityContext.capabilities.add: ["NET_ADMIN"] を付与します。
• CNCF Blog 本文には具体的なルール例の掲載がないため、設計思想の再現に留め、正確な運用ルールは自環境で検証してください。

OTEL Collector のデプロイ

最小構成の Collector 設定 (otlp receiver → batch processor → exporter) は公式ドキュメント記載のパターンに準拠します。

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch: {}

exporters:
  debug:
    verbosity: detailed
  # 実運用では Jaeger / Grafana Tempo / SIEM 等への OTLP exporter に置き換える
  otlp:
    endpoint: jaeger-collector.observability.svc:4317
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, otlp]

利用方法

ngx_otel_module ディレクティブ一覧

出典: https://nginx.org/en/docs/ngx_otel_module.html (現行版で確認)。

Kubernetes マニフェスト例

ConfigMap: NGINX 設定 (reverse proxy + forward proxy + allowlist + otel)

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-boundary-conf
  namespace: agent-boundary
data:
  nginx.conf: |
    load_module modules/ngx_otel_module.so;

    events {}

    http {
      resolver 127.0.0.11 valid=30s;

      otel_exporter {
        endpoint otel-collector.agent-boundary.svc:4317;
      }
      otel_service_name nginx-agent-boundary;

      map $http_host $is_allowed_host {
        hostnames;
        default            0;
        nginx.org          1;
        www.nginx.org      1;
        duckduckgo.com     1;
        www.duckduckgo.com 1;
      }

      # forward proxy: agent -> 外部
      server {
        listen 8888;
        otel_trace on;
        otel_trace_context propagate;
        otel_span_name "forward_proxy:$http_host";
        otel_span_attr "boundary.direction" "egress";

        location / {
          if ($is_allowed_host = 0) {
            return 403 "destination not allowed by egress policy";
          }
          proxy_pass $scheme://$http_host$request_uri;
          proxy_set_header Host $http_host;
        }
      }

      # reverse proxy: 外部 -> agent (Ollama/OpenClaw)
      server {
        listen 443 ssl;
        ssl_certificate     /etc/nginx/tls/tls.crt;
        ssl_certificate_key /etc/nginx/tls/tls.key;

        otel_trace on;
        otel_trace_context extract;
        otel_span_name "reverse_proxy:$request_uri";
        otel_span_attr "boundary.direction" "ingress";

        location / {
          proxy_pass http://agent-svc.agent-boundary.svc:11434;
        }
      }
    }

agent Pod: egress を iptables で NGINX 経由に強制

apiVersion: v1
kind: Pod
metadata:
  name: openclaw-agent
  namespace: agent-boundary
spec:
  initContainers:
    - name: iptables-init
      image: <NET_ADMIN 権限で iptables を実行できるイメージ>
      securityContext:
        capabilities:
          add: ["NET_ADMIN"]
      command: ["sh", "-c"]
      args:
        - |
          iptables -A OUTPUT -o lo -j ACCEPT
          iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
          iptables -A OUTPUT -p udp -d <cluster-dns-clusterip> --dport 53 -j ACCEPT
          iptables -A OUTPUT -p tcp -d <cluster-dns-clusterip> --dport 53 -j ACCEPT
          iptables -A OUTPUT -p tcp -d 127.0.0.1 --dport 8888 -j ACCEPT
          iptables -A OUTPUT -j DROP
  containers:
    - name: agent
      image: <openclaw イメージ>
      env:
        - name: HTTP_PROXY
          value: "http://127.0.0.1:8888"
        - name: HTTPS_PROXY
          value: "http://127.0.0.1:8888"
    - name: nginx-boundary-sidecar
      image: <自前ビルドの nginx + ngx_otel_module イメージ>
      ports:
        - containerPort: 8888
      volumeMounts:
        - name: conf
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
  volumes:
    - name: conf
      configMap:
        name: nginx-boundary-conf

• agent と nginx-boundary-sidecar を同一 Pod に同居させ、ネットワーク namespace を共有させることで 127.0.0.1:8888 への到達と iptables ルールの Pod 単位適用が両立します。
• Deployment 分離構成 (NGINX を独立 Service にする案) を採る場合、iptables の許可先は NGINX Service の ClusterIP に置き換えます。

Deployment/Service: OTEL Collector (前掲 otel-collector-config.yaml を ConfigMap 化して参照)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: otel-collector
  namespace: agent-boundary
spec:
  replicas: 1
  selector:
    matchLabels: { app: otel-collector }
  template:
    metadata:
      labels: { app: otel-collector }
    spec:
      containers:
        - name: otel-collector
          image: otel/opentelemetry-collector:latest
          args: ["--config=/etc/otel/config.yaml"]
          ports:
            - containerPort: 4317
          volumeMounts:
            - name: conf
              mountPath: /etc/otel
      volumes:
        - name: conf
          configMap:
            name: otel-collector-conf   # otel-collector-config.yaml を config.yaml として格納
---
apiVersion: v1
kind: Service
metadata:
  name: otel-collector
  namespace: agent-boundary
spec:
  selector: { app: otel-collector }
  ports:
    - port: 4317
      targetPort: 4317

動作確認

前提の注意 (proxy 方式と CONNECT): 下記の curl -x http://127.0.0.1:8888 https://... は、https:// 宛てのため CONNECT メソッドを送ります。前掲の OSS 向け ConfigMap 例 (proxy_pass $scheme://$http_host$request_uri) は平文 HTTP の forward proxy であり、CONNECT を処理できません。HTTPS を通すには、NGINX Plus の tunnel_pass/tunnel_allow_upstream 構成か、OSS では ngx_http_proxy_connect_module を組み込んだビルドが必要です。以下の検証は CONNECT 対応ビルドを前提とします。平文 HTTP だけを検証する場合は curl -x http://127.0.0.1:8888 http://nginx.org のように http:// 宛てにします。

許可ドメインへの通信 (通る):

kubectl exec -n agent-boundary openclaw-agent -c agent -- \
  curl -sS -x http://127.0.0.1:8888 https://duckduckgo.com -o /dev/null -w '%{http_code}\n'
# => 200 が返り、NGINX 側で span が生成される

非許可ドメインへの通信 (allowlist で遮断):

kubectl exec -n agent-boundary openclaw-agent -c agent -- \
  curl -sS -x http://127.0.0.1:8888 https://example.com -o /dev/null -w '%{http_code}\n'
# => 403 (allowlist で拒否)

NGINX を迂回した直接 egress (iptables で遮断):

kubectl exec -n agent-boundary openclaw-agent -c agent -- \
  curl -sS --max-time 3 https://duckduckgo.com -o /dev/null -w '%{http_code}\n'
# => 接続がタイムアウト/失敗する (iptables OUTPUT DROP)

span の確認: OTEL Collector の debug exporter ログ、または Jaeger / Grafana Tempo 等で service.name = nginx-agent-boundary の span を検索し、boundary.direction (ingress/egress) 属性と宛先ホストが記録されていることを確認します。

kubectl logs -n agent-boundary deploy/otel-collector | grep -A5 'forward_proxy'

運用

監査ログの活用

• NGINX は otel_trace on を設定した location を通過するリクエストごとに OTEL span を 1 本生成します。
• span には HTTP semantic conventions 準拠の属性 (メソッド・宛先・ステータス等) が自動付与され、「どの agent がいつどの宛先へ通信したか」を再構成できます。
• OTEL Collector が span を Jaeger / Grafana / SIEM に転送します。CNCF 記事では監査ログとしての永続化・観測基盤への連携・SIEM 連携の 3 系統が挙げられています。

• 運用フロー: 追いたい agent の service.name / トレース ID で Jaeger を検索し、経路上の span から宛先ホスト・ステータスコード・タイムスタンプを確認します。
• SIEM 連携時は Collector の exporter で SIEM 向け OTLP/HTTP または Kafka などのパイプラインに転送します。

allowlist の更新運用

• allowlist を ConfigMap 化し、変更後に NGINX Pod を reload (nginx -s reload またはローリング再起動) して反映します。
• allowlist の変更は GitOps で管理し、Pull Request → レビュー → 自動デプロイの経路を通すことで「誰が・いつ・なぜ許可を広げたか」の証跡を Git 履歴に残せます。
• allowlist はアプリケーションコードと切り離して管理し、agent の実装変更なしに宛先を絞り込み・拡張できる状態を保ちます。
• nginx -s reload は graceful reload (旧 worker が処理中の接続を捌き切ってから新 worker に切り替わる) のため、reload 自体は原則ダウンタイムを生みません。ただし Pod のローリング再起動で反映する構成では切り替え中の接続断があり得るため、監査対象の通信を止めない運用にするなら graceful reload を優先します。

span の保持・サンプリング

• 監査目的では全リクエストの記録が前提のため、境界となる NGINX 側は基本 otel_trace on (全件トレース) を既定にします。
• 母数が多く保持コストが問題になる場合は otel_trace に変数を渡すことで比率サンプリングができます。

split_clients "$otel_trace_id" $ratio_sampler {
    10%  on;
    *    off;
}

location / {
    otel_trace $ratio_sampler;
}

• 「異常系だけは絶対に取りこぼさない」要件がある場合は、境界の NGINX 側は head-based (全件 on が基本) で出し、Collector 側の tail_sampling processor でエラー/特定宛先の span を優先的に長期保存する構成が現実的です。

性能監視

• NGINX 公式の OpenTelemetry 連携ガイドは、ngx_otel_module 有効時の request processing overhead を 10〜15% に収まるとし、他の OpenTelemetry 実装では最大 50% の性能劣化があり得ると比較しています。
• CNCF 記事では GPU 使用率グラフを用いて、境界導入後も agent のワークロード実行が feasible であることを示していますが、NGINX プロキシ自体の詳細なオーバーヘッド実測値は記事内に明記されていません。
• 運用では NGINX の request 処理レイテンシ (p50/p95/p99) を境界導入前後で比較し、otel_exporter の batch_size / batch_count / interval を調整して Collector への送信頻度とバッファリングのバランスを取ります。

可用性

• forward proxy を 1 台構成にすると、NGINX 障害時に全 agent の egress が止まる単一障害点になります。
• CNCF 記事はこの点を「proxy-based enforcement introduces another operational component that must be secured and monitored」として運用上の懸念に挙げていますが、具体的な冗長化手段までは踏み込んでいません。
• HA (High Availability) 構成は NGINX 公式ドキュメントの keepalived パターンが利用できます。

• OTEL Collector 側も単一インスタンスでは同様に SPOF (Single Point of Failure) となるため、agent 型 (各ノードに配置) または gateway 型 (複数レプリカ + ロードバランサ) でスケールし、span 欠落を防ぎます。

ベストプラクティス

defense-in-depth の 1 層として位置づける

• CNCF 記事は本アーキテクチャを「it should be viewed as one layer in a broader defense-in-depth strategy alongside identity, policy, runtime security, and application-level guardrails」と明言しています。
• ネットワーク境界だけで agent の安全性を担保しようとせず、identity (認証・認可)・policy・runtime guardrails・application-level guardrails と重ねて設計します。

boundary as architecture を壊さない運用

• 境界は「agent が守ってくれることを期待するポリシー」ではなく「構造的に迂回できない仕組み」であるべきです。iptables で forward proxy 以外への全 egress を drop し、agent プロセスに迂回経路を残さない構成を取ります。
• agent コンテナ/Pod に新しい sidecar やツールを追加する際、その通信経路が iptables ルールをバイパスしていないか都度確認します。
• デバッグ目的で一時的に iptables ルールを緩めた場合、作業後に必ず revert し、GitOps 管理下の状態と実機の設定に差分が残らないようにします。
• sidecar / init container パターンで network namespace レベルに egress 強制を仕込み、アプリケーションコードの変更や新規コンテナ追加でも境界が自動的に効く構成を維持します。

最小許可 (deny-by-default)

• allowlist は「明示的に許可した宛先以外は全て拒否」の deny-by-default を既定とします。
• 宛先は業務上必要な最小セットに絞り、広範なワイルドカード (*.example.com のような広すぎるパターン) は避けます。
• 新規宛先の追加は allowlist への明示的な追記を必須にします。
• 保証範囲の限界: forward proxy が縛れるのは HTTP(S) egress です。DNS・ICMP・生ソケットなどの帯域外チャネルは本アーキテクチャの保証範囲外であり、iptables で DNS を社内リゾルバに限定する・IPv6 を塞ぐ・NetworkPolicy を併用するなど、別の縮小策を重ねます。

監査証跡は通信境界から取る

• 監査ログの正とする発生源は、agent のアプリケーション内ログではなく NGINX の span (通信境界) です。
• アプリケーション内ログは agent の実装・プロンプト経由で改変され得る一方、境界の span は agent コードから独立して生成されるため、agent 自身による記録の改竄・欠落から影響を受けません。
• アプリケーション内ログは agent の意思決定コンテキストの補助情報として併用し、監査の一次証跡としては境界の span を採用します。

TLS 可視性

• CNCF 記事の構成は inbound 側で「terminates TLS, and forwards requests for the agent」と TLS 終端を行っていますが、outbound (agent → 外部 API) 側をどちらの方式にしているかは記事内で明示されていません。監査で通信内容 (payload) まで見たい場合は MITM 型の TLS 終端が必要になる点に留意してください。

OTEL Collector のセキュア化・監査ログ改竄防止

• 送信側 (NGINX の otel_exporter)・受信側 (Collector receiver) の両方で TLS/mTLS を設定し、trusted_certificate で CA を明示します。mTLS を有効にしないと Collector の receiver は任意のクライアントからデータを受け付けます。
• 長期保存は Amazon S3 Object Lock、Azure Immutable Blob Storage、GCS の保持ポリシーなど append-only ストレージを使うと、書き込み後の改変・削除を防止できます。
• span に含まれる可能性のある機微情報 (トークン・個人情報等) は Collector の processor で属性削除・マスキング・正規表現変換を行い、監査ログとして保存する前に最小化します。

採用前チェックリスト

トラブルシューティング

まとめ

AI エージェントの外部通信は、プロンプトやアプリ内ポリシーだけで縛るよりも、NGINX forward proxy と iptables で通信経路を単一化し、OpenTelemetry span を境界で取得する構成にすると監査可能性が上がります。一方で、HTTPS CONNECT の実装方式、DNS・IPv6・Collector の保護、allowlist の GitOps 運用を設計に含める必要があります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 公式ドキュメント
  • Network boundary for AI agents using NGINX and OpenTelemetry (CNCF Blog, 2026-07-08)
  • Module ngx_otel_module (NGINX docs)
  • OpenTelemetry dynamic module 管理ガイド (docs.nginx.com)
  • HTTP CONNECT proxy (docs.nginx.com)
  • Installing NGINX Open Source (docs.nginx.com)
  • OpenTelemetry Collector Architecture
  • OpenTelemetry Collector Configuration
  • Collector deployment (OpenTelemetry)
  • W3C Trace Context
  • Semantic conventions for HTTP spans (OpenTelemetry)
  • Traces (OpenTelemetry Concepts)
  • Sampling (OpenTelemetry)
  • Handling sensitive data (OpenTelemetry)
  • Configuring Active-Active HA with keepalived (NGINX)
  • Istio / Egress Gateways
  • How Linkerd Uses iptables to Route Kubernetes Traffic
• GitHub
  • ngx_otel_module GitHub (nginx/nginx-otel)
  • ngx_http_proxy_connect_module (chobits)
• 記事・ブログ
  • Using NGINX as an AI Proxy (NGINX Blog)
  • AI Egress Proxy: Control What Your Agents Send (PipeLab)
  • How to Use an External HTTPS Proxy with Istio (OneUptime)
  • How to Build DNS-Based Egress Policies in Cilium (OneUptime)
  • eBPF for AI Agent Enforcement (ARMO)
  • MCP Gateway Comparison: 10 Tools for Governing AI Agent Access (Zuplo)
  • What is an MCP Gateway? (Kong)
  • How to Build an Immutable Audit Log Pipeline Using OpenTelemetry (OneUptime)
  • Audit Logging for OpenTelemetry Telemetry Access (OneUptime)