Connecting AI to Network Equipment Safely: On-Site vs Cloud Connectors

The first question any IT manager asks when they hear an AI will be reading their network equipment is: who can access what?

It is the right question, and the answer has nothing to do with the brand of the hardware. It is a property of the connector architecture.

Two genuinely different shapes

One: an on-site connector. The connector process runs on a machine inside the same LAN as the equipment, and the AI using it runs on the administrator's own machine. Device data never leaves the internal network. This is the right shape for core equipment, firewalls, and any case where policy forbids data leaving the building.

Two: a cloud connector. The connector is exposed as a service that browser-based AI can call over HTTPS with OAuth authentication. This is the right shape when you want to ask from a phone, or when several people on a team need the same view.

These do not compete. Real organisations run both, for different jobs.

Why you cannot simply point cloud AI at on-premise equipment

Because LAN devices have no public address, and should not have one. Exposing a device's management interface to the internet so an AI can reach it creates a vulnerability far larger than the convenience it buys.

The correct pattern inverts the direction: a machine inside the network opens an outbound, encrypted tunnel to a central service, and that service is what the AI calls. The equipment never accepts an inbound connection from the internet at all.

Four layers that are non-negotiable either way

1. Authentication. Every call must be attributable. There is no "open to whoever finds the URL".
2. Per-role permissions. Whoever reads a report should not hold the same rights as whoever edits firewall rules — and the connector must enforce that itself rather than hoping nobody tries.
3. Read and write separated. Start read-only, always. Grant write access only for specific operations that genuinely need it.
4. An audit trail. Every call the AI makes must be reviewable afterwards: who asked, when, and what came back.

The second point is where people most often go wrong. Assuming a read-only tool needs no permission model is a dangerous mistake, because reading all network state is seeing everything in the organisation.

How we approach it

We build connectors ourselves, and where a device already has a solid standard connector, we integrate and operate that one instead of duplicating it. Six connector servers we wrote are in production today, each carrying the authentication and per-role permissions described above. We run them against our own systems first.

Frequently Asked Questions

Q1: Can we allow the AI to read but never change anything?
A1: Yes, and it is the default we recommend. Read-only already covers nearly all of the diagnostic and documentation value.

Q2: Do we have to open ports to the internet?
A2: No, and you should not. The correct pattern has an internal machine open an outbound connection, so the equipment never accepts inbound traffic from outside.

Q3: How long does this take to set up?
A3: For a single site, design plus deployment runs 2–4 weeks overall. Attaching a connector to equipment that already exposes readable state takes considerably less.

Want to talk through the right architecture for your organisation? Consultations are free — LINE @tectony or hello@tectony.co.th