Security When an AI Can Read Your Devices: What to Ask Before You Approve It

If a provider proposes giving an AI access to your network equipment, here is the list of questions to put to them before you sign.

Good answers are specific. Vague answers are the warning sign.

One: does data leave the organisation, and where does it go?

If it does, you need to know whose systems hold it, for how long, and who can reach it.

If it does not, that should be demonstrable — the connector genuinely runs inside the LAN, and the AI calling it runs on an internal machine.

For core equipment and firewalls, we recommend the never-leaves option without exception.

Two: does the equipment have to accept connections from the internet?

There is only one acceptable answer: no.

If a provider says a device's management interface must be exposed so the AI can reach it, that trades convenience for a serious vulnerability. The correct pattern has an internal machine open the connection outward instead.

Three: are permissions divided by role?

This question separates providers who have thought about security from providers who have simply wired something up until it worked.

The common mistake is assuming a read-only tool needs no permission model. It is not true. Reading all network state means seeing everything in the organisation — who is where, using what, and when.

Ask plainly whether someone reading a report holds different rights from someone changing device configuration, and whether the connector enforces that itself rather than relying on nobody trying.

Four: is there an audit trail?

Every call the AI makes should record who asked, when, and what came back. Without that record there is no way to reconstruct events during an incident.

Five: can we start read-only?

The answer should be yes, and it should be the default.

Read-only covers nearly all of the value — diagnosis, documentation, capacity planning. Write access should be granted only for operations that genuinely require it, and only once your team is comfortable with the system.

Six: how is access revoked?

There should be a clear revocation path you can execute immediately, without waiting on the provider.

How we answer these

Every connector we write carries authentication and per-role permissions built in. We default to read-only. For equipment whose data must not leave the building, we deploy the connector on-site. Six connector servers we wrote are in production today, all on this same standard — and we run them against our own systems first.

Frequently Asked Questions

Q1: Does this touch PDPA?
A1: Yes. Connection data about staff can be personally identifiable in some contexts, so collection scope and retention period should be agreed at the start rather than discovered later.

Q2: Our policy forbids any data leaving. Is this still possible?
A2: Yes — with on-site connectors throughout, device data never leaves the LAN.

Q3: Does the provider have permanent access to our network?
A3: They should not, and the contract should say so. Support access should be requested per occasion, time-bounded, and logged.

Want these questions answered against your own environment? Consultations are free — LINE @tectony or hello@tectony.co.th