Your Robot Fleet’s Hardest Attacker Is Already Authorized

What does the insider case break in the rest of the model?

The assumption that the principal is the problem. Nearly every control we have described on this site distinguishes a legitimate actor from an illegitimate one, then refuses the second. Per-robot identity establishes that a command came from a known device. A pre-actuation gate establishes that the requested action is permitted by policy. Both work by finding something wrong.

An insider presents nothing wrong to find. The credential is genuine because it was issued to them. The action is permitted because their role permits it. The robot is unmodified, the firmware attests correctly, and no skill has deviated from its declaration. Every check passes, and every check is right to pass.

This is not a gap in the controls so much as a category difference in the threat. Treating it as a gap leads to the wrong instinct, which is to make the gate stricter. A gate strict enough to refuse an authorized operator performing their job stops the fleet working, and the organization will correctly override it. The controls that help here are different ones.

How common is this, and how long does it run?

Common, and long. Ponemon's 2026 Cost of Insider Risks study, drawn from 354 organizations and 7,490 incidents, measured an average of 67 days to contain an insider incident, an improvement from 81 days in the previous study, with only 13 percent contained within 30 days ¹.

Set that number against the asset. Sixty-seven days of undetected insider activity in an IT estate is data moving somewhere it should not. Sixty-seven days on a robot fleet is a machine that moves, in a space that may contain people, under authority nobody has questioned. The containment figure is the same; what sits at the end of it is not.

Containment speed also drives cost directly. Ponemon reports organizations containing incidents in under 30 days at $14.2 million against $21.9 million for those taking more than 90 days ¹. Those are enterprise-wide annual figures rather than per-incident ones, and the direction is the useful part: the same incident costs materially more the longer it runs.

Is the dominant insider malicious or simply careless?

Careless, by more than two to one. Ponemon puts negligent insider incidents at 13.8 per organization per year against 6.3 malicious ones ¹. If you build an insider programme around detecting a disgruntled employee, you have designed for the smaller half of the problem.

This should feel familiar if you have read the rest of this site. When researchers scanned an agent skill registry, 81 percent of behavioural deviations traced to developer oversight rather than adversarial intent. When a control plane handed one owner authority over thousands of other people's robots, nobody attacked anything. The pattern repeats: the dominant failure mode is a legitimate participant doing something legitimate and slightly wrong.

Note also that carelessness is not the cheap category. At $747,107 per negligent incident against $742,125 per malicious one ¹, the cost of a mistake and the cost of an attack are within one percent of each other. Intent changes how you respond to a person. It changes very little about what the machine did.

What does an insider incident look like on a robot fleet?

Rarely dramatic. The instructive cases are ordinary actions taken by people entitled to take them, in circumstances that made them wrong. A commissioning engineer widens a speed or force limit to finish a stubborn integration and does not narrow it afterwards. An operator disables a zone restriction during a maintenance window and the shift changes before it is restored. A supervisor overrides a stop condition because the line is backed up and the robot has stopped for what looks like a sensor fault.

None of those is sabotage and none of them fails an authorization check, because each person held exactly the authority they used. What they have in common is that the resulting state persists after the reason for it has gone, and nothing in the system is tracking that the exception was temporary.

The malicious version is rarer and structurally similar. A departing employee retains console access through a notice period and issues commands they are still entitled to issue. The control that matters there is not detection of intent, which arrives too late to help, but how quickly authority can be withdrawn once someone decides to withdraw it.

Does a deny-by-default gate stop an authorized operator?

No, and we should not imply otherwise. A pre-actuation authorization gate answers one question: is this principal permitted to perform this action on this robot right now. When the principal is a genuine operator and the action is within their role, the answer is yes, the gate permits it, and the gate is correct. Selling that control as an insider defence would be selling something it does not do.

It is worth stating the shape of that limit precisely, because it also tells you where the boundary sits. The gate constrains what actions are possible for a given authority. It does not evaluate motive, context or whether this particular use of a permitted authority is a good idea. Those are different problems, and two of them are not technical problems at all.

This is the same discipline we applied when a robot has been rooted: in the piece on unpatched vulnerabilities, an on-robot gate does not save a unit whose locomotion computer is under an attacker's control. A control with a clearly stated boundary is more useful than one with an implied universal one, because you can tell what else you need.

What actually changes the answer?

Four things, and only one of them is exotic. Scope comes first: authority granted by robot, action class, zone and time rather than a single operator role that can do everything to everything. Most fleets have one role because it was faster to configure, which means the authority available on a bad day is the authority granted at hire.

Attribution comes second and is the precondition for everything else. If a command is bound to a named person rather than a shared console session, you can scope authority to them, require someone else to countersign, withdraw their access alone, and answer afterwards who did it. Without it none of those are available.

Dual authorization is the one control that genuinely prevents rather than detects. For a defined and deliberately small set of actions, require a second, different principal to approve before the actuator moves. This is the two-person rule, long used where a single person should not be able to cause an unrecoverable outcome alone, and it is enforceable by the same gate that permits ordinary work. The gate is not evaluating intent; it is counting signatures.

Withdrawal speed is fourth. Against a 67-day average containment time ¹, the interesting number is not how long detection takes but what happens in the minutes after it. If removing one person's authority means a firmware campaign or a trip to each unit, you do not have revocation, you have an intention. CISA frames insider mitigation as defining, detecting and identifying, assessing, and then managing the threat ²; the last step is where robotics fleets are usually least equipped.

Why do shared operator accounts undo the whole model?

Because they collapse attribution, and attribution is load-bearing for every other control. A shared console login on a plant floor is convenient, standard, and means that every command carries the identity of a workstation rather than a person. You can still enforce policy, but you can no longer say who invoked it.

This is the third distinct appearance of one defect on this site, which is usually the point at which it stops being a coincidence. A key shared across a model line meant one compromise reached every unit. That same shared key meant no unit could be cleanly retired. A shared human account means no action can be attributed to a person. Device credential, cloud token, operator login: the same choice, made in three places, producing three unrelated-looking failures.

The fix is unglamorous and it is not primarily a technology purchase. Individual accounts, individual credentials, and a record that carries the person rather than the terminal. What that buys is the ability to answer a question you cannot currently answer, and the ability to remove one person without removing the shift.

When is a two-person rule worth the friction?

When a single authorized command produces a consequence you cannot take back. That is a genuinely small set on most fleets, and keeping it small is what makes the control survive contact with operations. Candidates worth considering: widening a safety envelope or speed limit, disabling a zone restriction or interlock, pushing firmware or policy to more than a handful of units at once, and commanding motion in a space flagged as occupied.

Note what is not on that list. Ordinary task assignment, routine teleoperation, and day-to-day fleet management should not require a second approver, because a control applied everywhere is a control that gets bypassed everywhere. The two-person rule earns its friction precisely by being rare.

The practical objection is response time, and it is a fair one: requiring a second approver at three in the morning can mean the line stays down. That is a real cost and it should be weighed openly rather than assumed away. The counter-question is which of these actions you would want performed by one tired person alone, with nobody else aware it happened until the consequence showed up. For most of the list above, the answer decides itself.

What should a fleet operator check this week?

Three questions, answerable without buying anything. First, can you name the person behind the last ten high-consequence commands issued to your fleet, or only the console they came from. Second, list what a single trusted operator could do right now with no second approval, and ask which items on that list you would want reversed. Third, time how long it would actually take to remove one named individual's authority across the fleet, by trying it.

The worksheet below assumes throughout that the person is authorized and the command is permitted, which is what makes it a different exercise from the other tools on this site. It produces a dated summary, and everything runs in your browser.

Frequently asked questions about insider risk on robot fleets

References

1. Ponemon Institute. 2026 Cost of Insider Risks: Global (354 organizations, 7,490 incidents). published May 2026. www.ponemon.org/news-updates/blog/security/lessons-learned-f
2. Cybersecurity and Infrastructure Security Agency (CISA). Insider Threat Mitigation Guide. 2022. www.cisa.gov/resources-tools/resources/insider-threat-mitiga