Ad-hoc connection IDs versus unattended agent access: which model fits

How the two models differ mechanically

In the ad-hoc model, the remote machine runs a small client — often without installation — which generates an identifier and a session password. The user reads them out, the operator enters them, and a session begins. Authorisation is the user's willingness to share the code. When the session ends, the relationship ends.

In the managed-agent model, a persistent service is installed and registers the device with a central console. Authorisation is a property of the operator's account and the device's group, checked at connection time. The device is addressable whether or not anyone is sitting at it, and every connection is attributable to a named operator.

• Ad-hoc: nothing to deploy, works on unknown devices, expires with the session
• Ad-hoc: authorisation is verbal and per-session; no central revocation
• Agent: central inventory, roles, groups, and unattended reachability
• Agent: one deployment step per device, and an offboarding path that works

Auditability is where the models really separate

Ask a simple question: which of your machines could a given operator have connected to last Tuesday? With managed agents this is answerable from the console — group membership and role define it, and session logs confirm what happened. With ad-hoc IDs the honest answer is 'any machine where someone read them a code', which is not an answer an auditor will accept.

The same asymmetry appears at offboarding. Disabling an operator account instantly removes their access to every managed device. In the ad-hoc model there is nothing central to disable — anyone who knows the connection method can still be given a code by a helpful user.

Where the ad-hoc model is genuinely better

Ad-hoc is the right answer whenever installing something is inappropriate: a customer's own laptop, a supplier's machine, a one-off favour, a device you have no authority over, or a locked-down environment where you are not permitted to deploy software. It is fast, requires no prior relationship, and leaves nothing behind — which is exactly the point.

It also matters for consent. Attended sessions where the user is present, watching and able to end the session are appropriate for supporting people rather than machines, and many organisations rightly require them for staff desktops during working hours.

Where the agent model is the only workable answer

Anything unattended requires an agent: servers in a cupboard, kiosks, digital signage, machines being patched overnight, a laptop that has stopped booting properly and needs work before anyone arrives. There is nobody to read out a code, so there is no session.

Scale pushes the same way. At twenty devices you can improvise; at two hundred you need groups, roles, last-seen state and a way to answer questions about the estate without phoning people. That is an inventory problem, and only the agent model produces an inventory.

The practical answer: run both, deliberately

The right structure for most teams is managed agents across everything you are responsible for, plus an ad-hoc route for everything else. What matters is that the split is intentional and documented, rather than being whichever method the operator remembered first.

Write down the rule: owned devices use the managed path with role-based access and logging; third-party and unknown devices use the attended path with explicit consent and no residue. That single sentence prevents most of the mess.