Humanoid identities in carmaking
Humanoids are on the factory floor. But who controls access?
As humanoids move from demo to shift work at plants including BMW Spartanburg, Acre Security CEO Kumar Sokka argues factories are deploying a new class of worker without the identity and access systems built to govern it.
Figure's humanoid completed an eleven month working shift at BMW's Spartanburg plant this year. Tesla is ramping Optimus at Fremont, while Boston Dynamics' Atlas is now working inside a Hyundai facility. Coverage of all three has settled on jobs and safety, but it has missed a narrower, more urgent question underneath every deployment decision - what is a robot allowed to touch? and who decides?
A humanoid on a plant floor has physical access to almost everything a human worker does; doors, machines, materials, server rooms, and with increasing frequency, more. Yet it typically sits entirely outside the access control and identity systems built over decades to govern who can go where inside a facility. It is, in effect, an insider that was never vetted, was never issued a credential anyone can revoke, and will never be offboarded in the way a departing employee is.
Kumar Sokka has spent his career on either side of that problem. Before becoming chief executive of Acre Security, a global physical security provider serving more than 100,000 customers across 25-plus countries, he spent 15 years at Rockwell Automation building and leading its Digital Business unit, and served as President and General Manager of LenelS2. AMS interviewed him on this overlooked aspect of how manufacturers should think about humanoid identity, access, and accountability before the fleet grows.
A worker with no badge
Sokka's starting position is simultaneously counterintuitive and intriguing. A humanoid should not be treated as a piece of equipment that happens to move around a factory. It should be treated as a worker.
"Treat the robot as an identity in its own right, not a tool," he says. "Every humanoid should have a unique, verifiable machine identity bound to that specific physical unit, and it has to carry more than a serial number, the software or firmware version it's currently running, its assigned owner or operator, and the task it's cleared to perform."
The reasoning behind including software version alongside identity is specific to what makes a robot different from a static piece of tooling. "The software version matters because a robot is only as trustworthy as the code on it, an update can change its behaviour completely, so the identity has to be version-aware," Sokka says. In practice, he argues, the robot should authenticate to a plant's access system much as a person badges in, "except its credential also asserts what it's running and what it's been told to do."
Building an identity a robot can carry
That framing has an immediate consequence for how manufacturers set up access in the first place. If the identity has to specify task and zone, then the permissions attached to it have to be equally specific, and Sokka is clear that the discipline required is one that security teams already apply to people.
"Least privilege, the exact discipline we apply to people, applied to the machine," he says. "Authorisation to fetch a part from one zone should grant that zone and nothing next to it, not the tooling, not the hazardous area, not the adjacent line, with a default of deny everywhere it hasn't been explicitly granted."
The risk he is describing is a familiar one dressed in new clothes. That means mapping the robot's operational permissions onto physical zones deliberately, rather than issuing broad standing access 'so it can do its job,', he says, “which is how a robot cleared for one cell ends up able to walk into twenty." His prescription is to scope access tightly to the task and the zone, and to time-box it to the job or the shift wherever that is technically possible.
The prescription bears weight because a humanoid's permissions are not a fixed attribute the way a person's job title roughly is for months or years at a time. They are closer to a live configuration state, which is where Sokka locates the genuinely new part of the problem.
The part current systems cannot do
Human access changes on a human timescale. A badge is updated over hire, role change or departure - a process generally measured in days. A robot can be reassigned or remotely updated in seconds, and Sokka's point is that this is not a matter of degree, but an entirely different kind of problem. "A changed robot is effectively a different worker on your floor," he says.
His advice is, at base, for access control to become dynamically event-driven rather than static. "When the software version or the assigned task changes, permissions should re-validate automatically, and if something looks wrong you need to revoke access in seconds, not on the next audit cycle." Sokka argues that most physical access platforms were built for slow-moving human identities and cannot do this on their own. "Closing the gap means integrating physical access with the IT and OT systems that actually know the robot's live state, so the door knows the moment the robot changes."
He points to a broader shift already under way in machine identity security toward ephemeral, context-aware credentials that expire the instant a task ends, and argues physical access needs to move in the same direction.
Accountability agreed before, not argued after
None of this solves the question of who answers for a robot that goes wrong, and Sokka is clear about the risk of leaving that question open. "The one thing you can't allow is for 'the robot did it' to end the conversation," he says.
His view is that responsibility is inherently shared across the manufacturer of the robot, the integrator that deployed and configured it, and the operator running the access policy it works under, but that the split has to be settled in advance. "That split has to be agreed before deployment, not argued after an incident." What makes such an agreement enforceable, in his account, is precisely the identity infrastructure described earlier. "If every action is tied to a specific unit, its software version, its owner and its task, then any physical movement can be traced back to an accountable party. Without that, responsibility diffuses across three or four vendors and nobody actually holds it."
One timeline, not three archives
Accountability of that kind depends on being able to reconstruct exactly what happened, and Sokka argues most facilities currently cannot do so cleanly. "A useful trail lets you answer one question instantly, which robot, running which software, authorised by whom, went where, and when, with the OT and access data sitting right alongside it."
And following the thread, we surmise that the obstacle is organisational as much as technical. "Today those facts usually live in three separate places, the OT historian, the identity store, the physical access log, that don't talk to each other, so reconstructing an incident means stitching timelines together afterwards under pressure." His preferred alternative is a single, continuously built record, "so it's there before you need it, not assembled once something has already gone wrong."
The humanoid did not create this problem
Asked whether humanoids represent a genuinely new physical security problem or simply expose an old one, Sokka comes down firmly on the latter. Factories already run on a large population of non-human identities, PLCs, AGVs, AMRs, sensors and service accounts, alongside a rotating cast of contractors, and he argues that these are, across the industry, among the worst-governed identities of all. He cites industry findings that the average enterprise now has more than 80 non-human identities for every human one, with most organisations unable to say how many they have or what those identities can reach.
"The humanoid doesn't create that problem. It makes it walk around," Sokka says. Because it looks and moves like a person, he argues, it forces a question plants have generally been able to avoid, whether they actually govern the identities and permissions of the non-human things already on their floor.
"If a manufacturer can't answer that cleanly for its AGVs today, the first humanoid will expose it, which is why I'd treat that deployment less as a new threat and more as the trigger to finally fix identity governance for every machine on site."
Six controls before the fleet scales
Asked what he would tell an automotive manufacturer deploying its first humanoids today, Sokka offers six essential controls. Give every robot a unique, verifiable identity tied to the unit, its software version, its owner and its task. Grant least-privilege, zone-scoped access, only where the task needs it, with deny by default everywhere else. Build in instant revocation, an actual kill switch rather than a support ticket, so a robot's physical access can be cut in seconds if its software changes or it behaves oddly. Pull identity, task, authentication and physical movement into one audit timeline, with OT data alongside it. Fix accountability across manufacturer, integrator and operator before the robot arrives on site. And treat the rollout itself as the moment to bring the wider non-human identity estate under control, since the humanoid is simply the most visible member of a machine workforce plants already employ.
"Governance first,” he says, “then scale the fleet."
Read more stories on Humanoid Robotics...
-
Why factories need an AI orchestration layer, not more apps
Maneva's Rae Jeong argues automotive plants are drowning in disconnected AI point solutions. The fix, he says, is not another dashboard but a layer that lets a plant manager simply ask what went wrong.
-
Shanghai Electric expands AI robotics for industrial manufacturing
Shanghai Electric has unveiled a new generation of 'embodied' AI robots, industrial AI agents and an AI-native smart factory architecture at WAIC 2026, signalling a broader push to embed autonomous intelligence across manufacturing operations.
-
BMW expands humanoid robotics software at Landshut plant
BMW is establishing its Landshut plant as a centre for humanoid robotics software development, advancing AI models, simulation and robot training to support future manufacturing applications alongside pilot projects in Leipzig and Spartanburg.
-
Mercedes production chief, Michael Schiebe, backs AIand flexible EV strategy
Mercedes-Benz production chief Michael Schiebe outlines how AI, flexible manufacturing and localisation will help balance cost pressures, EV uncertainty and premium quality demands as the automaker ramps up a wave of new models.