25. The Automaton’s Second Heart
Domain: Endpoint Security — Hardening, EDR, Application Control POV: Wren Reading time: ~15 minutes
The automaton workforce numbered in the thousands — brass workers that tended the gear-chambers, carried goods through the maintenance tunnels, operated the assembly lines in the industrial district, and performed a hundred other tasks that kept the city functioning. They were tireless and precise and, as the backdoor incident had demonstrated, dangerously vulnerable. A single compromised automaton could spread corruption to every other automaton in its network. A single corrupted command could turn the city’s own workforce against it.
“We need to secure the automata,” Wren said to the council. “Every single one of them. Not just the network that controls them — the automata themselves. Their mechanisms. Their command interfaces. The way they receive and execute instructions. Everything.”
The automaton security project became known, informally, as “the hardening” — a term that Quill had found in the old treatises, describing the process of reducing unnecessary risk on individual systems.
The first step was removing unnecessary functions. Every automaton in the city had been built with a full set of capabilities — the ability to receive and execute any command, to connect to any network, to communicate with any other automaton — because building them that way was simpler than building them with limited capabilities. Simpler, but more dangerous. The hardening project stripped away every capability that a given automaton did not actually need. A gear-chamber worker did not need the ability to communicate with the Library’s archival system. An assembly-line automaton did not need the ability to access the Spire’s timekeeping network. Every unnecessary function was a potential attack vector, and every attack vector that could be removed was removed.
The second step was application control — restricting which commands each automaton would accept and execute. The old system had allowed any authorized user to issue any command to any automaton. The new system maintained a whitelist: each automaton would only accept commands that were specifically approved for its role and its function. A maintenance command could only be issued by an authorized engineer. A routing command could only be issued by the gate-control system. A shutdown command required two-person verification and a documented justification. Any command that was not on the whitelist was rejected, logged, and reported as a potential security incident.
The third step was detection and response. Thread designed a monitoring system — a network of sensors distributed throughout the automaton workforce — that tracked the behavior of every brass worker in the city. If an automaton deviated from its normal pattern — if it hesitated before executing a command, if it moved to an area it was not authorized to access, if it communicated with a system it had no legitimate reason to contact — the monitoring system flagged the anomaly and alerted the human supervisors. The system was crude — it generated many false positives, and it required constant tuning to distinguish between genuine anomalies and ordinary operational variation — but it was better than nothing.
“Endpoint detection and response,” Quill said, reading from one of his treatises. “The principle is simple: you cannot prevent every attack, so you must be able to detect attacks when they occur and respond before the damage spreads. The automata are endpoints — individual devices that can be compromised individually. The monitoring system detects compromise. The response procedures — isolation, investigation, remediation — contain the damage and restore function.”
The first test of the hardened automaton system came two weeks after the project was completed.
A maintenance automaton in the gear-chambers — a brass worker designated Unit 447, responsible for lubricating the main driveshaft bearings — received a command that had been injected into the control network by one of Vale’s remaining devices. The command was well-formed and appeared legitimate: “Proceed to Sector 12 and adjust bearing tension by 0.3 degrees.” But Unit 447 was not authorized to perform tension adjustments — that capability had been stripped during the hardening process — and the command was rejected. The automaton logged the rejection and continued its normal maintenance routine.
The monitoring system, however, noticed something that the automaton itself had not: the rejected command had originated from a control node that was not on Unit 447’s whitelist of authorized command sources. The anomaly was flagged. Thread, who was monitoring the system from the shed, received the alert within seconds. And the control node — a small brass device hidden in a maintenance passage near Sector 12 — was located and removed before it could inject any additional commands.
“The system worked,” Wren said, reviewing the incident report with a quiet satisfaction. “The automaton was hardened — it could not execute the unauthorized command. The application control whitelist prevented the command from being accepted. And the detection system identified the source of the attack, allowing us to neutralize it before additional commands could be injected.”
“How many other command-injection devices are still out there?” Kip asked.
“I do not know,” Thread said. “The detection system is still being tuned. It generates many false positives — ordinary operational anomalies that look like attacks but are not. We are learning to distinguish between the two, but it is a slow process.”
“Then we keep tuning,” Wren said. “And we keep hardening. Every automaton that has been stripped of unnecessary capabilities is one fewer attack vector. Every command that is rejected by the whitelist is one fewer successful compromise. And every anomaly that is detected and investigated is one fewer attack that succeeds undetected.”
She looked at the monitoring display on the wall of the shed — a simplified version of Thread’s full system, showing the status of every automaton in the city as a series of colored dots. Most of the dots were green: normal operation, no anomalies detected. A few were yellow: minor deviations, being investigated. None were red — not today, at least — but Wren knew there would be red dots eventually. There always were.
The automata were endpoints in the city’s vast network of systems — individual devices that could be compromised individually, each one a potential beachhead for an adversary. The hardening had made them harder to compromise. The detection system had made compromises more visible. But neither system was perfect, and neither would ever be perfect. The goal, as always, was not perfection but resilience: the ability to absorb attacks, contain damage, and continue functioning even when individual endpoints failed.
The automaton’s second heart — the hardened command interface, the restricted capability set, the monitoring system that watched for anomalies — was not a guarantee of security. It was a bet. A bet that the cost of hardening was worth the protection it provided. And the bet, so far, was paying off.