Your AI Gateway Governs One Protocol. Your Developers Use Three.
AI gateways solved keys, routing and spend visibility — and they were right to. But a coding agent spends most of its day calling your mail, your calendar and your CRM, and no gateway is in that path. Here is what governing all three surfaces looks like, and why the vendor key never reaches a laptop at all.
AI adoption is ramping up everywhere, and most organisations are now standardising on a tool of choice — Claude Code, Codex, Cursor. That standardisation is healthy. It also arrives with a set of questions that nobody asked two years ago:
- How do you manage API keys, and stop your source code leaking into a prompt?
- How do you audit any of this, in a way that survives a real audit?
- How do you allow or disallow particular tools and particular models?
- How do you keep data inside the EU, and prove that you did?
- How do you give agents access to your standard set of tools — mail, calendars, tickets, CRM — without handing out credentials for each?
And, increasingly the one that reaches the board first: how do you manage cost? Models are not getting cheaper, the frontier ones are getting more expensive, and the whole industry is shifting from plan-based pricing to usage-based. A per-seat line item you could forecast is becoming a consumption line item you cannot.
Enter the AI Gateway
What if you could solve all of that at once, and get an escape hatch on cost while you were at it?
This is exactly where AI gateways come in, and they are a genuinely good idea. They hold your keys so developers never see them. They route across providers, so you choose which model runs and when — including falling back to something cheaper. They apply guardrails. They give you spend insight instead of an undifferentiated invoice. You can self-host one or use a hosted one in a fraction of the time it takes to build anything yourself.
If your problem is "govern our model traffic", a gateway solves it. We are not going to pretend otherwise.
Where Gateways Stop
Here is the catch. A gateway governs one protocol: the model call.
Watch what someone actually does with a coding agent for an afternoon. They ask it to read a ticket, check who is on call, pull the failing deployment's logs, draft a reply to the customer who reported it, and drop fifteen minutes in a calendar to talk it through. Perhaps two of those are model calls. The rest are tool calls against systems that hold your real data — and a gateway is not in that path. It cannot see them, and it cannot govern them.
That leaves three surfaces, not one.
The model
Which models, for whom, at what spend. Genuinely solved by the current generation of gateways, and the reason they took off.
The tools
Which of your systems an agent can reach, using whose credentials, and what leaves the building in the arguments. This is where your customer list lives — and where most gateways stop.
The network
What the sandbox running that tool is allowed to talk to, enforced somewhere the workload itself cannot reach or reconfigure. Without it, a compromised tool is an open egress route.
Govern the first and you have a compliance story. Govern all three and you have a security boundary. The difference is not a feature checkbox — it is an architecture, because the three surfaces have to share one credential model, one policy and one audit trail, or the seams between them become the attack.
What This Looks Like Per Team
The same architecture reads differently depending on who is asking.
Exposing Your Standard Toolset — And Enforcing Its Use
This is the part that changes what people can do, rather than what they are stopped from doing.
Most organisations have already decided which systems are the official ones: this mail platform, that ticket tracker, this CRM. The problem with agents is that every developer otherwise wires up their own connection to each — a personal token here, a side-loaded tool server there — and now your standard toolset has a shadow copy per laptop.
With Scrydon, an administrator enables an integration once, for the organisation, and every developer's agent picks up those tools on its very next turn. No per-developer OAuth dance, no key distribution, no window where half the team has the capability and half does not. Revocation is the same gesture inverted, and it takes effect immediately — the enabled-product set is deliberately read fresh on every single call rather than cached.
| Category | Available through the governed catalog |
|---|---|
| Email & calendar | Outlook mail, Microsoft Calendar, Gmail, Google Calendar |
| Collaboration | Microsoft Teams, Atlassian, GitHub |
| Business systems | Salesforce, SAP, Microsoft Dynamics |
| Observability | Grafana, SigNoz |
| Model vendors | Anthropic, OpenAI, Google, Bedrock, Azure AI Foundry, Mistral |
| Local & self-hosted inference | vLLM, Ollama, any OpenAI-compatible endpoint |
| Internal systems Your own | A typed authoring SDK; the runtime does not privilege our integrations over yours |
The agent acts as the person, never as a super-user
This is the single most important property in this post, so it is worth stating plainly and repeating.
When an agent reads a calendar, it uses that developer's own delegated credential. Not a service account with organisation-wide reach. Not a shared integration user. The agent can do exactly what its human can do, and nothing more.
That is enforced structurally rather than by convention: the principal's identity is part of the internal cache key for credential resolution, precisely so that a cached lookup can never hand one person's delegated access to somebody else. If your CFO's assistant asks an agent to check a calendar, it sees the calendars the assistant can see.
Most breach stories in this category are the opposite shape — one over-privileged integration account that every agent shares, and one prompt injection away from reading everything.
Onboarding Users as Easily as Possible
None of the above matters if the governed path is more annoying than the ungoverned one. So, concretely, this is the whole thing:
bunx @scrydon/cli login https://auth.your-company.com
bunx @scrydon/cli router setup
The first opens a device-authorisation flow — the CLI prints a short code, the developer approves it in a browser where they are already signed in. The second mints an environment-scoped key and prints the lines to paste:
export ANTHROPIC_BASE_URL="https://auth.your-company.com/api/router"
export OPENAI_BASE_URL="https://auth.your-company.com/api/router/v1"
export GOOGLE_GEMINI_BASE_URL="https://auth.your-company.com/api/router"
export ANTHROPIC_API_KEY="scry_..."
That is it. Claude Code, Codex, Gemini CLI, Cursor, Aider, and anything speaking Azure OpenAI or Ollama now run governed. No plugin, no wrapper binary, no forked client, nothing about how they work changes.
What changed is on the other side of the connection: every turn is attributable to the person who made it, model policy is enforced at dispatch, the company toolset is already connected, and cost is attributed per developer instead of arriving as one number at the end of the month.
And a vendor key never reaches a laptop at all. Not vaulted — never issued.
The endpoint those two commands point at is the Scrydon LLM Router, and that page is the implementation rather than the pitch: which API dialects it accepts, how a router key resolves to a person through your own identity provider, and what runs at dispatch before the request reaches a vendor.
Scrydon Protects Your Data. There Is No Way Around It.
That heading is meant literally. These controls are not request fields, not client settings, and not something a caller can influence. They run on every call, on a path the request cannot route around.
Data-loss prevention runs inline on prompts and responses, and it cannot be steered from the outside: applications cannot send a scan context, a purpose, a clearance, or an audit-suppression flag on the wire. The platform derives all of them from the verified identity. Turning it off is not a toggle — it requires a time-boxed exception with a stated reason and an expiry no more than 90 days away, and a server-side job automatically reverts the policy when that window closes and records that it did.
Every sandbox running a tool gets a non-cooperative enforcer alongside it, doing DNS-aware firewalling with live certificate-name verdicts against an immutable policy snapshot. The workload cannot alter the firewall, DNS, or decision path — it is not a library the code calls, it is a boundary the code is inside. Untrusted code runs in a fresh microVM with its own kernel, not a shared-kernel container.
The audit trail is not written best-effort after the fact. It settles durably before the response finishes — one hash-chained record covering the prompt, the tool call, and the model that made it, because they all went through the same pipeline rather than three disconnected systems.
The whole platform self-hosts, including EU-only and air-gapped deployments. The governed pipeline, the tool catalog, the sandboxes and the audit store are all yours, in your region, under your keys.
On top of these sit clearance-gated model eligibility, an allowlist enforced at dispatch, spend caps, and per-organisation isolation tiers.
How to Compare
If you are running a bake-off, these are the rows that separate the categories. We have deliberately not named products — the point is the shape of what each category covers, and any specific vendor's roadmap will have moved by the time you read this.
| Capability | Routing library | AI gateway | Scrydon |
|---|---|---|---|
| Model routing, fallbacks, A/B | Yes | Yes | Yes |
| Cost attribution and spend caps | No | Yes | Yes |
| Prompt and response DLP | No | Usually | Yes, non-optional |
| Keys hidden from developers | No | Vaulted | Never issued |
| Your standard toolset, centrally enabled | No | Rarely | Yes, 95 tools |
| Tools act as the individual user | No | No | Yes, delegated |
| Sandboxed tool execution | No | No | Yes, microVM |
| Network egress control on tool calls | No | No | Yes, enforced |
| One audit chain across models and tools | No | Models only | Yes |
| EU-only or air-gapped self-hosting | Self-built | Sometimes | Yes |
The distinction is not that gateways are bad. It is that a gateway sits in front of your credentials, and can govern the model call. It cannot govern what happens after the model decides to call your CRM, because it is not in that path.
What This Means, and What Comes Next
The tax for all of the above.
Their existing tool, unchanged.
Every agent picks it up on its next turn.
Two properties customers measure first, so they are worth stating. Prompt caching still works — an agent re-sends its whole context every turn, so we forward cache breakpoints and report cache-split tokens back; a router that silently breaks caching is one you measure once and switch off. And the model is never silently substituted: if a request names a model, that model runs or the request fails loudly. Substitution happens only inside a route an administrator defined and a developer explicitly chose.
What is next is mostly cost. Route policies — where an administrator defines a virtual model that escalates from a cheap model to a strong one only when the work warrants it — are new, and their signals are still calibrated on synthetic rather than production traffic. That is the lever we expect to matter most as usage-based pricing bites.
If you are currently choosing between handing out vendor keys and telling your engineers no, there is a third option.
Start the conversation
Start the conversation, schedule a call with Xavier.
Prefer to write? Email hello [at] scrydon.com and we will get back to you.