Every agent, every integration and every automated workflow needs an identity of its own: a credential, a scope and an owner. Enterprises are working out that their identity platforms were built for people and are now being asked to carry machine identities in volumes nobody planned for, and that gap, more than model capability, is what’s holding AI programmes back.
Every agent needs an identity
The conversation about AI has been about what the models can do. The conversation that decides whether any of it ships is about what each of those agents is allowed to do, on whose authority, and how you take that authority away.
A human identity is messy and forgiving. Someone joins, someone leaves, and a person notices when an account keeps working after they’ve gone. Machine identities don’t work that way. A service account created for a project in 2019 is still there. A workload identity with broad permissions is still broad. An agent with a credential sitting in a configuration file is still live, and nothing about it looks unusual.
The volume is the part that catches people. Every new system, every new integration and every new agent adds more machine identities than the last generation did, and the inventory of what exists, let alone what it can reach, is usually the piece nobody has.
The authentication estate was built for people
In the briefs we take, the authentication estate has usually run the way it did a decade ago: federation protocols like SAML and LDAP, a directory, and a set of integrations that grew one project at a time.
That holds together while the users are staff and customers. It starts to strain when the thing authenticating is a workload, and it breaks down when the volume climbs and access has to be just in time rather than standing. The move to token-centric authentication, where access is proven per request and scoped to what’s needed, is the direction the market is going, and the architecture behind it is genuinely hard to get right.
The gap we get briefed on is narrower than it looks. The strategy usually exists and it’s often sound. What’s missing is a senior practitioner who can turn it into architecture, patterns and a sequencing plan that delivery teams can build against, and who’ll hold that position when a project asks for an exception. It’s an awkward gap because it doesn’t sit inside any one team’s remit, so it goes unnoticed until a programme stalls.
The governance layer underneath
There’s an unglamorous layer under all of this, and it’s where a lot of programmes are stuck. Identity governance and lifecycle management is the work that decides who should have access, proves it was granted properly, and removes it when it should go. When a governance deployment isn’t delivering, the visible symptom is audit findings that stay open, and the underlying problem is usually that nobody senior owns the outcome.
This is the part of identity that never makes it into a strategy document, and it’s the part that has to be true before anything modern sits on top of it. A token-centric authentication programme running over a lifecycle process nobody trusts has moved the problem rather than solved it.
Integration is the other half, and it’s usually discovered late
Identity decides whether an agent is allowed to reach something, and integration decides whether it can reach it at all. The two arrive together more often than not, because they’re the same problem seen from two sides, and a business that runs them as separate programmes usually ends up designing the same architecture twice. From where I sit the demand is for both, combined and separately, and it’s the enabler rather than the AI itself.
Integration work has a habit of being discovered mid-programme. The model is chosen, the use case is agreed, and then someone establishes that the data sits across three systems, none of which has a governed way of being read. That’s a programme of work against a deadline that was already announced.
What this means for hiring
The profile everyone wants sits at an intersection rather than inside a discipline: deep identity expertise, cloud-native architecture, token-based authentication design, and enough seniority to carry the argument with an executive who doesn’t want to hear it. Plenty of people are strong in one of those. The intersection is thin because each of those skills is normally built in a different function over a different decade, so almost no career puts them all in the same room.
The practical consequence is a sequencing problem the brief rarely captures. The architecture has to be settled and defended before a delivery team can build against it at speed, and on these programmes the two tend to happen at once because the deadline was set first. That’s why so much of the work gets briefed as a contract engagement with a permanent owner behind it, rather than as one hire expected to do both.
It’s also worth being honest about what the work is. Platform certification tells you very little about whether someone has owned an architecture, and a great many capable people have administered an identity or integration platform faithfully for years without ever deciding what it should be. What separates them isn’t the tools. It’s what they designed, what they refused to build, and what happened next.
Frequently asked questions
Where this leaves the programme
If you’re planning AI work and you haven’t yet established what your machine identity position is, that’s the first conversation rather than a later workstream. It sets the timeline more than anything in the model layer, and it’s much cheaper to find out now than halfway through a programme with a date already announced.
I [run identity and architecture searches](/what-we-do/technology-recruitment/identity-and-access-management/) on contract and permanent, and the conversation is more useful before the brief is written than after.
