TL;DR: Leadership sets an AI date on a business clock. Identity work runs on an IT clock. So the mandate shows up first. It happened on 11 client calls in 2026. Don't wait for the program to finish. Give every AI agent a small version of five identity jobs now: a record, an owner, an exit, a scoped credential, and a log.
Key takeaways:
Eleven IANS client calls between January 13 and August 10, 2026 showed the same pattern: an AI push on top of identity work that wasn't finished.
The shapes differ (a migration mid-flight, a missing team, a lopsided program), but the order of events is the same every time.
AI agents inherit every weakness in the human identity program, including weak leaver processes and permission creep.
Five small jobs give an agent a safe starting point: a record, an owner, an exit date, a scoped credential, and an attributed log.
NIST SP 800-63-4 covers people, so the agent rules you need are yours to write for now.
Why does the AI mandate arrive before identity is ready?
Because the two efforts run on different clocks. Leadership picks an AI date from market pressure, and it falls in a calendar quarter. Identity work runs on migrations, vendor contracts, hiring, and budget cycles, and it takes years. When the dates collide, the AI date wins, and the identity program has to carry the load it wasn't built for.
On July 31, 2026, a property insurer told me its leaders were pushing company-wide AI. Its identity governance product was new and still being stood up, and its multifactor policies were in progress. Secure remote access wasn't deployed yet. Leadership kept pushing anyway.
That call was not unusual. It was the eighth in a line, and the line goes back to January.
How many client calls showed the same pattern?
Eleven calls between January 13 and August 10, 2026 had the same order of events. An AI plan or mandate arrived, and the identity work underneath it was behind, mid-migration, lopsided, or missing. I counted them from my own call notes. Clients are described by sector here, and none are named.
The calls came in different shapes:
A healthcare company on January 13 was forming an IAM team from scratch. Accounts copied from a source system had caused permission creep, and its mover and leaver steps were weak on the SaaS side.
A medical device maker on February 27 was moving from Active Directory to Entra in the middle of a network-access evaluation.
A consumer products company on March 31 vetted every human through HR before creating a directory account. Agents arrived with no matching gate.
A regional electric utility on April 17 chose to finish identity first, on purpose, because it saw no safe way to grant temporary or elevated access without it.
A regional health system on May 29 and an investment firm on June 4 were both mid-migration between identity providers.
A century-old freight railroad on July 8 was excellent at creating and provisioning human accounts. It scored low on governing them afterward, and it saw agents as a new kind of employee.
A property insurer on July 31 and a mid-sized company on August 4 each ran a young identity program, and the August 4 client called its own identity governance poor.
A mid-market technology company on August 5 couldn't justify an enterprise governance platform, so it ran on checklists where its directory couldn't automate a step.
An equipment maker on August 10 called its readiness work "asset inventory first." It had no repository inventory, yet it planned coding agents against legacy code.
That's eleven calls, and the shapes vary a lot. The order of events doesn't.
What does an AI agent inherit from a weak identity program?
Every weakness the human program already has, and usually in a worse form. An agent is a non-human identity, meaning an account that acts without a person typing. It needs a record, an owner, scoped access, and an exit. If the program can't do those four for people, it won't do them for agents.
Take the leaver step. A weak leaver process means a person's access lingers after they go. For an agent, the same weakness means a credential keeps working after the project ends, the owner changes teams, the pilot is cancelled, or the budget runs out. Nobody gets an exit interview for a script.
Permission creep follows the same path. On the January call, accounts copied from a source system had piled up access nobody reviewed. An agent that borrows a person's token, or a copied service account, takes all of it.
The consumer products call showed the front door problem most clearly. People get vetted before the directory creates an account. Agents get created by a developer in an afternoon. So the sturdiest control in the whole program, the one at the door, doesn't apply to the newest identities.
The railroad showed the other side. Strong at provisioning, weak at governing afterward. That's the shape I'd expect most mature programs to have, and agents sit right in the weak half.
For a longer look at the owner problem, see the post on why every AI agent needs one accountable human.
What should you build first, before the identity program is done?
Build the smallest version of five jobs, for AI agents only. Don't try to fix the whole human program first. The five jobs are a record, an owner, an exit, a scoped credential, and a log. Each one fits on a form and a short review. None of them needs a new product.
1. A record. One list of every AI agent, what it does, which systems it touches, and which model sits underneath. A spreadsheet works. The equipment maker on August 10 had no inventory at all, and it still planned coding agents.
2. An owner. One named person per agent. A person, not a committee.
3. An exit. A date when the agent's access gets reviewed or ends. Put it on the record from day one.
4. A scoped credential. The agent gets its own account or token, with only the access its job needs. It never borrows a person's login.
5. A log. One line per action, tied to that agent's identity, so a bad day can be traced.
Small teams can do this. The post on how a small security team can govern AI shows how to extend the pillars you already have instead of starting a new program. And the five jobs answer a plain question: what can your AI agent access right now.
The utility on April 17 had the right instinct in one way. It wanted identity solid before it granted anything elevated. Most teams can't wait that long. The five jobs let you move without pretending the foundation is finished.
Where does NIST SP 800-63-4 fit?
NIST's Digital Identity Guidelines set the standard for how strongly you prove a person is who they say they are. The revision, SP 800-63-4, came out in 2025 in four volumes: the overview, identity proofing and enrollment, authentication, and federation. All four cover people. They don't tell you how to treat an agent.
The idea worth borrowing is the assurance level. NIST ties the strength of the proof to the risk of the thing being accessed. You can apply the same logic to agents. The weaker the identity underneath, the less autonomy the agent gets. A new agent with a shared credential should only read. One with its own scoped account, an owner, a review date, and a log can do more.
You can read the full set at NIST's SP 800-63-4 site. The pages I read cover people only. So the rules for agents are yours to write today, and the five jobs above are a fair draft.
Frequently asked questions
Should I pause AI work until identity is fixed?
No. A pause rarely holds once leadership has set a date. Pause only the agents that need more access than your identity program can safely give. Everything else can start at read-only with the five jobs in place, then earn more access as the foundation improves.
Do I need an enterprise identity governance product first?
Not to start. On August 5, 2026, a mid-market company told me its identity stack sat below the price point of an enterprise governance platform. It used checklists where its directory couldn't automate the step. That's a fair answer for agents too. A record, an owner, a review date, and a scope note can live in a form and a calendar.
Who should own the agent record?
Whoever already owns accounts and access reviews. For most teams that's the identity group. If you don't have one, give it to the security lead and name a backup. The record only works if one person checks it on a schedule.
How is an AI agent different from a service account?
A service account runs fixed code. An agent decides what to do next, so its actions vary. You still manage both with the same basics: a record, an owner, a scope, and an exit. The agent just needs tighter scope and a better log, because you can't predict its next move from its job description.
What should I tell leadership when the AI date comes before the identity work?
Tell them the date can hold if agents start small. Show the five jobs. Name the owner for each agent and give a date for the next access review. Leadership doesn't need the identity roadmap. It needs to know who answers when an agent does something unexpected.
The AI date is already set. The identity program won't finish before it, and the five jobs are what you can finish by Friday.