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.

Keep them. Both now ship MCP servers that let an agent launch jobs people wrote (Red Hat AAP 2.7 MCP, Rundeck MCP). bastn starts from the CLIs and scripts already on your hosts, so you do not author a job per action. Each agent gets its own menu on the same tool, the limits are enforced by the connector on the host, risky actions wait for approval per call, and every call goes into an audit trail you can verify offline.

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.

bastn is self-hosted. The gateway and every connector run inside your network, and connectors talk to the gateway. Nothing leaves your network unless you send it. Fully offline install, licensing and updates are coming.

Only the actions in its own menu. With a large menu, bastn can offer three discovery tools instead of every schema: search_tools finds actions the policy allows, tool_schema returns the arguments of one, and call_tool runs it. People can search the same catalog with bastn tools search or browse it on the Tool catalog page in the dashboard.

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.

Destructive actions are held for approval by default. New tools can be denied until you review them (new_tools: deny).

Every agent gets its own key. One switch disables an agent and its keys.

Set rate limits per agent or caller.

Commands run as a dedicated non-root user (run_as). Running commands as root is refused. The connector process must run as root to switch to that user. The published image runs as uid 10001 and does not switch users.

Shipped: the connector, CLI and script actions, the read-only Linux pack, reviewed scripts, OpenAPI 3 and existing MCP servers, per-agent keys, approvals for destructive actions, rate limits you set, a switch that disables an agent and its keys, tool discovery (search_tools, tool_schema, call_tool), tool proposals reviewed by your admins, approval webhooks per organisation, organisations with teams and roles, and a hash-chained audit log you can verify offline. No shell by default. Coming: gRPC, GraphQL and SQL named queries as tools, undo of a change's effect, and fully offline install, licensing and updates.

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.

Request access and we set up a gateway and your first connectors with you. Connector binaries are shared with early-access teams. Contact comms@dflux.io.