Self-hosted tool gateway for internal systems
bastn turns the CLIs, scripts and services on your VMs, containers and sandboxes into typed tools, with a different menu for each agent. No MCP server to write. Each machine runs one small outbound program, the bastn connector, and it can only run what you approved: no SSH keys, no open ports, no shell by default.
Early access for platform and SRE teams. Runs in your network.
The problem
The agent can triage an alert. To finish the job it has to read logs, check a route or restart a service on real machines. Today that means one of three things, and none of them gets past a security review:
01
However well it is brokered, the agent ends up with a shell, limited by the Unix account it logs in as.
02
Someone writes, hosts and maintains a server per CLI, per script, per team. The long tail of internal tools never gets one.
03
Every agent uses the same key or the same job account, so nobody can say which agent ran what, or stop just one.
bastn gives the agent a menu instead of a shell. Each agent sees the actions it may take, on the machines it may touch, with the values it may use.
How it works
01
One small binary per VM, container or sandbox. It dials out to your bastn gateway over mutual TLS, so the host needs no inbound port and no VPN. Give it labels like web, db or prod when it enrols.
BASTN_CONNECTOR_TOKEN='wpj_…' bastn-connector enroll --hub bastn.acme.internal:18093 --name web-4202
Describe a tool once: which subcommands become actions, which arguments each takes and which values are allowed. Paste the tool's --help into your own AI assistant with our authoring guide, review the result and approve it. Read-only Linux diagnostics ship ready to use.
03
Each agent gets its own key and its own policy: which actions, on which labels, with which argument values, how often, and what waits for you.
04
The gateway checks identity, policy, arguments, rate limits and approvals. The connector checks its own local limits, then runs the command as plain arguments. The call goes into the audit trail.
What changes
Label machines once (web, db, qa, prod) and actions reach every machine with that label, including new ones as soon as their connector enrols. One agent can diagnose 100 hosts and hold full access to none of them.
Describe your CLI once and bastn serves it as typed MCP tools with validated arguments. The internal tools that will never get an MCP server (your deployctl, your runbook scripts) become agent tools. Services with an OpenAPI spec and existing MCP servers plug in the same way.
A triage agent gets status and logs. A remediation agent also gets restart, on web only, with approval. Rules go down to individual argument values: which units, which paths, which hosts. Every agent gets its own key. One switch disables an agent and its keys. Set rate limits per agent or caller.
Destructive actions are held for approval by default. New tools can be denied until you review them (new_tools: deny). You see the exact action, host and arguments, approve or deny, and the agent carries on. Approval requests can also go to a webhook per organisation, so they reach any channel, Slack included through a webhook bridge. When no action fits, the agent can write a script: it runs after you review it, and the connector re-checks the approved hash before every run.
When an agent needs a tool, a flag or access it does not have, it asks with propose_tool and checks the answer with proposal_status. Your admins review each request under Approvals › Proposals in the dashboard. Nothing is applied automatically: an accepted proposal becomes a draft that goes through its own review.
Every decision (allowed, held, refused, approved) is written to a keyed, hash-chained log: which agent, which action, which machine, which arguments. Export it as JSONL and verify it offline with your key. An edited or missing row breaks the chain.
The gateway is one Go binary and Postgres, inside your network. Connectors dial the gateway. Nothing leaves your network unless you send it.
Check it yourself
The specs the connector enforces, the limits a host owner sets, and a captured run with its verdicts and audit check are all on the security page.
A real policy, its deny and hold verdicts, and bastn audit verify, all captured from a bastn run.
The security page lists what is enforced today, and nothing else.
bastn runs on your infrastructure, and each host's connector dials out to it.
Agents connect to /mcp with a virtual key or an OAuth sign-in.
Pricing
Agents are not charged. Start free on up to 10 hosts.
Free
No charge
$8 per connected host per month, billed annually
$10 per connected host per month, billed monthly. Early access pricing.
Contact us
FAQ
It speaks MCP, so any MCP-capable agent can use it. It is not a gateway to external SaaS. bastn is a tool gateway for your internal systems: the VMs, containers, sandboxes, services, scripts and CLIs in your network. See MCP gateway vs tool gateway.
SSH access, however well it is brokered, ends in a shell on the host, bounded by the Unix account the agent logs in as. An SSH MCP server adds allow-lists on top of that shell. The bastn connector runs named actions with typed, validated arguments. There is no shell by default. Raw commands are off unless you enable them, and every raw call waits for approval. You do not have to write or host an MCP server per tool. Keep your access broker for people. Give agents a menu. See bastn vs SSH MCP servers.
Yes. One small connector per host, the same way you already run monitoring or config agents. It dials out, needs no inbound port and can run the actions you approved. There is no shell by default. Release binaries for Linux, macOS and Windows (amd64, arm64). The Linux command pack is tested on Debian, Ubuntu and Alpine. Install recipes beyond the release binaries are coming.
Any agent that speaks MCP. Point it at your bastn gateway's single MCP endpoint, /mcp, and authenticate with that agent's own virtual key or an OAuth sign-in. An example address is https://bastn.acme.internal/mcp.
If your agents mostly need SaaS apps, a gateway aimed at SaaS is a better fit. If your whole estate is in one cloud and you are happy with that cloud's node agent, start there.
Early access
Early access is open to a small number of platform and SRE teams. Tell us about your hosts and the agent you want to run.