Skip to content

Enterprise & air-gapped networking

Mylonite's per-PR gate re-drives your MCP server in CI. This page covers the stdio transport, where the server is spawned as a subprocess inside the runner (from your target.yaml's command/args/env) — so there is no inbound connection to your agent. The other transports (sse, http, rest) connect outbound to a URL you supply and spawn nothing; for those, the relevant question is whether the runner can reach that URL. See target.yaml and HTTP agents. So "can CI reach my MCP server?" reduces to three questions, each with an answer.

1. Your MCP server's backend dependencies (internal DBs, private APIs)

A GitHub-hosted runner can't reach services behind your corporate gate. Options:

  • Self-hosted runner (recommended). Set runs-on to a self-hosted runner inside your perimeter — Mylonite scaffolds the workflows with a --runs-on you choose (mylonite gate --target-file target.yaml --authorize my-app --workflows --runs-on "[self-hosted, linux]"; --runs-on writes nothing without --workflows). The runner reaches your internal backends; nothing leaves the network.
  • Staging or mock backend. Mylonite tests the AI layer (system prompt, tool schemas, planning loop), not your backend data. Point target.yaml's env at a CI-reachable staging or stubbed backend — the exploit is about the agent's behaviour, so a mock DB is a legitimate gate environment.

2. The LLM provider endpoint

If you use an internal model gateway (Azure OpenAI private endpoint, an internal LiteLLM proxy, a Bedrock VPC endpoint), Mylonite routes there via LiteLLM (--model with a provider/model prefix, and the provider's api_base). With a local or small model the provider need never be public egress.

3. TLS-inspecting corporate proxy (or local AV)

This is the common case, not an "enterprise" one: a proxy or local antivirus presents a MITM certificate whose CA lives in your OS trust store but not in Python's bundled certifi bundle, so HTTPS fails with CERTIFICATE_VERIFY_FAILED. Mylonite ships truststore as a base dependency and enables it automatically, so a plain pip install mylonite trusts your OS-installed CA out of the box — no cert files, and a no-op in CI (the runner's OS already trusts standard CAs). This patches Python's ssl module process-wide (truststore.inject_into_ssl()), so it covers every outbound HTTPS call Mylonite's own process makes — the LLM provider and an sse/http/rest remote target's URL alike, since both run in-process. Escape hatches: MYLONITE_NO_TRUSTSTORE=1 (disable) or SSL_CERT_FILE=/path/to/ca.pem (point at a specific CA bundle). The legacy pip install "mylonite[enterprise]" still works as a back-compat alias but is no longer required.

A stdio target's spawned child is a separate process and gets none of this. The truststore patch lives in Mylonite's own interpreter; an npx/uvx-launched server runs its own runtime (Node's own TLS stack, a second Python interpreter, …) with its own, unpatched trust store. If that child itself calls out through the same TLS-inspecting proxy — reaching its own backend, an npm/PyPI registry on first install — declare its proxy/CA variables explicitly in the target file's env: block (NODE_EXTRA_CA_CERTS, SSL_CERT_FILE, HTTPS_PROXY, …); see the env overlay in target.yaml.

Not just GitHub

mylonite gate is a plain pip package + pytest. An air-gapped team can run the identical command in any in-perimeter CI (Jenkins, GitLab) with no GitHub dependency. Self-hosted runner + internal/local model + stdio-spawned server gives a fully in-network gate.

Where to go next