Walk into just about any company, and you’ll see that every employee has some kind of identity. Maybe it’s a badge clipped to a belt, a username in Entra ID or Active Directory, an employee number in HR, or a handful of credentials that prove, yes, this person is who they say they are.
A physical badge might open doors. A digital identity? That’s your ticket to apps, files, databases, email, and a whole universe of cloud services. But really, both serve the same purpose: organizations need to know who’s asking for access.
AI needs the same thing.
In my last post, I talked about the idea of giving AI performance reviews. Of course, that only works if we can answer a deceptively simple question: Which AI actually did the work?
If the answer is “the AI,” we have a problem.
Picture trying to run a performance review for a department where every single person is named “Employee.” The logs say Employee opened a sensitive file, Employee created a ticket, Employee changed a customer record, and Employee sent an email. If you’re management, you’d want a lot more detail than that.
But organizations sometimes deploy a bunch of AI agents using one shared service account, API credential, or application identity—and then assume those logs are enough for real accountability.
They’re not.
AI needs a badge number.
I don’t mean a literal badge—though it’s kind of hilarious to picture a rack of badges labeled “Finance AI,” “Security AI,” and “That One Marketing Keeps Experimenting With.” What I mean is every meaningful AI worker should have a unique, managed identity that the organization can authenticate, authorize, monitor, review, and, if needed, revoke.
That might sound like a technical detail, but it’s actually one of the foundations of real AI governance.
Identity answers the first question in almost every access decision: Who are you?
For humans, we’ve spent decades coming up with better and better ways to answer that question. Passwords turned into multifactor authentication, then came certificates, device trust, biometrics, conditional access, passkeys, and risk-based authentication—each one adding another layer of confidence that the person (or thing) asking for access is legit.
Machines have identities too. Applications use service principals. Workloads use managed identities. Services use certificates or keys. Automation uses tokens. APIs use OAuth and scopes.
AI fits naturally into this world.
The mistake would be treating AI as somehow outside it.
If an AI agent can retrieve sensitive data, create records, send communications, or execute actions, it should not exist as an anonymous feature hidden inside a platform. It should have an identity that represents the role it performs.
Suppose an organization has three AI agents. One triages security alerts. One assists Finance with invoice analysis. One helps HR answer policy questions.
Those agents should not share the same identity.
The security agent needs access to security systems. Finance needs financial data. HR may need employee-policy information. If all three agents authenticate using the same service account, least privilege becomes nearly impossible. Either the shared identity receives the combined permissions of all three roles, or the organization creates increasingly complicated logic elsewhere to compensate for the fact that the identity model is wrong.
This is how service accounts become terrifying.
They start off with one clear purpose. Then another team needs them. Then a project adds a permission. A few years down the line, no one remembers who originally owned it. Suddenly, there’s an account named something like svc_prod_app01 with access to half the company—and a password last changed in a presidential administration nobody wants to talk about.
We do not need to repeat that history with AI.
A unique AI identity makes authorization cleaner. The Finance assistant receives Finance permissions. The Security assistant receives Security permissions. The HR assistant receives HR permissions. If one role needs additional access, that change applies to the specific identity rather than expanding a shared credential used by unrelated systems.
That also improves monitoring. If the Security AI suddenly begins querying payroll information, the behavior is clearly unusual. If everything operates through a shared “AI Service” identity, the same event may be much harder to interpret.
Identity provides context, and that context becomes essential as AI actions become more autonomous.
Authentication is part of the picture, but authentication alone does not solve the problem. Knowing which identity is requesting access is useful. We also need confidence that the identity is being used legitimately.
For humans, this is where controls like MFA, conditional access, device trust, and privileged access management come into play. For AI and machine identities, the equivalent controls may include certificates, workload identities, managed identities, short-lived tokens, vault-managed secrets, signed requests, and restricted API scopes.
The implementation will vary by platform, but the principle stays the same: credentials should be strong, protected, rotated where appropriate, and limited to the intended use.
Scattering hard-coded API keys through scripts isn’t a real identity strategy. Neither is leaving a production AI token in a file called keys.txt on someone’s desktop.
I mean, I’m sure nobody reading this has ever seen anything like that.
Definitely not lurking in a folder called Old.
AI identities also need lifecycle management. Human identities have a beginning and an end. An employee joins, receives an account, changes roles, receives different permissions, and eventually leaves. Mature identity systems try to follow that lifecycle.
AI should too.
When an agent is created, its identity should have an owner and a documented purpose. When the agent changes roles, its permissions should be reviewed. When the agent is retired, the identity should be disabled and its credentials revoked.
This all sounds straightforward on paper, but machine identities have always been tough to manage—mostly because they don’t walk into HR and hand in their resignation.
They just… stick around.
An AI proof of concept can disappear from everyone’s calendar while its token continues to work for years.
That’s how digital ghosts are born.
AI identities should therefore appear in access reviews just like other privileged or non-human accounts. Someone should periodically ask whether the identity is still needed, whether the permissions remain appropriate, whether the owner is still correct, and whether the credentials are being managed properly.
If nobody knows what an AI identity does, the answer shouldn’t be “leave it alone in case something breaks.”
That’s not governance.
That’s superstition.
Logging and traceability are where the badge-number concept becomes even more important.
Suppose a user asks an AI agent to update a customer record. Ideally, the logs should preserve several pieces of context. We should know which human initiated the request, which AI identity performed the action, what system was accessed, what change was made, and whether human approval was required.
That creates a chain of accountability.
Without it, the logs may simply show that the human user made the change even though the AI actually executed it. Or they may show that a service account performed the change without revealing which human initiated the request.
Both are incomplete.
The human and the AI are separate actors.
We should log them that way.
This distinction will become especially important when one AI can call another AI. That sounds futuristic until you look at agentic platforms today. A user may interact with one orchestrating agent that delegates a task to a research agent, which invokes another tool, which calls an automation, which changes a record.
At that point, “Who did this?” turns into a full-on adventure.
Identity has to survive the chain.
The organization should be able to trace the initiating user, the AI agents involved, the systems accessed, and the resulting actions. Otherwise, an incident investigation could end up looking like a corporate version of the children’s game where everyone points at someone else.
“It wasn’t me. The orchestration agent asked the finance agent, who called the workflow, which used the service principal.”
Perfect.
We’ve invented distributed accountability.
A strong identity architecture prevents that.
There is also a privileged-access question. Some AI workers will inevitably require sensitive permissions. A security agent may need to query privileged systems. An infrastructure agent may eventually be able to restart services or modify configurations. A database agent may have access to sensitive records.
Those AI identities should be treated as privileged identities.
That means stronger controls, more restrictive permissions, more detailed monitoring, shorter credential lifetimes, and potentially approval before certain privileges become active.
We already know how to protect privileged human accounts. Administrators should not use domain-admin credentials to browse the internet, read email, and sign up for the office fantasy-football league.
The same logic applies to AI.
An agent with powerful production permissions should not use the same identity for routine low-risk activities. Separating AI identities by function and privilege makes compromise, misuse, and simple mistakes easier to contain.
Identity also helps with attribution during failures. In the previous article, I argued that AI should receive performance reviews. If an AI makes an incorrect recommendation, causes an incident, or produces unusually good results, we need to know which system actually produced the outcome.
“AI generated this” is about as helpful as saying, “a computer did it.”
Which AI? Which version? Which configuration? Which identity? Which knowledge source? Which permissions? Which human initiated the interaction?
The more organizations rely on AI, the more those questions matter.
There is another benefit to assigning AI identities: it makes AI visible.
One of the risks organizations face is shadow AI. Employees and departments may experiment with AI services, build agents, create API integrations, or connect data without a central inventory.
If AI identities are formally registered, governed, and monitored, the organization begins to develop a picture of its AI workforce.
How many AI identities exist? Who owns them? Which departments use them? What systems can they access? Which are privileged? Which are inactive? Which ones were created for a pilot nobody remembers?
That inventory will eventually become as important as inventories of human users, service accounts, applications, and devices.
You can’t govern identities you don’t even know exist.
A badge number makes the worker visible.
Of course, giving AI a unique identity does not magically solve AI security. An employee badge does not prevent an employee from doing something foolish. A username does not prevent data leakage. Identity is the foundation on which authorization, monitoring, lifecycle management, and accountability are built.
But without that foundation, everything else just gets harder.
Least privilege becomes harder because permissions are shared. Monitoring becomes harder because actions are ambiguous. Performance reviews become harder because outcomes cannot be attributed. Offboarding becomes harder because nobody knows which credential belongs to which system. Incident response becomes harder because investigators cannot determine who or what acted.
A unique identity does not solve every problem.
It makes the problems solvable.
That’s why every meaningful AI worker needs a badge number. Give it an identity that matches its job. Protect its credentials. Limit its permissions. Log its activity. Connect its actions back to the human or process that started them. Review its access. Shut it down when the job ends.
Those are not new ideas.
We already do this for every other identity that matters.
AI just gives us a new reason to get them right.
And once every AI has a badge number, there’s another question you can’t avoid:
So, what can that badge actually see?
Because AI may not be malicious, but an identity that can read faster than any employee, remember more than any employee, correlate information across departments, and operate around the clock creates a very different kind of insider risk.
That is where we go next