Controlled Autonomy in Security Robotics: The Honest Operating Model

Autonomy, in the security context, is not a marketing claim. It is a legal posture, and most products on the market cannot hold it.

A machine that patrols a perimeter, classifies an intrusion, and acts on that classification has, at some point in the sequence, made a decision with consequences. If those consequences fall on a third party, the question of who decided becomes the only question that matters. The vendor will point at the operator. The operator will point at the algorithm. The algorithm will point nowhere, because algorithms do not point. The result is a liability vacuum, and liability vacuums close in court, not in product brochures.

Boswau + Knauer has chosen a different operating model. We call it controlled autonomy. The robot acts on routine. The operator acts on exception. Both acts are logged in the same data structure, with the same timestamp resolution, on the same evidentiary footing. This is not a compromise between full autonomy and remote operation. It is the only architecture that survives a serious review by an insurer, a regulator, or a court.

Why full autonomy fails the legal test

A fully autonomous security robot is a system that perceives, decides, and acts without human intervention. In a laboratory, that sequence is elegant. In a real environment, it is unworkable, and not because the technology is immature. The technology is workable for narrow tasks. The problem is that the legal frameworks under which security operations function in Europe, North America, and most of Asia presume an identifiable decision-maker for any act with material consequence. Property damage, personal injury, wrongful detention, breach of privacy, escalation of force. Each of these categories requires a name on the file.

When the name is the algorithm, the file does not close. The manufacturer is asked to stand in for the decision, and most manufacturers, ourselves included, are not willing to absorb that exposure. Insurance carriers know this. They underwrite the operator, not the machine. CISA guidance on operational technology, NIST CSF 2.0 on identification and governance, and the IEC 62443 family on industrial control system security all converge on the same point: a system that produces consequential outputs must have governance that names the responsible party at each step. ISO 27001 does the same for information assets. ASIS International publications on security operations describe the same expectation in plain operational terms.

The marketing literature of full autonomy elides this. It speaks of "decision-making robots" and "autonomous response." When pressed, the same vendors quietly add a human in the loop, but they do not redesign the architecture around that human. The human is a footnote. In controlled autonomy, the human is a structural element. The architecture is built around the handover, not around its absence.

We made this choice early. It cost us in pitch decks and trade shows, where competitors promised more. It paid us in long contracts, where customers signed because their legal departments could approve what we built. Operators do not buy what their lawyers cannot defend.

The decomposition of decisions

Controlled autonomy works because it decomposes the security task into classes of decisions, each with a defined owner. The decomposition is not academic. It is operational, and it determines what the machine does, what the operator does, and what the system records.

The first class is routine perception. The robot moves along a route, fixed or randomized, and records what it sees, hears, and measures. It classifies the environment against a baseline. Background, weather, expected movement, scheduled vehicles. This class is fully delegated to the machine. No operator approves a routine frame. The volume would be unmanageable, and the value of operator attention would collapse.

The second class is routine response. When the robot detects a condition that matches a pre-approved pattern, it executes a pre-approved action. A door closes. A light activates. A spoken warning plays. A recording is escalated to a higher resolution. These actions are bounded. They do not include force, they do not include detention, they do not include any irreversible step. The operator does not approve each one. The operator approves the policy that defines them, and that approval is logged with a version number.

The third class is exception. When the robot detects a condition that does not match the pre-approved patterns, or when confidence in classification falls below a defined threshold, the system stops acting and starts asking. The frame, the sensor data, the location, the timestamp, and the candidate classifications are pushed to the operator. The operator decides. The decision is logged with the operator's identity, the time of decision, and the reasoning, in either free text or a structured tag set.

The fourth class is intervention. When the operator's decision implies physical contact, dispatch of personnel, contact with law enforcement, or any step with legal weight, the decision is handled outside the robot. The robot may continue to observe and record. It does not act on the intervention class. This separation is what makes the model defensible. The machine never crosses into the space where its actions could be questioned in a way it cannot answer.

This decomposition is not unique to us in its conceptual outline. It draws on the same logic that NIST 800-53 applies to access control and incident response, where roles are separated and approvals are documented. What is unique is that we have built it into the hardware and software architecture, not into a manual that operators are expected to follow.

The audit trail as primary product

In a controlled autonomy system, the audit trail is not a byproduct. It is the product. The robot is a means of generating the trail. The operator console is a means of completing it. The software platform is a means of preserving it. Everything else is secondary.

This reframing matters because it shifts what we optimize for. A vendor that treats logging as compliance overhead will produce logs that satisfy compliance and nothing more. A vendor that treats logging as the deliverable will produce logs that survive cross-examination. The difference is visible in the data structure, the retention policy, the integrity guarantees, and the ease of export.

Our system logs every classification, every action, every operator decision, and every system state transition with a timestamp resolution that allows reconstruction at the level of individual perception cycles. The log is append-only. Entries are signed. The signing keys are managed under a scheme that aligns with ISO 27001 controls on cryptographic key management. The log is exportable in formats that customers' counsel can hand to opposing counsel without translation.

Three properties matter beyond the basic structure. The first is completeness. A log that captures only alerts misses the context in which alerts emerged. We log the routine, not because the routine is interesting, but because the routine establishes the baseline against which the exception is judged. The second is immutability. A log that can be edited after the fact is not a log. It is a draft. We use append-only storage with cryptographic chaining, so that any tampering is detectable by simple verification. The third is intelligibility. A log that requires the manufacturer to interpret it is a log that belongs to the manufacturer. We document the schema and provide reference tools so that the customer's own systems can read it.

The audit trail is also what makes the insurance conversation possible. Carriers underwrite risks they can measure. When the policyholder can produce a continuous, signed, intelligible record of what their security system perceived, decided, and recorded over a measurable period, the carrier has something to work with. Premiums respond. GDV and equivalent industry bodies in other jurisdictions are increasingly explicit about this. The NICB and ASIS International publications track the same shift in commercial insurance.

The geometry of liability

Liability in a security operation is not a single line. It is a geometry. Where the line falls depends on who decided, what they knew, what the system told them, what they did with what the system told them, and whether the system itself was operating within the specifications its manufacturer warranted.

A fully autonomous system collapses this geometry into a single point, the manufacturer, and the manufacturer cannot bear it. A remote-operated system pushes everything to the operator, who is then responsible for sustained attention that no human can deliver across long shifts and many sites. A controlled autonomy system distributes the load. The manufacturer warrants the perception and the policy execution. The operator warrants the exception handling. The customer warrants the configuration and the deployment context. Each party owns what they can control, and nothing else.

This distribution is reflected in our contracts. We warrant that the perception pipeline meets defined classification accuracy thresholds under specified environmental conditions. We warrant that the policy engine executes only the actions it has been configured to execute. We do not warrant that the operator will make the right call on every exception, because that is not within our control. We do warrant that the operator will see the exception, with the data needed to decide, within a time window we measure in milliseconds.

The customer warrants that the configuration matches the site. A robot configured for a construction perimeter and deployed on a hospital grounds will produce inappropriate outputs, and the responsibility for that mismatch belongs to whoever made the deployment decision. We provide audits, three to five days on site, that establish whether the configuration matches the context. The audit produces a report the customer owns. They can use it with us or without us. The book BOSWAU + KNAUER. From Building to Security Technology describes the audit deliverables in detail, and they are not abstract. Six specified deliverables, defined before the work begins.

The operator warrants the exception handling within the scope of their training and the policies their organization has approved. Where the operator is a contracted security firm, the contracts between customer and firm establish that scope. Where the operator is in-house, the customer's own policies establish it. In either case, the audit trail records what the operator saw, when they saw it, and what they did.

This geometry holds in court because it was designed to. We did not retrofit it to a product. We built the product around it.

What the architecture looks like in practice

A controlled autonomy deployment has four layers, and each layer has measurable properties.

The robot layer consists of mobile platforms with perception sensors, local compute for routine classification, and actuation for pre-approved responses. Local compute matters because network latency and network failure are not acceptable failure modes for a security system. When the connection drops, the robot continues to perceive and to execute routine policy. It does not escalate to exception, because exception requires the operator, and the operator is unreachable. Instead, it widens its recording, increases its sensor resolution, and waits. When the connection returns, the buffered data flows to the operator console with timestamps intact.

The communication layer carries data between robot and console under encrypted channels that align with IEC 62443 requirements for industrial control system communication. Authentication is mutual. Keys rotate on a schedule documented in the customer's onboarding package. The layer is monitored for integrity, and integrity failures are themselves logged.

The operator console is where exception decisions happen. The console presents the exception with the data needed to decide, in a layout that minimizes the time between perception and decision without compromising the quality of the decision. The console is not a generic dashboard. It is a tool built for the specific cognitive task of security exception handling, and it has been refined through field deployment with operators who told us where they were losing time and where they were second-guessing themselves.

The platform layer holds the logs, the policies, the configuration, and the integration with the customer's other systems. The platform speaks open interfaces, because we have decided that customers should not be locked in. They can read their logs without us. They can extract their configurations without us. They can, if they choose, run the platform on their own infrastructure. This openness is not a marketing concession. It is the operational consequence of treating the audit trail as the product. A locked-in audit trail is a less credible audit trail, because the customer cannot independently demonstrate its integrity.

Across all four layers, the design principle is the same. The machine handles what it can handle well, the operator handles what requires judgment, and the system records both with the same rigor. There is no layer where decisions disappear into a black box, and no layer where the human is asked to do what the machine should have done. The result is a system that does less than full autonomy promises and more than full autonomy delivers.

What holds

Controlled autonomy is not a step on the way to full autonomy. It is the operating model that holds under legal and commercial scrutiny, and it will remain the operating model as long as security operations are accountable to identifiable parties. Vendors who promise more are promising what they cannot deliver, and customers who buy the promise will pay for the gap when the first serious incident reaches counsel.

Boswau + Knauer builds systems that name the decider at every step, log the decision in a form that survives review, and distribute liability along lines that each party can defend. This is not the most exciting story in security robotics. It is the only one that lasts. Operators who have managed a serious incident in their career know the difference between a product that performs in a demonstration and a product that holds in a deposition.

For organizations weighing the move from conventional security to robotics, three paths are available. A sixty-minute confidential conversation, in which a member of the leadership describes what we would see in your situation. A three-to-five-day audit, with a defined scope and six specified deliverables you own at the end. A ninety-day pilot, on one site, with success criteria fixed before the start. The first costs you an hour. The third costs you a quarter. Each closes with you holding a document or a dataset you can use, with us or without us. That is the standard we hold ourselves to, because it is the standard our architecture is built around.

Frequently asked questions

What is controlled autonomy in security robotics?

Controlled autonomy is an operating model in which a security robot handles routine perception and pre-approved responses independently, while exceptions are escalated to a named human operator who decides and acts. The robot does not perform actions with legal weight. The operator does, within a defined scope. Every step, machine and human, is logged in a single audit trail with cryptographic integrity. The model exists because full autonomy cannot carry the liability that security operations generate, and because remote-only operation cannot sustain the attention modern sites require.

How are decisions split between robot and operator?

Decisions fall into four classes. Routine perception and routine response stay with the robot, executed against policies the customer has approved in advance. Exceptions, defined as conditions that do not match approved patterns or fall below confidence thresholds, escalate to the operator, who decides with the supporting data on screen within milliseconds of detection. Interventions with legal weight, such as dispatch, contact, or physical engagement, are handled outside the robot. The robot continues to observe and record, but does not act in the intervention class.

How is each decision logged?

Every classification, action, operator decision, and system state transition is written to an append-only log with timestamps at the resolution of individual perception cycles. Entries are cryptographically signed and chained, so that tampering is detectable through standard verification. The log schema is documented and the export format is open, so that the customer's own systems and external counsel can read the data without manufacturer involvement. Retention periods are set by the customer in line with their regulatory environment, drawing on ISO 27001 and IEC 62443 guidance.

Is this model accepted by insurers?

Insurers underwrite risks they can measure, and controlled autonomy produces measurable risk. The continuous, signed audit trail allows carriers to assess incident rates, response times, and operator performance against defined baselines. GDV publications in Germany, and equivalent guidance from carriers and bodies such as NICB and ASIS International in other markets, increasingly treat documented controlled-autonomy deployments as a positive underwriting factor. Premium responses vary by carrier and by sector, but the conversation is now possible in a way that fully autonomous claims do not allow.