A warehouse robot does not read a manual or think twice about a command. If its software holds a credential that can open the fleet dashboard, update firmware or release a door interlock, it will do exactly what any valid request tells it. That makes permissions a safety topic in robotics operations as much as a security one. This checklist applies IAMOps, the loose name for access rules handled as policy code that is drafted, checked and revised, to a fleet of robots and the services around them. Work through it with the people who run the fleet.

The Ops Atlas, in its write-up on IAMOps, defines the idea around people, workloads and automated agents. Robots are workloads with moving parts, so the framing fits neatly. The Atlas also says the term is a working label, so use the method and ignore the branding.

Part A: Who is acting

• Every robot has its own identity. A shared fleet credential means one captured unit exposes all units, and logs cannot say which one acted. Consider workload-identity systems of the kind the Atlas mentions, such as SPIFFE and its reference runtime, a pairing that moved to the top maturity tier of the CNCF in 2022.
• Controllers and gateways are separate principals. The fleet manager, the map service and the firmware pipeline should not share an account.
• Humans use personal accounts. No team login for the dashboard, however convenient.

Part B: What each actor may do

• Write the action list in plain words. For a picking robot: read its task queue, post status, request a charging slot. Anything beyond that must be justified.
• Separate read from change. Seeing a robot’s position is not the same as sending it a move command, and neither equals pushing new firmware.
• Add context limits. A command that releases a safety interlock might only be valid from the maintenance network and only while the zone is in service mode.
• Know which rules grant and which only cap. Per the Atlas, ceilings such as boundaries limit but never grant, and an explicit deny wins. Use a deny for actions robots must never perform, and keep it somewhere that ordinary grants cannot override.

Teams that run automated guided vehicles will recognise the care involved. The practical advice in a full guide to AGV warehouse automation treats traffic rules and zone limits as first-class design inputs, and permissions deserve the same treatment.

Part C: How credentials live

• No permanent keys on devices. Robots get short-lived tokens, renewed through a verified exchange. A stolen unit then yields a credential that expires within minutes or hours.
• Audit anything older than ninety days. The Atlas lists the share of long-lived credentials as a core metric. Set a target and track it monthly.
• Trust rules are exact. If the cloud side accepts tokens from a pipeline, the rule should name one repository and one environment, not a wildcard pattern.
• Plan the unit lost in the field. Write down how to revoke one robot’s identity in under an hour.

Part D: Where the rules live

• Policies in version control. Each change has an author, a reviewer and a date.
• Tests for allowed and forbidden requests. For example, a picking robot may post status and may not request a firmware update. Include a test where an expected attribute, such as the zone tag, is missing.
• Validate before deploying. The Atlas warns that in one policy language an erroring rule is skipped, so a forbid guardrail can silently stop working. A schema check catches the typo.

Drone operations raise the stakes further, since an unauthorised command can have physical consequences. The overview in a simple guide to drone robotics platforms for real teams is worth a read alongside this checklist when your fleet includes aerial units.

Part E: Measure and review

• Utilisation. For each role, compare the actions permitted with the actions used. Remove the idle ones, after asking whether a seasonal task, such as a quarterly recalibration, explains the silence.
• Wildcard share. Count allow statements that use wildcards and aim to lower the figure each quarter.
• Refusals after releases. Track how many denials follow each software release per hundred changes. Spikes point to missing tests.
• Time to grant. Measure how long a legitimate request waits. Accepting a modest increase for lower risk is a legitimate trade, so long as the number is visible.
• Exceptions register. List every deliberate departure, with an owner and an expiry.

Part F: Maintenance and change windows

• Temporary access ends itself. A technician who needs elevated rights for a firmware visit receives them for the window and nothing more.
• Emergency stop paths stay separate. The ability to halt a robot should be available to more people than the ability to reconfigure one, and it should never depend on a cloud round-trip.
• Record who changed what. After each maintenance window, compare the log with the approved work order and note any difference.

Scoring yourself

Mark each item done, partial or missing. If more than a third are missing, concentrate on three actions first: one identity per robot, short-lived credentials, and one tested guardrail on the most dangerous command. The Atlas offers a thirty-day starting plan that begins with owners and an inventory, and that is an excellent first move for a fleet team as well.

Repeat the audit monthly for the first quarter, then quarterly. Invite someone from the floor operations side to each session, because they know which commands the robots really receive on a busy shift, and that practical knowledge often exposes permissions nobody remembers granting. Keep the checklist in the same repository as the policies, so the review has a record and improvement is visible.