📖 Technical reading. This article delves into the "how" of NAiOS Tunnel and is intended for technical profiles —IT, systems, development— with terms like ports, TCP, or databases. If this isn't your area, just remember the idea in one sentence: NAiOS Tunnel connects the programs and data residing on your company's computers with NAiOS's artificial intelligence, securely and without exposing your network to the internet. The rest, your IT team will understand in no time.
The data you need is there, but locked away
Almost every company has valuable information living on a home machine: the database of the management program, the ERP with invoices and clients, an internal application that only works in the office, a control panel, a file server. It is just a few meters away from those who need it, yet it remains disconnected. Your AI assistant can search the internet, draft an email, or summarize a document, but it cannot look at the row in your database or the order in your management program.
The reason is simple: those services live behind the company's firewall, and opening a port to the internet to reach them is precisely what no one wants to do. It is the door through which problems enter. So the data stays where it is, and someone ends up manually exporting an Excel file every time it's needed.
NAiOS Tunnel: a secure bridge to your local services
NAiOS Tunnel is the new module that connects those home services —anyone that communicates over the network— with NAiOS without opening a single port. You install a small agent on the machine where the service resides —the database server, the ERP machine, the PC running the internal application— and from there NAiOS can reach it live.
The trick lies in the direction of the connection. The agent does not wait for anyone to call it: it is the one that opens a connection outward, towards the NAiOS tunnel. Just like when your browser opens a website, the conversation is initiated by the internal machine. That's why there's no need to touch the router, open ports on the firewall, or expose anything to the internet.
And it is a tunnel unique to NAiOS: without ngrok, without Cloudflare, without third parties in between.Zero open ports, and with permission for everything
Each team with the agent has a list of allowed destinations that you define. The tunnel can only reach exactly what you have authorized —for example, “the database on port 5432” or “the internal application on 8080”— and nothing else. The token for each team can be revoked with one click, and as soon as you do it, that agent loses access instantly.
The agent is lightweight and runs on Windows (with an icon in the system tray for a quick glance) and on Linux (as a service, for servers). It installs in a moment with a one-time pairing code, and it updates itself: when we release a new version, it gets updated upon reconnecting without you having to reinstall anything.
Two ways to use it
Once the team is online, the tunnel can be utilized in two ways, depending on what you need.
1. Ask it directly in the chat
You define a “profile” about the tunnel, and that service is within reach of the assistant. Today there are three types, designed to cover most cases:
Databases PostgreSQL and MySQL — the assistant can see the schema and answer questions about your data: “how many orders came in yesterday?”, “give me the ten clients who billed the most this month”. Queries are always executed in read-only mode, so asking can never modify anything.
APIs and internal applications — that custom service that only responds within the office (a dashboard, a microservice, a proprietary tool) is available through its API, with authentication if needed. The assistant can consult it, and also perform actions that write, always with prior confirmation.
SAP Business One — as an example of a ready-to-use integration, the module brings a specific profile for the SAP Service Layer: asking about business partners, open invoices, or stock in natural language, and even creating an offer with prior confirmation. It is a demonstration of how far a well-made profile on the tunnel can reach.
2. Connect your own tools
Sometimes you don’t want to ask: you want to work with your usual program. With a forwarding, NAiOS Tunnel opens a port on your computer that exits through the tunnel to the remote service, just like a ssh -L as usual. It works for any TCP service: your database client (psql, DBeaver…), an administration console, an internal tool.
You copy the command that is generated —with permission limited to that destination and with expiration— and point your program to localhost, as if the service were on your own machine.
Designed to avoid surprises
When what’s on the other side is the company’s database or ERP, security is not an extra: it is the starting point. That’s why NAiOS Tunnel was designed with several layers:
The agent only opens connections outward: there is never a listening port on the client’s machine.
All traffic is encrypted, and the tunnel only reaches the destinations on your whitelist.
Credentials are stored encrypted; on Windows, the agent's token itself is protected with the system's encryption.
Databases are always read-only at the engine level, not just by convention: a write operation is impossible even if attempted.
Any action that writes —creating a record, calling an endpoint that modifies— requires confirmation before execution.
It is a limited one-way tunnel —NAiOS reaches the service you authorize, not the other way around— not a VPN that opens the network wide.
What can you connect? Real cases, taken to the limit
If something in your company communicates over the network, it is a candidate to enter through the tunnel. To get an idea of how far it goes, here are a few examples by sector:
Management, ERP, and POS — SAP Business One, but also the current ERP, the invoicing program, the warehouse software, or the point of sale terminal: check orders, customers, stock, or invoices from the chat, or let an agent prepare a quote, always with confirmation before writing.
Databases and BI — the database that feeds your reports: natural language queries about sales, margins, or inventory without exporting anything, and your usual tools (DBeaver, a BI client via a forwarding) pointing as if the database were on your own desk.
Internal applications and APIs — the custom microservice, the intranet, the control panel, a proprietary CRM: available through its API for querying and also for acting, always with confirmation on what modifies.
IoT and industry (Industry 4.0) — devices with IP on your network: an MQTT broker, PLCs and PLCs via Modbus TCP, cameras, sensors, a home automation hub with a local API. You can read telemetry from the chat —“What temperature is the cold room at?”— or plug in your industrial client through a forwarding. (The devices via USB or serial port need a small bridge to connect them to the network first.)
Hospitality, retail, logistics, offices, clinics… — the availability of a hotel, the stock of a store, the status of a fleet, the system of an office or a management firm, the history of a clinic: any data that today can only be consulted in front of a specific computer.
Legacy tools and systems — an administration console, a file server, an internal email service, or that old but essential program that only lives on one PC: without migrating it or exposing it, within reach of AI.
What it does today and what it still doesn't (it's a V1)
This is a first version, and we prefer to clearly state where the limits are today:
It tunnels services that communicate over TCP (and HTTP): databases, APIs, MQTT, Modbus TCP… It still does not support UDP, so some IoT or streaming protocol that runs over UDP is out for now.
It connects to what has IP and port. A device via USB, serial port, Bluetooth or Zigbee needs a bridge to expose it to the network in order to tunnel it.
It is a tunnel in one direction and limited to your whitelist: NAiOS reaches the service you authorize, and nothing more. It is not a VPN that opens the entire network.
It is in controlled deployment: today we activate it case by case, accompanying the implementation, rather than as a self-service for anyone.
What’s coming (2026–2027)
The direction is set by what you ask us for. Without promising dates, on the horizon of 2026 and 2027 we are looking at UDP and more protocols (to cover more IoT, voice, and streaming), more ready-to-use integrations like the one for SAP —for the most common ERPs, CRMs, and systems—, and an increasingly self-service implementation. We will open it up according to real demand, with security always in the forefront.
Available in NAiOS
NAiOS Tunnel was born from a very specific need —to connect a collaborator's system without setting up half an infrastructure— and has become a piece that serves any service that lives behind closed doors: a database, an ERP, an internal application, a custom panel. We are deploying it gradually: if there is something in your company that you would love to be able to consult or manage from the chat, let’s discuss it and we will activate it for your case.
Because AI is much more useful when it can look at your data. NAiOS Tunnel is the bridge to get to them, without lowering our guard.
