Guardian

The Guardian lets your technicians into a server with nobody in front of it. Nobody has to start golem serve or pass on the line, and nobody has to open an AnyDesk session first to do it. It is new in 1.4 and comes with the Golem Company license, with no charge per server.

The server keeps no password. It keeps a lock that recognizes the credentials of your company's technicians, and a Windows service that listens to nothing from outside while nobody calls. When a technician with a valid credential calls (the "knock"), the service opens an ordinary Golem session for them, with a new token and for them alone, and closes it when they stop using it.

Where it is not installed, nothing changes: without a lock, golem.exe behaves as in 1.3.1. The rest of the agent is in the server kit.

What you need

• A Golem Company license. With it, the account administrator registers their technicians under Technicians and the portal issues a credential for each one. A technician or team license has no credentials.
• The credential of one of those technicians, in a file.
• An elevated console (Run as administrator), because a service gets installed.
• golem.exe in its final folder, for instance C:\Golem\: the service starts that file at that path. In tunnel mode, cloudflared.exe next to it, as it comes in the kit.

Installing it on a server

The first time is done from an attended session, with somebody from the customer present or through the usual remote session. That installation is the moment the customer gives their permission. The lock is written with the date, your company and the technician who installed it, and it is the record of that consent.

golem guardian install --credential C:\Golem\juan.cred

That leaves it in tunnel mode, asking the portal every 60 seconds, with every tool and 30 minutes of idle time. The options:

When it finishes, it prints two things you have to write down in that customer's inventory. The slot is the eight digits the technician types to get in, and they do not change while the guardian stays installed. The identity is 16 hexadecimal characters, the fingerprint of the guardian's key: with it the technician checks that the server at the other end is this one and no other.

Guardian installed: service GolemGuardian, ISV lic_01m2k8..., installed by Juan Perez, mode tunnel. The lock is C:\Golem\golem.guardian.json; to revoke everything: golem guardian remove
Guardian identity: B46CBC0856E39E3A. Write it down in the inventory: it is the one the technician pins the first time they come in through the portal.
Portal slot: 3050 7712. A technician of this ISV gets in with those eight digits (portal https://irwinrodriguez.dev/api).

If the portal does not answer during the installation, the guardian gets installed anyway, without a slot, and says so in red. Without a slot nobody gets in through the portal. The fix is golem guardian remove and install again once the portal answers.

The two modes

In tunnel the guardian listens to nothing outside the machine. It opens a Cloudflare quick tunnel only when a knock arrives that has already passed every check, and closes it with the session. The tunnel limits of the server kit apply: no call can take longer than 125 seconds.

In direct it listens on its port, with TLS and a certificate of its own that is created once. Besides the eight digits, the technician can call the port directly, without the portal and without waiting for a poll, and if the portal goes down that way in keeps working. Windows gets the inbound firewall rule for its port, which the service creates when it starts and removes when it stops.

What it leaves on the machine

Next to golem.exe:

In Windows it leaves the GolemGuardian service, which runs as LocalSystem and starts with the machine, and the GolemGuardian source in the Application event log.

The lock carries no key. The slot secret only serves to ask the portal whether a knock has arrived, and it gets nobody into the server.

Checking, removing and updating it

golem guardian status needs neither elevation nor a credential: it shows the lock, the mode, the slot, the identity and the state of the service, and warns in red if something is wrong. golem guardian remove, in an elevated console, takes everything away: the service, the lock, the certificate, the portal state and the event log source. Only golem-audit.log stays, because it belongs to the owner of the machine. If it is installed again, it gets a new slot and a new identity.

golem guardian status
golem guardian remove

To update golem.exe, stop the service, copy the new one over it and start it again. The slot and the identity do not change.

sc stop GolemGuardian
copy /y golem.exe C:\Golem\golem.exe
sc start GolemGuardian

How a technician gets in

It takes a key on their computer, a credential from their company and the server's eight digits. The first two steps are done once.

1. The key

On the technician's computer:

%LOCALAPPDATA%\Golem\golem-client.exe --guardian-key

It creates a key in %APPDATA%\Golem\guardian.key, encrypted with the DPAPI of their Windows user, and prints its public part and its fingerprint. It only works on that computer and with that account: on a new computer, they create another one and ask for a credential for it.

2. The credential

The technician gives the public key to the administrator of the Golem Company account, who registers them under Technicians and sends them the credential the portal issues. The technician stores it with:

%LOCALAPPDATA%\Golem\golem-client.exe --guardian-cred %USERPROFILE%\Downloads\juan.cred

The credential expires after 30 days. It renews itself when golem_connect gets into a guardian and it has less than 7 days left (or expired less than 7 days ago), and by hand with --guardian-renew. It renews while the technician stays registered and the Company license stays active; more than 7 days after it expired, the administrator has to issue it again.

%LOCALAPPDATA%\Golem\golem-client.exe --guardian-renew

3. Getting in

In Claude's chat, the eight digits your company has written down for that server:

golem_connect 3050 7712

The client leaves the knock at the portal and waits for the answer, which arrives with the guardian's next poll: a minute at most with the factory settings, plus a few seconds if it opens a tunnel. From there on it is a Golem session like any other. On a server with an IP, in direct mode, the port can be called without going through the portal:

golem_connect guardian:https://srv01.clinica.local:8797

There is one session at a time: if another technician is in, the second one gets toque_ocupado, without being told who. Since the service has no desktop, screenshot and list_monitors do not work through the Guardian.

The guardian's identity

The answer that comes through the portal is signed by the guardian, and the technician's client checks it the way SSH checks a server's key. The first time it gets in through a slot, it notes that guardian's identity; after that it demands the same one, and if it changes it gets guardian_identidad_cambiada and does not connect. If your company has the identity in its inventory, the technician can demand it from the first time by writing it after the eight digits:

golem_connect 3050 7712 B46C-BC08-56E3-9E3A

The same form serves to accept a legitimate change, for instance when the guardian had to create a new certificate. Through the direct knock it is not needed: the TLS certificate is checked against the fingerprint that comes inside the encrypted answer.

What the customer sees

The evidence of what is done stays on their server. golem-audit.log, next to golem.exe, notes every knock, accepted or refused, with the technician's name taken from their verified credential, and every call in the session. It never carries tokens or credentials.

Whoever runs the server also sees it in the Event Viewer, under Windows Logs, Application, with the GolemGuardian source:

While nobody calls, the door is shut: in tunnel mode the service listens to nothing outside the machine. The session closes on its own after 30 minutes without requests, the tunnel closes with it and the token stops working. The customer can remove the Guardian at any time with golem guardian remove, and from then on nobody else gets in.

What the portal sees and what it does not

The Golem agent calls nobody. The guardian is the one exception, and it is bounded: only the guardian service calls, only to the URL its lock names and only to ask about its slot. Nearly always the answer is empty.

The portal acts as a relay that cannot read what goes through it. It keeps the slot, the hash of its secret and, for a few minutes, encrypted knocks and answers. It does not know the machine's name or its IP, and it sees no commands, files or sessions. About your company it knows what it already knew from the license, plus the list of technicians you register under Technicians.

If the portal does not answer, the service keeps running and retries, spacing out its attempts. A slot with no polls for 90 days is recycled, for instance the slot of a server switched off for three months: status says so in red, and the fix is remove and install.

Hosting your own relay

If your company prefers not to depend on the irwinrodriguez.dev portal for knocks, it can host its own. The contract (five routes and what each one keeps) is in GUARDIAN-RELAY.md, in Spanish and English. On the server it is set with --portal at installation, and on the technician's computer with the GOLEM_PORTAL environment variable, in the env block of the .mcp.json.

Credentials and their renewal are always issued by the irwinrodriguez.dev portal, even when the knock goes through your relay, because they are part of the Company license.

If something does not work

The codes that come up most, and what to do:

The toque_* codes arrive inside guardian_toque_rechazado: the guardian sets them when it refuses the knock.