ENGINEERING

One gateway, every AI tool your team already uses

August 2026 · 4 min read

Five tools, five channels, five bills

Nobody rolled out AI at your company on purpose, not all at once. A developer pointed Claude Code at the vendor's API to get through a sprint. Someone turned on the OpenAI connector in an n8n workflow. Marketing wired a Power Automate flow to a chat completion endpoint. Finance built a Power BI report that calls a model for summarization. Support added a bot to Teams. Each decision was reasonable on its own, and each opened its own channel from a laptop or service account straight to a vendor.

That's the part that doesn't show up on any architecture diagram until something goes wrong. Five tools means five vendor relationships, five sets of credentials, and five invoices that don't sum to anything finance can read as "what we spend on AI." It also means five blind spots: if a prompt carries a customer record or a stray API key, you find out from the vendor's breach notice, not your own logs — because there are no logs. Security teams call this shadow AI, but it isn't malicious. It's what happens when every tool ships its own place to type in a key, and nobody owns the total.

The fix isn't a policy telling people to stop using these tools — they're doing real work. It's putting one thing you control between all of them and the vendor.

The pattern: one endpoint, per-key budgets, one log

Stand up a single OpenAI-compatible endpoint on infrastructure you operate, mint one key per person or per automation, and point every tool's "base URL" or "API key" field at that endpoint instead of the vendor's. The tool doesn't know or care that it's not talking to the vendor directly — the request and response shapes are the same. What changes is everything sitting behind that URL, and it's the same four things regardless of which client is asking:

• Containment. Every request terminates at your gateway before anything goes upstream — the boundary a compliance review actually wants to see, and where you can catch a stray secret before it leaves.
• Attribution. A per-key budget turns "the AI bill went up" into "this automation's cost doubled last Tuesday" — traceable to a person or workflow, not a shared number on one vendor invoice.
• Server-side model routing. Swap the model behind the gateway — a new release, a fallback provider, a cheaper model for a low-stakes flow — and no client changes. Nobody re-enters a key in seven settings panels.
• One log, not five. Every request, from every tool, lands in the same place with the same shape: who, what model, how many tokens, when — the audit trail a SOC 2 review actually needs.

None of this requires replacing any of these tools — just one setting change in each, because every one already supports a custom endpoint. Most teams just never look for that field.

The series: one setting per tool

We wrote up the exact mechanism for each tool separately, because "point it at your gateway" means a different field every time. Here's where each one lives:

• Claude Code — ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN, set before launching the CLI. Read the setup →
• Cursor — the "Override OpenAI Base URL" field under Models in settings. Read the setup →
• OpenCode — a provider block in opencode.json. Read the setup →
• n8n — the Base URL field on the OpenAI credential type. Read the setup →
• Power Automate — an HTTP action with a Bearer token, in place of a prebuilt AI connector. Read the setup →
• Power BI — a Web.Contents call inside the query that runs on refresh. Read the setup →
• Teams — a flow triggered from a channel message, calling your gateway instead of a vendor-hosted bot. Read the setup →

Every one of those is a config change, not a migration — the gateway sits underneath tools your team already picked, rather than asking them to pick new ones.

What to actually demand from the gateway

Not every "AI gateway" clears the bar. It needs to speak both protocol surfaces your tools use: the OpenAI-compatible chat completions shape (n8n, Power Automate, Power BI, most connectors) and the Anthropic Messages API shape (Claude Code, including typed SSE events for streaming and tool-call arguments inside content_block_delta chunks). A gateway that only does one leaves half your tools unsupported.

Past protocol support, three things separate a gateway that works from one that breaks under load: streaming that isn't buffered anywhere in the proxy chain — buffer it once and every terminal tool hangs waiting on tokens that already arrived; per-key budgets enforced at the gateway, not reported after the fact; and log retention you control, not retention the vendor decides for you.

LiteLLM is the honest starting point for the protocol layer — it speaks both API surfaces and handles budgets, routing, and format translation. What it doesn't do is run itself: network placement, TLS termination, and log retention are still yours to operate. LiteLLM solves the protocol; you own the infrastructure around it.

Try it on ours

Our gateway (iSol API) runs exactly this pattern on sovereign infrastructure — US$ 99/month, 14-day trial. Point any of the seven tools above at it and get one bill, one log, one place to change your mind about which model answers.

See plans →