AI Gateway: Satu Bastion Host untuk Semua API Key LLM

Bila agent AI anda berhubung dengan beberapa provider model, setiap kunci API biasanya tersebar: sebahagian dalam .env agent, sebahagian dalam skrip, sebahagian dalam sejarah chat. Semakin banyak tempat yang memegang rahsia, semakin banyak tempat yang boleh bocor.

Cadangan ini mudah: satu bastion host yang memegang SEMUA kunci, dan semua client (termasuk agent saya) hanya menerima kunci maya yang boleh dibatalkan.

Status: cadangan. Reka bentuk dan sokongan alat disahkan pada kertas, tetapi langkah pelaksanaan di bawah belum semuanya dijalankan.

Aliran

Pengguna (Telegram / CLI / Web)
        │
        ▼
AGENT  (Hermes)
   • gateway platform, skill, MCP client
   • model router → base_url menunjuk ke gateway
        │   (guna VIRTUAL KEY sahaja)
        ▼
AI GATEWAY  (bastion host)
   • LiteLLM Proxy (OpenAI-compatible /v1)
   • peti simpanan rahsia: OpenAI · Anthropic · DeepSeek · model tempatan
   • virtual key · routing · bajet · audit log
        │                        │
        ▼                        ▼
PROVIDER MODEL             SERVER MCP
 (awam + tempatan)         Notion · GitHub · Filesystem · custom

Boleh ke setup ini?

Ya. Semua komponen sumber terbuka dan serasi dengan agent saya.

Lapisan	Pilihan	Catatan
AI gateway	LiteLLM	Self-hosted, OpenAI-compatible, menyokong banyak provider
Alternatif	Portkey Gateway	Guardrails dan MCP gateway dengan pengesahan dan observability
Alternatif	Higress (berasaskan Envoy)	Cloud-native, sokongan proksi MCP
Routing	`/v1` yang OpenAI-compatible	Provider `custom` dalam agent menerima `base_url` dan `api_key`
Akses MCP	MCP client terbina dalam agent	stdio setempat atau HTTP jauh
Rahsia	env atau DB dengan `chmod 600`	Corak sedia ada

Pada sisi agent, tetapan cukup begini, dan agent tidak perlu menyimpan kunci provider asal langsung:

model:
  provider: custom
  base_url: http://<gateway>:4000/v1
  api_key: sk-<virtual-key>

Satu perkara untuk dielakkan: provider ai-gateway dalam agent saya merujuk perkhidmatan hosted milik pihak ketiga. Untuk self-hosted, guna provider custom dengan LiteLLM.

Kenapa LiteLLM

Sumber terbuka dan boleh di-host sendiri (Docker). Semak lesen untuk ciri enterprise sebelum bergantung padanya.
OpenAI-compatible, jadi alat sedia ada boleh menyambung tanpa mengubah kod.
Virtual key: setiap client mendapat kunci sendiri yang boleh dibatalkan dan dihadkan dengan bajet atau rate limit.
Rahsia di satu tempat, tidak keluar ke client.
Guardrails dan penapisan PII sebelum permintaan sampai ke model awam.
Penjejakan perbelanjaan dan audit log: siapa guna apa, dan berapa kosnya.
Menyokong model tempatan (contohnya Qwen3-8B di VM sendiri) selain provider awam.

services:
  litellm:
    image: ghcr.io/berriai/litellm:<pin-a-version>   # elakkan 'main-latest' di production
    ports: ["4000:4000"]
    volumes:
      - ./config.yaml:/app/config.yaml
      - ./litellm.db:/app/litellm.db
    env_file: .env     # OPENAI_API_KEY, ANTHROPIC_API_KEY, DEEPSEEK_API_KEY ...

Alternatif

Alat	Kelebihan	Bila guna
Portkey Gateway	Banyak guardrail, MCP gateway dengan auth, latensi rendah	Mahu pengurusan MCP server dan guardrail yang kuat
Higress	Berasaskan Envoy, natif Kubernetes, proksi MCP	Sudah ada Kubernetes dan mahu gateway setahap infra
Kong AI Gateway	Ekosistem plugin enterprise	Sudah guna Kong
Gateway hosted (Vercel AI Gateway)	Tiada operasi	Tidak mahu menyelenggara server, tetapi kunci berada pada pihak ketiga

Postur keselamatan

Semua API key hanya dalam .env (chmod 600) pada bastion; tidak pernah dalam chat, log atau git.
Client (agent, alat) hanya menerima virtual key.
Server MCP berjalan setempat (stdio) pada hos agent, jadi data tidak keluar ke model.
Audit log merekod setiap permintaan: siapa, model apa, berapa token, berapa kos.
Guardrails menyunting corak PII dan kunci sebelum permintaan sampai ke model awam.
Rangkaian: gateway hanya bind ke localhost atau rangkaian peribadi, tidak terdedah ke awam kecuali sengaja.

Pelan pelaksanaan

Deploy LiteLLM (pada hos agent atau VM khusus) melalui Docker.
Letak semua API key dalam .env gateway.
Cipta virtual key untuk agent.
Ubah model.base_url agent supaya menunjuk ke gateway.
Uji tukar model antara OpenAI, Claude, DeepSeek dan model tempatan, semuanya melalui gateway.
Sahkan penjejakan perbelanjaan dan audit log berfungsi.
(Pilihan) Tambah MCP gateway untuk server MCP jauh.

Satu kaveat dalam reka bentuk: bastion menjadi titik kegagalan tunggal dan sasaran bernilai tinggi. Kunci tidak lagi tersebar, tetapi sekarang semuanya berada di satu tempat, jadi akses kepada host itu mesti diketatkan dan dipantau.