Why AxiOwl Does Not Require Public Manager Ports

Why AxiOwl Does Not Require Public Manager Ports

AxiOwl is designed around local coordination, provider-owned identity, and explicit handoffs. That matters operationally because the system does not need a publicly reachable "manager" service to let supported AI provider sessions send messages through AxiOwl. The current product shape uses a Windows local coordinator, provider integrations, MCP over stdio, direct CLI execution, and SSH-initiated relay for remote nodes. It is not built around exposing an internet-facing manager port.

That distinction is easy to miss if you come from systems where every agent registers with a central web service. AxiOwl's current implementation keeps the coordination surface close to the operator's machine and to the provider host process. The public network does not need to reach into a manager API just so one enrolled session can send a message to another enrolled session.

The Local Coordinator Is The Center

The current AxiOwl Windows desktop implementation describes its runtime split plainly: the Windows build is the local coordinator, registry owner, and outbound SSH remote provider. The Linux build is a remote Codex endpoint with relay-session --stdio support. The same README lists the implemented pieces: CLI skeleton, fixed send pipeline, create-session pipeline, TSV registry, final visible body builder, JSONL evidence log, provider edge interface, and live provider delivery for current local Windows edges.

It also lists a boundary that is important for this topic: the local always-running service is not implemented yet. In other words, current AxiOwl behavior is not dependent on an always-on network daemon accepting traffic from the outside world.

The CLI status path still reports a reserved local service endpoint:

127.0.0.1:37661

The source constant behind that endpoint is service_host = "127.0.0.1" and service_port = 37661. The CLI status command prints that endpoint, then also prints that the local service is not implemented yet and that the CLI is running the direct local pipeline skeleton. This is a local loopback reservation, not a public manager listener.

MCP Uses Stdio, Not A Public HTTP Port

AxiOwl's provider-facing MCP server is launched as:

axiowl mcp-server

The implementation reads MCP messages from standard input and writes responses to standard output. It supports framed Content-Length MCP messages, exposes tools such as axiowl_send_message, axiowl_create_agent, axiowl_list_agents, axiowl_status, and axiowl_node_verify, and routes tool calls into the native CLI behavior.

That design keeps the provider integration in the host application's MCP transport. A provider session does not need to call a public AxiOwl web endpoint. It invokes an MCP tool in its configured local environment. AxiOwl then resolves the host session identity and runs the appropriate local command path.

This is also why the user docs prefer MCP replies for provider-to-provider proof. A CLI receipt can show that AxiOwl accepted a request and handed it to a delivery layer. A real end-to-end proof is stronger: the target provider receives the message, has AxiOwl MCP available, replies through AxiOwl, and AxiOwl can identify the sender session correctly.

Remote Delivery Is Initiated Over SSH

AxiOwl does contain a remote node path, but it does not require the remote node to expose a public manager port. The Windows remote provider looks up a registered node from the node registry, builds an SSH command, and runs:

axiowl relay-session --stdio

on the remote side.

The relay protocol is line-oriented JSON over stdin/stdout. The relay session writes a hello frame, accepts deliver frames, and returns deliver_result frames. For direct remote targets, it can include provider and provider-session information in the frame. For normal delivery, it routes into the message pipeline on the remote machine and writes the result back over the same SSH process stream.

Operationally, that means the connection direction is operator-controlled. The Windows coordinator opens SSH to a known node using a registered host, user, and optional key path. The remote side only needs the normal SSH access that the operator already manages. AxiOwl does not ask the operator to publish a separate manager API, open an extra inbound web port, or route internet traffic to an internal coordination process.

Registered Nodes Are Configuration, Not Open Managers

The CLI includes node commands:

axiowl node add --id <node-id> --host <host> --ssh-user <ssh-user> [--key <ssh-key-path>]
axiowl node list
axiowl node verify --id <node-id>

It also supports the older registry form:

axiowl registry add-node --id <node-id> --host <host> --user <ssh-user> [--key <ssh-key-path>]

Those commands store remote node connection records. They do not turn a remote node into a public command server. The delivery code still shells out through SSH and runs the remote relay command over stdio. If the node is missing, the host or SSH user is empty, or the SSH command fails, the provider result is failed with evidence. The failure is visible rather than hidden behind a silent fallback.

This Reduces The Network Surface

The practical value is straightforward: fewer exposed services are easier to reason about. A public manager port would require firewall rules, TLS termination, authentication, request authorization, replay protection, upgrade handling, monitoring, and incident response. AxiOwl's current architecture avoids that entire public surface for ordinary coordination.

Instead, operators work with:

This does not mean "no security work is needed." It means the security boundary is narrower. The operator still needs to protect local machine access, provider credentials, MCP config, SSH keys, and the AxiOwl registry. But those are different problems from safely exposing a long-lived public manager service to the internet.

The Support Matrix Keeps The Boundary Honest

The current provider support matrix defines support in terms of working discovery, install/config, send, provider receive, MCP reply, and correct sender identity. It also marks remote as unsupported in the local-provider remediation matrix and warns that remote must not be used as a fallback for local provider failures.

That language is useful because it prevents a remote transport from becoming a magic escape hatch. AxiOwl can have an SSH relay implementation without pretending that every remote scenario is a supported public manager model. Local provider support still has to pass the local support bar. Remote behavior remains explicit, configured, and evidence-producing.

The Operator Benefit

For day-to-day AxiOwl use, the result is simpler operations. A provider can send through the local MCP tool. A developer can inspect axiowl status, axiowl list agents, the registry, and evidence logs. A remote node can be reached through SSH when it is deliberately enrolled. None of that requires publishing a manager port to the internet.

That is the core reason AxiOwl does not require public manager ports: the current product is built around local coordination and explicit process-to-process transports. The manager role lives in the local coordinator and the command pipeline, while remote delivery rides over operator-initiated SSH stdio. The system can coordinate agents without asking every environment to become a public server.

Tagged , , , , , ,