Envoy AI Gateway Kini Agent Router: Apa yang Berubah di 1.2

Saya membuka pengumuman rename dengan harapan menemukan panduan migrasi. Yang saya temukan justru sebuah janji: manifest kemarin tetap berlaku besok. Untuk gateway yang menyimpan API key provider dan berada di depan tool MCP, kalimat tidak ada yang berubah adalah kalimat yang paling kurang saya percaya, jadi saya membaca release notes 1.2 baris demi baris untuk mencari apa yang tidak disebut.

Post ini membahas rename dan perpindahan ke foundation, janji stabilitas 1.0, desain identitas per user dari bulan Juli, serta perubahan 1.2 pada otorisasi MCP dan credential multi-team. Saya tidak menjalankan 1.2 di cluster untuk post ini. Semuanya dibaca dari pengumuman, release notes, dan docs proyek itu sendiri, dan bila saya merangkai config sendiri, saya menyebutkannya.

Rename hanya mengubah nama, bukan permukaan API

Pada 9 September 2026 para maintainer mengumumkan bahwa Envoy AI Gateway menjadi Agent Router, efektif 10 September. Ringkasan mereka hanya tiga kalimat pendek: kode sama, maintainer sama, rumah baru. Tabel ini memuat apa yang bisa saya konfirmasi dari pengumuman dan dari release notes 1.2.0.

Dampak praktisnya jelas. Tidak ada yang perlu diedit di repository GitOps karena rename, dan perintah Helm di pipeline Anda tetap jalan. Yang perlu dirapikan adalah dokumentasi dan script yang menaut ke repository atau website lama. Redirect menutupinya untuk saat ini, tetapi link yang Anda kendalikan lebih baik daripada redirect yang Anda andalkan.

Kenapa pindah ke foundation, dan foundation yang mana

Linux Foundation mengumumkan Agentic AI Foundation pada 9 Desember 2025 dengan tiga proyek pendiri: Model Context Protocol dari Anthropic, goose dari Block, dan AGENTS.md dari OpenAI. Anggota platinum saat peluncuran adalah Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, dan OpenAI. Tujuan yang dinyatakan adalah rumah yang netral dan terbuka untuk agentic AI.

Post rename menyebut proyek ini bermula sebagai sub-proyek Envoy di CNCF dan kini menjadi proyek mandiri di bawah Agentic AI Foundation, yang mereka sebut rumah bagi agentic stack. Alasan yang lebih rinci tidak diberikan, jadi kalimat berikut adalah inferensi saya: gateway yang tugas terpentingnya lalu lintas MCP kini berada di foundation yang sama dengan MCP itu sendiri. Ia tetap dibangun di atas Envoy dan Envoy Gateway, jadi data plane-nya sama dengan yang sudah Anda jalankan.

Sebuah tulisan berbahasa Korea menyebut Agent Router sebagai gateway kedua di foundation tersebut, di samping agentgateway yang data plane-nya ditulis dengan Rust, dan mengatakan bedanya, Agent Router adalah control plane yang mengonfigurasi Envoy. Saya anggap itu perbandingan pihak ketiga. Satu klaimnya bisa saya cocokkan dengan docs resmi: CEL untuk otorisasi bisa membaca argumen tool lewat request.mcp.params.

Apa yang dijanjikan 1.0 sebelum rename

Versi 1.0 dirilis pada 23 Juni 2026 sebagai rilis stabil pertama. Lima CRD, yaitu AIGatewayRoute, AIServiceBackend, BackendSecurityPolicy, GatewayConfig, dan MCPRoute, disajikan di v1beta1, dan komitmennya lugas: API tidak akan dipatahkan kecuali ada masalah keamanan kritis. Post 1.0 menghitung 16 provider AI, MCP gateway lengkap, dan dukungan multimodal.

Baca janji itu dengan teliti. Janji tersebut mencakup bentuk API, sedangkan beberapa breaking change di 1.2 adalah perubahan perilaku dan validasi di dalam bentuk yang stabil: aturan CRD yang kini menolak sebuah ekspresi, policy yang kini menghormati namespace. Post 1.0 tidak memuat angka benchmark dan tidak ada matriks kompatibilitas Envoy Gateway atau Kubernetes, jadi batasan versi yang sebenarnya ada di release notes 1.2.

Identitas per user: desain bulan Juli di balik pekerjaan 1.2

Post 5 Juli dimulai dari kegagalan yang dialami setiap rollout MCP. Tim memulai dengan satu service account bersama per tool, disimpan sebagai Kubernetes Secret, sehingga komentar terposting atas nama bot, user mengakses data yang tidak bisa dijangkau akun mereka sendiri, dan RBAC di hilir terlewati tanpa error yang terlihat. Post itu memisahkan dua pertanyaan: apakah gateway mempercayai request, dan identitas siapa yang dilihat backend. Tabel ini adalah jawabannya untuk pertanyaan kedua.

Header forwarding bersifat opt-in. MCP proxy membuat request upstream baru untuk setiap panggilan dan tidak meneruskan header client secara default; backend hanya menerima header yang tercantum di forwardHeaders-nya. Saat fan-out, misalnya panggilan tools/list, tiap backend tetap hanya mendapat header yang ia pilih. Ada satu jebakan yang dijelaskan: credential yang disuntikkan securityPolicy sebuah backend menimpa header terusan dengan nama yang sama, jadi beri identitas user yang diteruskan header tersendiri.

Trade-off-nya dinyatakan jelas di post itu. Passthrough tidak menyimpan token vault, jadi tidak ada yang perlu disimpan, dirotasi, atau dibobol, tetapi revocation tidak terpusat karena platform client yang memegang credential. Gateway juga tidak memvalidasi personal access token; backend yang melakukannya, jadi pertahankan autentikasi masuk di pintu depan atau gateway menjadi open proxy. Token exchange saat itu masih direview dan tetap ada di daftar what's next 1.2.

Hardening 1.2: otorisasi MCP yang fail closed

Pengumuman 1.2 mengelompokkan pekerjaan MCP di bawah satu gagasan: taruh tool di depan user sungguhan. Aturan otorisasi hanya membaca claim JWT dari token yang sudah diverifikasi Envoy, dan issuer harus sama dengan yang dikonfigurasi. Kebijakan CEL yang error saat runtime kini menolak panggilan, bukan dilewati. Session terikat ke user yang memulainya, sehingga user lain tidak bisa memakai ulang session ID-nya. Dan Helm chart membuat session encryption seed acak, bukan membawa default bersama.

Release notes menunjukkan di mana ini terasa. Claim, scope, dan subject session hanya berasal dari JWT yang diverifikasi Envoy, jadi tanpa securityPolicy.oauth semuanya kosong. Validasi CRD baru menolak CEL otorisasi atau backendSelector yang merujuk auth.jwt pada route semacam itu. Route yang sudah ada mempertahankan spec tersimpan, tetapi setiap update berikutnya ditolak, lookup claim gagal lalu menolak, dan pengecekan scope bernilai false. Konfigurasi di bawah adalah rangkaian field dari docs dan notes yang saya susun sendiri, bukan contoh yang dipublikasikan.

apiVersion: aigateway.envoyproxy.io/v1beta1
kind: MCPRoute
metadata:
  name: issues
  namespace: default
spec:
  parentRefs:
    - name: envoy-ai-gateway
      kind: Gateway
      group: gateway.networking.k8s.io
  path: "/mcp"
  prefixMode: Never            # clients see search_issues, not github__search_issues
  securityPolicy:
    mergeType: StrategicMerge  # keep gateway-level rate limits and ext-auth in force
    oauth:
      # Must equal the identity provider's iss claim byte for byte,
      # including a trailing slash. A mismatch is a 401 after 1.2.
      issuer: "https://keycloak.example.com/realms/master"
      audiences:
        - "https://api.example.com/mcp"
      protectedResourceMetadata:
        resource: "https://api.example.com/mcp"
        scopesSupported: ["profile", "email"]
    authorization:
      rules:
        - source:
            jwt:
              scopes: ["read"]
          target:
            tools:
              - backend: github
                tool: search_issues
          # An erroring expression now DENIES. Guard the claim with has()
          # so a missing claim is a deliberate no, not an accident.
          cel: has(request.auth.jwt.claims.tenant) && request.headers["x-tenant-id"] == request.auth.jwt.claims.tenant
  backendRefs:
    - name: github
      kind: Backend
      group: gateway.envoyproxy.io
      path: "/mcp"
      toolSelector:
        include: ["search_issues"]   # required for a backend in Never mode
      forwardHeaders:
        - name: Authorization        # the user's own token, when they send one
      securityPolicy:
        apiKey:
          secretRef:
            name: github-service-key
          injectionPolicy: IfNotPresent  # shared key only if the header is absent

Opsi kompatibilitas client masing-masing punya aturan. Dengan prefixMode Never, backend wajib mencantumkan tool-nya di toolSelector.include, dan dua backend mode Never yang menampilkan nama tool sama membuat route ditandai NotAccepted; resource selalu mempertahankan prefix. injectionPolicy IfNotPresent hanya berlaku untuk injeksi header dan tidak bisa digabung dengan queryParam. mergeType menerima StrategicMerge atau JSONMerge, dan Replace ditolak.

Banyak tim, satu gateway: credential kini butuh ReferenceGrant

Ini perubahan dengan kegagalan paling senyap. Release notes menyebut bahwa sebelum 1.2 sebagian referensi Secret, yaitu client secret Azure, file credentials GCP, dan client secret OIDC, dibaca dari namespace lain tanpa pengecekan. Untuk yang lain, seperti API key dan file credentials AWS, namespace diabaikan, sehingga referensi lintas namespace gagal atau diam-diam memakai Secret bernama sama di namespace policy itu sendiri. Kasus kedua berarti credential yang salah dipakai tanpa error apa pun.

Di 1.2 setiap tipe credential menghormati namespace. BackendSecurityPolicy hanya boleh memakai Secret di namespace lain bila namespace itu mengizinkannya lewat ReferenceGrant, dan grant yang hilang membuat policy berstatus NotAccepted. Token yang sudah terbit tetap berfungsi sampai kedaluwarsa, jadi kegagalan bisa muncul berjam-jam setelah upgrade. Grant yang menyebut satu objek hanya mencakup objek itu, dan pencabutan grant berlaku seketika. Manifest di bawah ini diambil dari upgrade guidance.

# Created in the namespace that OWNS the Secret (credentials),
# naming the namespace of the policy that wants to read it (ai-backends).
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-backend-security-policy-secrets
  namespace: credentials
spec:
  from:
    - group: aigateway.envoyproxy.io
      kind: BackendSecurityPolicy
      namespace: ai-backends
  to:
    - group: ""
      kind: Secret
      name: openai-api-key   # setting name limits the grant to this one Secret

Dua perbaikan kecil penting bagi tim yang sama. Credential yang dirotasi kini berlaku seketika, memperbaiki regresi 1.1.0 di mana panggilan bisa memakai key lama sampai reconcile berikutnya. Dan limit token per tenant kini dibebankan ke tenant yang benar, yang oleh pengumuman disebut sebagai alasan tenant mungkin kini melihat respons 429: limit yang sebelumnya dibebankan ke tenant yang salah kini bekerja di tempat yang seharusnya.

Apa yang rusak saat upgrade, dan bagaimana tampilannya

Post dan notes bersama-sama memberi enam gejala upgrade. Saya menyusunnya menurut apa yang benar-benar dilihat engineer on-call, karena penyebabnya jarang jelas dari gejalanya.

Jebakan GitOps mudah terlewat. Dengan helm template, chart tidak bisa mengingat seed yang dibuat, sehingga setiap render menghasilkan seed baru dan setiap sync akan mengakhiri semua session MCP. Notes menyarankan set controller.mcp.sessionEncryption.existingSecret atau nilai seed secara eksplisit.

Yang tidak bisa saya pastikan: baik post 1.0 maupun 1.2 tidak memublikasikan pengukuran biaya per request untuk pengecekan JWT terverifikasi dan evaluasi CEL. Bila panggilan tool MCP Anda punya anggaran latency, ukur di traffic Anda sendiri sebelum dan sesudah.

Yang dikerjakan hari Senin

Anggap rename bukan kejadian dan upgrade sebagai proyeknya. Berurutan:

1. Inventaris dulu: daftar semua MCPRoute, BackendSecurityPolicy, dan ReferenceGrant, lalu tandai policy yang Secret-nya ada di namespace lain dan route yang CEL-nya membaca auth.jwt.
2. Pastikan sudah di 1.1.x sebelum mulai. Pengumuman menyarankan upgrade dari 1.1.x, bukan langsung dari 1.0.x.
3. Upgrade Envoy Gateway ke v1.9.2 dan CRD Gateway API ke v1.6 terlebih dulu, dan jangan aktifkan opsi mergeBackends milik Envoy Gateway bersama Agent Router untuk saat ini.
4. Putuskan session seed: terima reconnect, pertahankan session dengan fallback seed untuk satu kali upgrade, atau buat Secret sendiri bila Anda me-render dengan helm template.
5. Perbaiki route dan tambahkan grant sebelum controller baru melihatnya: issuer yang persis, oauth di setiap route yang membaca JWT, CEL yang null-safe, satu ReferenceGrant per Secret lintas namespace.
6. Upgrade Agent Router, lalu periksa status policy untuk NotAccepted, perbarui dashboard untuk label gen_ai_backend, dan hapus Secret filter-config.yaml lama.

# 0. Inventory before touching anything
kubectl get mcproutes -A
kubectl get backendsecuritypolicies -A
kubectl get referencegrants -A

# 1. Gateway API CRDs and Envoy Gateway first (commands from the v1.2.0 notes)
helm template eg-crds oci://docker.io/envoyproxy/gateway-crds-helm \
  --version v1.9.2 \
  --set crds.gatewayAPI.enabled=true \
  --set crds.envoyGateway.enabled=true \
  | kubectl apply --force-conflicts --server-side -f -

# 2. Your own session seed, so a GitOps render does not mint a new one each time
kubectl create secret generic mcp-session-seed -n envoy-ai-gateway-system \
  --from-literal=seed="$(openssl rand -hex 32)"

# 3. Agent Router 1.2.0. Chart and image names keep the ai-gateway prefix.
helm upgrade -i aieg-crd oci://docker.io/envoyproxy/ai-gateway-crds-helm \
  --version v1.2.0 --namespace envoy-ai-gateway-system
# The existingSecret flag is my addition to the notes' command (step 2 above).
helm upgrade -i aieg oci://docker.io/envoyproxy/ai-gateway-helm \
  --version v1.2.0 --namespace envoy-ai-gateway-system \
  --set controller.mcp.sessionEncryption.existingSecret=mcp-session-seed

# 4. The late failure: a policy without a ReferenceGrant is NotAccepted
kubectl get backendsecuritypolicies -A -o yaml | grep -n NotAccepted

Lalu catat dua hal di kalender. Field lama cache_creation_input_tokens dijadwalkan dihapus di v1.3.0, jadi baca cache_write_tokens sebagai gantinya. Dan daftar what's next menyebut OAuth token exchange, CRD MCPBackend khusus, dan traffic agent-to-agent, yang semuanya akan mengubah cara Anda memodelkan identitas dan backend.

Aturan yang saya ambil: pengumuman rename memberi tahu apa yang tidak disentuh maintainer, sedangkan release notes memberi tahu apa yang mereka ubah. Agent Router 1.2 menutup celah yang tidak seharusnya ada di gateway bersama, termasuk credential lintas namespace yang senyap dan claim yang tidak diverifikasi, dan menutupnya dengan gagal secara terang-terangan. Siapkan anggaran untuk kegagalan yang berisik itu.