Ollama and Fly.io ship a gateway that hides keys from agents

Giving a coding agent a cloud model API key, and running the agent on a sandbox you do not fully control, has been an uncomfortable pair for anyone who has tried it. The key is read with env, exfiltrated through a tool call, and spent on someone else's workload before the day is out. The usual answer is to run the whole call through a gateway that holds the key, which every team has to build.

Ollama and Fly.io announced the Ollama Connector for Fly.io Sprites in a post on the Ollama blog. A Sprite is a sandbox from Fly.io, which the post describes as a full Linux virtual machine with its own disk that stays between sessions, built for coding agents. The post states Claude Code, Codex and Gemini CLI are supported out of the box, so the agent can run commands inside the sandbox.

How the Connector holds the key

The post states the Ollama API key is added to a Fly.io organisation, where Fly.io encrypts it and never returns it through the API. When code inside a Sprite calls Ollama, the call goes through a Fly.io gateway. The gateway checks which Sprite is calling and adds the key to the request. The Sprite itself only knows a gateway URL and a connection ID, which the post makes clear is the whole point: an agent in a Sprite cannot leak the key, because it never has it.

The access model is listed in three lines. New connectors block every Sprite by default. The owner chooses which Sprites have access, by label, by name prefix or all of them. Calls only work from inside a Sprite. The post names Ollama's cloud models that run through this path by name: kimi-k3, glm-5.3 and deepseek-v4.1-flash.

What the Sprite also carries for an agent

The post states that Fly.io Sprites come with a skill that tells Claude Code, Codex, Cursor and Gemini CLI about Ollama. If the Sprite has access to the connector, the agent can use Ollama models without any setup inside the sandbox. The OpenAI SDK works against the gateway with its base URL and any value for the API key field, because the gateway supplies the real one.

The example Ollama gives in the post is a fuzzing workflow with three models. A small model, nemotron-3-nano:30b, writes malformed inputs. A Sprite runs them against the program under test. A larger model, kimi-k3, inspects the crashes. The post says switching models is a change to the model field in the request.

The scope of the release

The pattern of a sandbox for coding agents has been shipping for a while, and so has the pattern of a secret-holding gateway in front of a model API. The Connector packages both and ships them with first-party support from the sandbox vendor and the model vendor at the same time, which is the release's actual contribution.

For a team running an unattended coding agent on a server, the question to ask this week is whether the host sandbox already carries a connector of this shape. If it does, the key goes into the sandbox vendor, and the agent never reads it. If it does not, this launch sets a reasonable bar for what to ask for: a per-sandbox allowlist, a key the agent never reads, and a quick path from the OpenAI SDK's base_url to an audited gateway.

Source

Ollama blog post, the Sprites product page, and the Ollama Cloud model list.