Governed LLM gateway

A controlled layer between enterprise applications and multiple model providers, so access, routing and policy are decided in one place instead of separately in every application.

Organisation
Salesforce / MuleSoft
Period
2025 – Present
Area
Agentic AI infrastructure

Context

Enterprises rarely settle on a single model provider. Teams adopt whichever model suits their problem, and each integration arrives with its own SDK, credential, error semantics and streaming format.

The problem

Without a common layer, provider choice becomes an application-level decision replicated dozens of times. Credentials spread across services, usage becomes impossible to attribute, and changing a provider means changing every caller. Governance turns into a review meeting instead of something the system enforces.

Constraints

  • A gateway sits on the critical path of every model call, so any latency it adds is paid for by every single request.
  • Streaming responses cannot be buffered to be inspected; policy has to work on a response that is still arriving.
  • Provider APIs differ in authentication, error semantics, token accounting and streaming format.
  • Existing callers must keep working; governance cannot be introduced as a breaking change.

My contribution

Shared ownership stated as such. Nothing here claims sole authorship of a platform.

  • Contributed to gateway capabilities covering governed provider access, model and provider routing, and organisation-level policy enforcement.
  • Worked on request-policy execution and model-based behaviour overrides within the gateway's policy model.
  • Worked on usage-governance and cost-attribution paths through the gateway.

Approach

  1. Treat the provider as an implementation detail. Callers address a logical model; the gateway resolves that to a concrete provider, credential and endpoint at request time, which is what turns routing and failover into a configuration change instead of a code change.

  2. Express governance as composable policies over the request lifecycle, not as branching logic buried inside the proxy. Each policy has a narrow contract, and the order in which they run is itself configuration.

  3. Keep the streaming path first-class. Accounting and termination must work on a response that is still being produced, so usage is recorded from what was actually delivered, not from what was asked for.

Decisions that mattered

The ones with a real cost on the other side.

Abstraction that does not hide operations

A provider abstraction is only worth having if it still tells operators what they need to know: which model actually served the request, which provider failed, what the call cost. Hiding all that makes the layer easier to describe and a lot harder to run.

Policy ordering as configuration, not convention

Access decisions must precede anything expensive, and accounting must follow the response. Encoding that ordering explicitly keeps the guarantee inspectable instead of implicit in the call sequence.

Outcome

A governed platform layer through which applications and agents reach language models without each one managing its own provider integrations, with access control, routing and usage accounting applied in one place.

What generalises

  • Governance built into the path is enforceable; governance added afterwards is advisory.
  • An abstraction should simplify usage without concealing operational reality.