Teams that build and run machine learning systems tend to assume identity is somebody else’s department. The directory belongs to IT, the login screen belongs to security, and the data scientists just want their notebooks to open. That assumption is exactly why IdentityOps keeps surfacing in postmortems. This article takes six popular beliefs about the discipline and tests each against what the Ops Atlas and the public incident record say, with an eye on the way AI and automation workloads change the picture.
A caution on terms first. The Atlas describes IdentityOps as an emerging label with no settled definition. Different vendors stretch it to cover more or less ground. Treat everything below as one reading of the field rather than a standard.
Myth one: “Single sign-on puts all our risk in one basket, so we should avoid it”
This one sounds like common sense and fails on inspection. Central sign-in does concentrate something, but what it concentrates is control. Without it, you have dozens of local password stores, each with its own recovery path and its own forgotten admin. The Atlas position is that the identity provider should be handled as the most protected tier in the estate, with its administrators using the strongest sign-in methods first and its trust relationships reviewed on a regular schedule.
The evidence for centralisation is practical. A leaver can only be removed everywhere quickly if there is a place from which to do it. Teams running experiment trackers, feature stores and model registries from separate logins will find that offboarding takes the longest in precisely these tools.
Myth two: “Disabling the account finishes the job”
Disabling is a first step, not an end state. The Atlas stresses that sessions and tokens can outlive the account that produced them. Access tokens on a major cloud identity platform commonly last somewhere between one and one and a half hours by default, and where continuous access evaluation is switched on they can stretch to around a day. Revoking sessions helps, though it can take a few minutes to land, and a revocation issued at the central login service may leave app-level sessions untouched.
For an AI team the lesson is concrete. A departed engineer’s long-running training job, pipeline trigger or notebook server can keep a working credential well after HR has closed the file. Build a leaver sequence that disables the account, cuts sessions, tells each application to deactivate the user and records a timestamp at every step.
Myth three: “Our multi-factor rate is one hundred percent, so we are covered”
Ask what the one hundred percent is made of. The Atlas lists “MFA everywhere” counted from text-message codes and push approvals as an anti-pattern, because those methods can be phished, relayed or socially engineered. Only security keys using FIDO2 or WebAuthn, and certificate-based smart cards, meet the strict phishing-resistant bar. Passkeys that sync between devices are excluded from the very highest assurance level since their keys can be exported.
The better figure to track is usage, not enrolment. The Atlas shows a case where coverage was 1,190 of 1,400 people, around eighty-five percent, yet fewer than two thirds of actual sign-ins went through the strong method. The gap meant policy still accepted weak ones. Roll out in order of blast radius: identity and cloud administrators first, after that anyone handling mail, remote entry or payment approval, and finally the rest of the staff.
Myth four: “Identity is about people, and our risk is in the models”
Non-human identities deserve more attention than most data teams give them. Service accounts, API keys, automation tokens and workload credentials multiply with every pipeline you add. The Atlas describes a lifecycle: take an inventory, register an owner, purpose, expiry and review cadence for each, prefer short-lived credentials, rotate them, and at the end retire the account with proof: disable it, leave it idle for a spell, then delete.
The public incident record is uncomfortable reading on this point. In the 2024 Snowflake customer intrusions, which Mandiant tracked as UNC5537, the Atlas notes that accounts lacked multi-factor sign-in, some credentials had not been rotated for as long as four years, and no network allow lists were in place. Roughly 165 organisations were notified. In the 2023 Okta support case, a service account credential was found in an employee’s personal storage, and a customer that was affected had failed to rotate one token and three service accounts believed to be unused. None of this was a failure of cryptography.
That last sentence is the Atlas conclusion about every cited incident: process was defeated, not mathematics. It applies cleanly to a model-serving account sitting in a shared notebook that nobody remembers creating. An earlier article about AI helping managers decide better argues for trusting machine output; the same trust only holds if the machine’s own credentials are governed.
Myth five: “Just-in-time account creation is enough, because people appear when they log in”
Creating an account at first login is convenient and leaves a gap. It has no removal channel. Nobody tells the application the person left, so the account lingers until someone sweeps it up. The Atlas notes that one container vendor recommends SCIM provisioning with just-in-time creation turned off, which provides both a way in and a way out.
Note also that the SCIM standard leaves the interpretation of an inactive flag to each application, and platforms behave differently: one never sends a delete request, another does under certain conditions. Test your own applications by deactivating a dummy user and checking what actually changes. Do not assume a vendor dashboard tick means access was removed.
Myth six: “The help desk will sort out lost access, so recovery is not a security topic”
It is arguably the most attacked surface. The Atlas draws on CISA’s advisory on Scattered Spider, which describes help-desk password and factor resets, SIM swaps, push bombing and rogue federated providers. Phone call-backs are not dependable under those conditions. The recommended shape is tiered: ordinary users recover through a second enrolled authenticator, assisted recovery issues a one-time pass only after a manager confirms the person on live video or in person, and privileged accounts need supervised identity proofing and sign-off from a second administrator. Each recovery event should also notify the account holder.
Why automation raises the stakes
Every new agent, scheduled job or inference endpoint you deploy usually arrives with a credential, and those credentials rarely appear on an HR roster. People leave and trigger a process; machines simply persist. If your organisation adds ten pipelines a quarter and retires two, the register of machine identities grows faster than anyone’s memory of it. That is why the Atlas pairs a monthly report on credentials nearing expiry with a daily reconciliation of the human directory against HR records: the human list changes by events, the machine list changes by accumulation.
What to do on Monday
The Atlas offers a thirty-sixty-ninety plan that suits small technical groups. In the first thirty days, assign owners, build an application register, put security keys on administrators and write the recovery script. By sixty days, connect HR data for one population, use SCIM for the ten most used applications and complete a machine-identity inventory. By ninety, add session revocation, run the first leaver drill and alert on resets and federation changes. A sensible footnote: do not buy governance tooling before your HR data is clean, and if the team is tiny, a separate practice may be overkill.
For the full scope description, including what the Atlas leaves out, see the Ops Atlas page on IdentityOps. If your estate also leans on managed services, the overview at this write-up on support services for cloud, Kubernetes, security and reliability covers the surrounding operational layer.
Scoring the myths
Not one of the six beliefs survives contact with the evidence, but each contains a grain worth keeping. Single sign-on really does demand care. Disabling really is a necessary step. Strong factors really do reduce risk. The error is stopping early. Treat identity as an operating routine with measurable service levels, owners and drills, and the AI platform you run stops depending on credentials nobody can account for.