← Back to news 19.09.2026

What the agent never does

A service running as SYSTEM on every device is the most powerful piece of software in the building. The isidaten agent appeared in four of the last six articles, always as a tool. This one is about the agent itself: five things it never does, and why a stolen database therefore does not control the fleet.

The isidaten agent is a service on the device: as LOCAL SYSTEM on Windows, as its own user with the network rights a scan needs on Linux, as a LaunchDaemon on macOS, plus Solaris. It now knows more than 50 task types, from hardware inventory via NetFlow collector and cryptography harvest to the probe on the domain controller, and since 17 September 2026 it ships as an arm64 package for Raspberry Pi and ARM servers.

A program with those rights on every device is the most powerful piece of software in the building. So what it does matters less than what it never does. Five answers.

1. It does not assess

The agent delivers facts, the server assesses. The probe on the domain controller reports registry values, service states and access entries; which of them are a weakness is decided by 62 rules on the server. That is not a stylistic choice but the reason a new check rule needs no agent release. The same holds for the cryptography harvest, the hardening benchmarks and OT discovery. Whatever is decided on the device has to be rolled out to every device. Whatever is decided on the server applies to all of them at once.

2. It runs no commands

There is no order type "run this command". Remote actions come from a list of twelve, with no free command line. A compensating measure in virtual patching is a mechanism with parameters, a registry value or a service or a kernel parameter, never a script. If the script existed, a single database row could execute code as SYSTEM across the whole fleet. What the agent does not know, it does not execute, even when signed.

3. It does not trust the server just because it is the server

A valid TLS certificate and a bearer token are not enough to give the agent an order. Every order carries an Ed25519 signature that the agent checks against locally pinned public keys, and passes nine checks in fixed order: pinned key, signature, tenant binding, agent binding, expiry with five seconds of tolerance for clock drift, nonce against replay, monotonic counter, order type in the compiled-in list, parameter schema. The list of order types is deliberately in the code and not extensible through configuration. If a device lacks the library for signature verification, orders are not executed unchecked; they are not executed at all.

The reason sits as a comment in the source: whoever controls the platform database could otherwise steer the entire fleet. With the signature, they do not.

4. It does not make itself unreachable

Network isolation of a device is the sharpest action the agent knows. Its guiding principle: when in doubt keep the management channel open, rather not isolate than become unreachable. If the path to the platform or a required proxy cannot be resolved, the device is not isolated; an error is reported. After setting the rules the agent checks whether the platform still answers, and rolls back if not. An isolated device nobody can reach is no gain in security.

5. It does not read what it does not need

A password in group policy preferences is reported as presence plus file name; the value is never read. Registry values come exclusively from an allowlist of fixed paths the server sends along and the agent restricts further. The cryptography harvest delivers metadata, and the server rejects a report containing a PEM block or a base64 blob. In operational technology the agent stays passive; probing OT ports is an opt-in per task with a warning, because an SNMP packet to the wrong controller can stop a plant.

What follows

These five rules cost something. A new remote action needs a release, a new mechanism too, and the agent cannot do things a three-line script could. The price is deliberate. The management tool running on every device is exactly what an attacker looks for after the first foot in the door.

More on the agent management module page and in the modules where the rules apply: directory security, cryptography inventory, virtual patching and OT security.

The question to ask

Which tool in your organisation runs on every device with system rights, and what happens if someone controls its database?

If the answer is "then they can do anything", the tool is the target.

Matching solution isidaten for ISO/IEC 27001

Questions about this update?

Talk to us – we are happy to show you this feature in a demo.