Forge tunneling: giving agents safe access to private APIs

The API your agent needs is bound to loopback on another machine. Forge tunnels the tool call there — default-deny, on camera.

Rysh Forge turns an OpenAPI spec into agent tools. Great — until you hit the version of the problem every real company has:

The API your agent needs isn't reachable from where the agent runs.

It's bound to 127.0.0.1 on a box in the office. It lives in a VPC. It's behind a bastion host. It's the internal admin service that — correctly! — has no public ingress at all. Your agent runs on your laptop; the API answers only to localhost on a machine three networks away.

The traditional menu of fixes is grim:

• Expose the API. Congratulations, your internal service now has a public attack surface because a chatbot wanted to call it.
• Copy credentials around. Now the laptop has prod keys, and so does the agent's context window.
• SSH port-forward and pray. Works for you, once, manually. Doesn't compose into "agents across the team use this daily," and gives you zero say over which endpoints flow through it.
• Don't integrate. The default outcome. The agent stays a very confident intern with no keycard.

The rysh answer: the tool call travels, not the API

Forge tunneling takes a different shape. Two rysh sessions, connected through a rysh upstream server:

• Session B runs on the machine where the private API is actually reachable — even if it's reachable only on loopback.
• Session A is where you (and your agent) work.
• Forge-generated tools in session A don't try to reach the API directly. The tool call is forwarded over the upstream to session B, executes there — where localhost means the right localhost — and the response travels back to the agent.

The API never gets exposed. No new ingress, no VPN sprawl, no credentials copied to the laptop. The only things that cross the network are the list of operations you shared and governed tool invocations between two sessions you own — and the upstream in the middle can be your own self-hosted rysh-server, on your infra.

From the agent's point of view, nothing special happened: it called a tool, it got a result. From your network's point of view, nothing changed at all: the private API is still private.

Default-deny, or it doesn't count

Reachability without control is just a hole with extra steps — so the tunnel is default-deny. Nothing is forwardable until you explicitly share the API. Set an allow list and only the operations it names will execute on the remote side; with no allow list, reads flow and writes are refused; a block list always wins. Everything else is refused at the seam, before it runs.

We filmed a real run of this — two live sessions, tunneling over a local rysh-server upstream — and the demo deliberately includes the failure case, because the failure case is the feature:

• The agent calls an allowlisted endpoint → the call tunnels to the remote session, executes against the loopback-bound API, and the response comes back into the pane.
• The agent calls an endpoint that isn't on the allowlist → denied. On camera. No forward, no execution, a refusal at the boundary.

And the proof that no clever routing trick was involved: the target API in that run was bound to loopback, and the calling session had no spec and no integration for it — only proxy tools whose one path is a request over the upstream to session B. Both sessions ran on one machine in that recording; what makes it work is that the call executes inside session B, through the tunnel.

Governance comes along for the ride

Because the tunnel carries tool calls — not raw packets — governance travels with them:

• Visible. The call and its result render in the pane like any other tool call. A teammate watching a shared pane sees the agent's remote interactions in the open.
• Gated. Tunneled calls skip the per-call approval prompt; the gate is the owner's policy — allow list, block list, writes refused by default — enforced on the owner's side before anything executes.
• Bounded. A tunneled call can only come from a session connected to the same upstream workspace — not an anonymous request appearing in an API log from nowhere.

This is the difference between "the agent has network access" and "the agent has the operations you shared, executed on the machine you chose."

What this unlocks

• Laptop agent, datacenter reach. Develop against the internal API from anywhere, with the calls executing where they're allowed to.
• One teammate holds the access; the team's agents hold none. Session B runs where access already legitimately exists. Nobody else's machine gains standing credentials.
• Demos and support against real systems, without exposure. Point session B at the environment; let the agent in session A operate at arm's length, allowlist-scoped.
• The AI-native path for the systems you'd never expose. The services that will never get public ingress are exactly the ones agents need most. Tunneling is how they participate without changing their security posture.

Honest scope

• Facts above — two-session tunneling over a local rysh-server upstream, the allowlist denial, the loopback-bound target — are from a real recorded run, not a mockup.
• The tunnel governs which endpoints execute; treat response content with the same care you'd treat any API response an agent reads. Don't put secrets in API responses you feed to any model, tunneled or not.
• rysh runs on Claude — bring your own Anthropic key. Provider layer pluggable.
• rysh is open-core — the CLI is Apache-2.0, the server (which runs the upstream) is proprietary. Your infra, your keys, your data.
• Forge ingests OpenAPI, GraphQL and gRPC — GraphQL introspects live over HTTP, gRPC over server reflection. Unary and server-streaming gRPC methods are supported; client-streaming and bidirectional methods are skipped at ingest rather than exposed as unary tools that fail when called. The run recorded above is the OpenAPI path.

Got an internal API your agents should reach but must never expose? That's the design-partner conversation we most enjoy. Bring the gnarliest network diagram you have. → rysh.ai/design-partner

Companions: Rysh Forge: point it at an OpenAPI spec · Every tool call visible