http_request blocks private LAN/Tailnet access in self-hosted setups – breaks autonomy use cases

[klausnitsche]

Summary

In v0.35.0 the http_request tool refuses all requests to private/internal addresses:

"Requests to private/internal addresses are not allowed"

This makes sense as SSRF protection for hosted deployments, but in a self-hosted setup it effectively prevents KinBot from talking to its own services in the same LAN / Tailnet (Kanboard, SSH sidecars, etc.).

For self-hosted autonomy scenarios (DevOps, Kanban SSOT, Sidecars), this is a hard blocker and degrades KinBot to a pure chat system.

Environment

• Deployment: Self-hosted
• Host: Synology DS923+ (DSM 7.2.x)
• KinBot: v0.35.0 (Docker, ghcr.io/marlburrow/kinbot:latest)
• Network:
  • KinBot in Docker on the Synology
  • Kanboard in another Docker container on the same Synology
  • Tailscale on the Synology for remote access
• Local services:
  • Kanboard URL (from host): http://192.168.178.43:8081
  • Tailscale hostname: [HOSTNAME].tailbee249.ts.net

---

Current Behavior

Using the http_request tool to call a local service (e.g. Kanboard JSON-RPC) from a Kin:

{
  "method": "POST",
  "url": "http://192.168.178.43:8081/jsonrpc.php",
  "headers": { "Content-Type": "application/json" },
  "body": {
    "jsonrpc": "2.0",
    "method": "getAllProjects",
    "id": 1
  }
}

returns:

{
  "error": "Requests to private/internal addresses are not allowed"
}

The same happens for any private IP in 10.x.x.x, 192.168.x.x, 172.16–31.x.x, as well as localhost etc.

When using the Tailscale hostname [HOSTNAME].tailbee249.ts.net:8081 from inside the KinBot container, the request just times out (KinBot is not a Tailscale client, so it has no route into the Tailnet).

Code Location and Behavior

The restriction is hard-coded in:

// src/server/tools/http-request-tools.ts

function isPrivateUrl(urlStr: string): boolean {
  try {
    const url = new URL(urlStr)
    const host = url.hostname
    // Block common private ranges and metadata endpoints
    if (
      host === 'localhost' ||
      host === '127.0.0.1' ||
      host === '::1' ||
      host === '0.0.0.0' ||
      host.startsWith('10.') ||
      host.startsWith('192.168.') ||
      host.startsWith('172.16.') ||
      host.startsWith('172.17.') ||
      host.startsWith('172.18.') ||
      host.startsWith('172.19.') ||
      host.startsWith('172.2') ||
      host.startsWith('172.30.') ||
      host.startsWith('172.31.') ||
      host === '169.254.169.254' || // AWS metadata
      host.endsWith('.internal') ||
      host.endsWith('.local')
    ) {
      return true
    }
    return false
  } catch {
    return true
  }
}

and used in the execute handler:

// SSRF protection
if (isPrivateUrl(url)) {
  return { error: 'Requests to private/internal addresses are not allowed' }
}

There is also an explicit test in:

// src/server/tools/http-request-tools.test.ts:189
expect(result).toEqual({
  error: 'Requests to private/internal addresses are not allowed'
})

So this is an intentional SSRF safeguard, not an accidental regression.

Why this is a problem for self-hosted autonomy

In a typical self-hosted setup:

• KinBot runs on a NAS/VM in the LAN.
• Other services (Kanban, databases, sidecars) run on the same host / LAN.
• The main value of KinBot is to:
• Read the Kanban board (SSOT),
• Execute tasks via sidecars/SSH,
• Update the board again (autopilot).

With the current http_request restriction:

KinBot cannot:

• Call Kanboard in the same LAN (192.168.x.x),
• Reach a local SSH-sidecar HTTP API,
• Talk to any other internal HTTP-based service.

This effectively blocks core autonomy scenarios for self-hosted users and turns KinBot into a chat + local file tool only.

In my case specifically:

Kanboard is intended as the single source of truth for tasks.
Bernie (the orchestrator Kin) should:

• Read tasks from Kanboard,
• Delegate to other Kins/sidecars,
• Update Kanboard statuses/comments.

With http_request blocked for private IPs, this architecture is no longer possible from within KinBot.

Requested change / Proposal

I fully understand and support the need for SSRF protection, especially for hosted / multi-tenant deployments.

However, for self-hosted instances this should be an admin decision, not a hard-coded, non-configurable rule.

Possible solutions (any of these would unblock self-hosted autonomy):

1. Config flag to allow private IPs globally

• Env var: HTTP_REQUEST_ALLOW_PRIVATE_IPS=true|false (default: false)
• If set to true, isPrivateUrl is bypassed or relaxed.

2. Allowlist for hosts

• Env var: HTTP_REQUEST_ALLOWED_HOSTS=192.168.178.43,kanboard.lan,sidecar.local
• If hostname matches one of these, the request is allowed even if it looks private.

3. Mode switch: hosted vs. self-hosted

• Env var: KINBOT_DEPLOYMENT_MODE=hosted|selfhosted
  In selfhosted mode:

• Keep metadata endpoints blocked (169.254.169.254, etc.),

• But allow RFC1918 ranges or at least make them opt-in configurable.

Any of these would keep hosted KinBot safe by default, while giving self-hosted users the control they need to integrate KinBot with their own infrastructure.

Why it matters

For my use case (and likely many other self-hosters), autonomy is the main reason to run KinBot locally:

• Kanboard as SSOT.
• SSH-/tool-sidecars for execution.
• Kins coordinating work between them and updating the board.

Right now, the http_request restriction makes these scenarios impossible from within KinBot, even though everything runs safely inside my own LAN/Tailnet.

Making this behavior configurable (or at least allowing an allowlist) would restore the ability to use KinBot as an actual autonomous agent in self-hosted environments, while keeping strong SSRF protection by default for hosted scenarios.

Happy to provide more details about my setup or test any proposed changes.

Just to add a bit of personal context:

I’m using KinBot as a local “execution architect” on my own infrastructure. The whole point of my setup is:

• Kanboard as a single source of truth for all work,
• Kins as orchestrators and workers,
• sidecars/SSH as the actual actuators on my Synology.

I’m investing quite a bit of time and trust into building this around KinBot, because I want real autonomy in my own LAN, not another chat frontend for cloud LLMs.

That’s why this restriction hits especially hard:
it doesn’t just block a convenience feature, it blocks the core reason why I’m running KinBot self‑hosted in the first place.

I absolutely understand why you added strict SSRF protection.
All I’m asking for is a way, as a self‑hosted admin, to consciously opt in to LAN/Tailnet access – with full responsibility on my side.

If we can find a good middle ground here (secure by default, configurable for self‑hosters), that would make KinBot an outstanding platform for serious local automation setups.

[MarlBurroW]

Welcome @klausnitsche, and thanks for this excellently detailed issue! 🎉

You're absolutely right — self-hosted users should be able to opt in to LAN access. The SSRF protection was designed with hosted/multi-tenant safety in mind, but it shouldn't be a hard blocker for self-hosted autonomy scenarios.

Plan: I'll implement a combination of your proposals 1 & 2:

• HTTP_REQUEST_ALLOW_PRIVATE_IPS=true|false (default: false) — global toggle
• HTTP_REQUEST_ALLOWED_HOSTS=host1,host2,... — granular allowlist for specific hosts
• Cloud metadata endpoints (169.254.169.254) stay blocked regardless

Both options are secure by default and give self-hosted admins full control.

Starting automated implementation...

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. If this is still relevant, please leave a comment.