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 thing that crosses the network is a governed tool invocation 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 it's explicitly allowed. You enumerate which endpoints the remote side will execute; everything else is refused at the seam.

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 streams 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 on the remote machine. There was no path to it from the calling machine — not over the LAN, not over anything. The only way a response could exist is that the call executed remotely, inside session B, through the tunnel. That's the whole claim, demonstrated the only way it can be: by construction.

Governance comes along for the ride

Because the tunnel carries tool calls — not raw packets — everything rysh already does for tools applies to remote ones:

• 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. The same approval machinery that fronts local tools fronts tunneled ones — with default-deny endpoint allowlisting layered underneath as the hard floor.
• Attributable. A tunneled call is a session-to-session event between named sessions on an upstream you control — 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 this verb, on this endpoint, via this machine, and everyone can watch."

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; Claude is what's wired today.
• rysh is self-hostable, upstream included — your infra, your keys, your data. It is not open source.
• Forge is OpenAPI-only today; GraphQL/gRPC are roadmap, not live.

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