Unattended access should be an appointment, not a licence

Ask most remote support tools who can connect to a particular PC without anybody
agreeing at the keyboard, and the honest answer is “everyone with the unattended
permission, on every machine, forever”. That is not an answer anybody can act on.

It is also the wrong shape for how the access is actually used. The common case
is narrow and temporary: a contractor who needs one server for one afternoon, an
engineer covering a site while a colleague is away, somebody finishing a migration
over a weekend. A permanent, fleet-wide capability is a poor fit for all three.

Two different questions

We split it. The permission answers “is this person trusted to work unattended at
all”. A grant answers “which machines, and until when”. They are checked together,
and both must hold.

That means holding the permission on its own reaches nothing. It also means a
grant handed to somebody without the permission does nothing at all – so an
administrator cannot accidentally give away unattended control by ticking one box
on one device. The two rights are deliberately not the same right.

Expiry is a moment, not a duration

Every grant runs out on a stated date and time. Not “two hours from first use”,
which cannot be shown on a grid, cannot be queried, and cannot be audited later
without replaying events. A moment can be read straight off the row by a person
and by a report.

There is a hard ceiling on how long a single grant can run. “Until 2099” is how
temporary access quietly becomes permanent and nobody revisits it.

A code every time, not once a day

Each unattended connection asks for a current authenticator code. Being signed in
proves who started the session that morning; it does not prove who is at the
keyboard now. An unattended session is precisely the case where nobody at the far
end will notice the difference, so it is the case where asking again is worth the
friction.

The check happens on the server, not in the browser. A check the interface
performs is a check the API route does not, and both open the same session.

The refusals are the useful part

Every attempt is recorded, including the ones that were turned away. A refused
connection never becomes a session, so without recording it, somebody working
through machines they hold no grant for leaves no trace anywhere. A log of
successes cannot show you that.

Withdrawn grants are kept rather than deleted, for the same reason: “who could
reach that machine last Tuesday” has to stay answerable after somebody has tidied
up.