Your Next Employee Doesn’t Have a Pulse

Your next employee may not need a desk, a laptop, a parking space, or access to the break room. It will not complain about the office temperature, schedule a meeting that could have been an email, or mysteriously disappear five minutes before a difficult conversation. It will never request vacation, submit an expense report, or spend twenty minutes trying to remember whether its password ends with an exclamation point or a number.

It may, however, need access to your email, SharePoint, ticketing system, source code, customer records, financial systems, collaboration tools, and security data.

That should probably get everyone’s attention.

Especially before someone gives it access to everything because “the demo was really impressive.”

In the first article in this series, I argued that we need to stop thinking about artificial intelligence only as technology. If AI can read information, communicate with people, retrieve organizational knowledge, perform tasks, and increasingly take action on behalf of the business, then from a cybersecurity perspective it begins to behave much more like an identity.

If that is true, the next logical question is what kind of identity it most closely resembles.

I think the answer is surprisingly simple.

An employee.

Not literally, of course. Your AI does not have career goals, a 401(k), or a secret LinkedIn profile it updates after a particularly frustrating staff meeting. But when you look at how AI operates inside an organization, the similarities are hard to ignore. Employees get identities. AI gets tokens. Employees get access to applications. AI gets connectors. Employees receive training. AI receives prompts, context, and retrieval sources. Employees follow policies. AI gets guardrails. Employees have supervisors. AI needs monitoring.

And both can make mistakes.

The terminology is different, but the underlying security problems are remarkably familiar.

Employees Get Usernames. AI Gets Tokens.

When a new employee joins an organization, one of the first things IT does is create an identity. The employee gets a username, email address, authentication method, and access to whatever systems are required for the job. Their actions can be logged, their permissions can be reviewed, and when they leave, their account can be disabled.

Nobody considers this particularly innovative. It is simply how identity management works.

AI needs the same basic treatment.

The mechanics may look different. An AI agent might authenticate through an API token, managed identity, certificate, service account, application registration, or OAuth permission. The technical implementation matters, but the larger question matters more: What identity is performing the work?

That becomes especially important when AI starts taking action.

Imagine an AI assistant updates a ticket, sends a message, changes a configuration, or initiates a workflow using a developer’s personal credentials. Six months later, something goes wrong and the logs show that the developer performed the action.

Did they?

Or did the AI?

Or did another employee instruct the AI to do it?

If answering that question requires three meetings, a forensic investigation, and someone drawing arrows on a whiteboard, we probably did not design the identity correctly.

An AI performing work should be independently identifiable. We should know when the human acted, when the AI acted, and ideally which human initiated the AI activity.

Accountability starts with knowing who—or what—did something.

Employees Get Access. AI Gets Connectors.

After an employee receives an identity, we give them access. Their role determines which applications, files, and systems they can use.

At least, that is the theory.

AI works in much the same way, except the word we tend to use is connector, which somehow makes the whole process sound much less dangerous.

Connect it to SharePoint.

Connect it to Teams.

Connect it to Salesforce.

Connect it to ServiceNow.

Connect it to GitHub.

Connect it to email.

Pretty soon the AI is connected to half the organization, and someone asks why we cannot connect the other half because it would produce “better context.”

Now imagine a new employee making the same request.

“I’ll need access to Finance, HR, Legal, Security, executive email, customer records, source code, and everything in SharePoint.”

Someone would probably ask what their job is.

When the AI asks, we sometimes call it integration.

From a security perspective, the question is exactly the same: Does this identity need this information to perform the work we expect from it?

A connector is not merely a convenience. A connector is access.

And access is permission.

That distinction becomes important because AI can consume information at a scale humans simply cannot. A person may have access to thousands of files and never look at most of them. AI can search through those files in seconds, correlate information across repositories, and surface relationships that a person may never have noticed.

That ability is one of the reasons AI is so valuable.

It is also one of the reasons access matters so much.

Employees Get Training. AI Gets Context.

New employees do not simply receive credentials and get released into the organization with instructions to “figure it out.”

Usually.

They receive training. They learn company terminology, processes, policies, systems, and expectations. They learn who approves what, where information lives, and which procedures everyone claims are documented even though the only person who actually understands them is Susan from Accounting.

AI needs organizational training too.

We may call it system instructions, prompts, retrieval-augmented generation, knowledge bases, embeddings, context, or reference material, but the purpose is similar. We are teaching the AI how our organization operates and giving it the information required to do its job.

That raises a question organizations may not enjoy answering:

How good is the information we are giving it?

Every organization has old procedures, outdated policies, abandoned project plans, contradictory documentation, and multiple files named some variation of FINAL, FINAL2, and FINAL-USE-THIS-ONE.

Humans eventually learn which information is current and which documents everyone quietly ignores.

AI may not.

If we connect an AI assistant to a decade of organizational information without identifying what is authoritative, we should not be surprised when it confidently provides the correct answer from 2019.

That is not necessarily an AI failure.

It may simply be exposing an information-governance problem we already had.

AI does not magically fix bad information.

Sometimes it just finds it faster.

Employees Have Policies. AI Has Guardrails.

Employees are expected to follow rules. There are acceptable-use policies, security policies, data-handling requirements, codes of conduct, confidentiality rules, and dozens of other documents everyone promises to read before clicking the button marked “Acknowledge.”

The point of those policies is to establish boundaries.

AI needs boundaries too.

We tend to call them guardrails, but the idea is not especially new.

An AI may be allowed to summarize a security incident but not close it. It may prepare a customer response but not send it. It may review a proposed firewall change without implementing it. It may analyze financial information without approving a payment.

The important distinction is between can and may.

An AI may technically be capable of doing something. That does not mean the organization has authorized it to do it.

Humans have the same problem. Most employees are technically capable of walking into the CEO’s office and rearranging the furniture.

Corporate policy generally discourages this.

Capability has never been the same thing as permission.

AI does not change that.

Employees Have Supervisors. AI Needs Monitoring.

We do not normally hire an employee, give them access to sensitive systems, and then never pay attention to what they do again.

Their manager supervises their work. Security monitors authentication and access. High-risk activities receive additional scrutiny. Privileged activity may be logged or reviewed.

AI should not receive less oversight because it happens to run on a server.

In some situations, it probably needs more.

AI can process information at machine speed. It can interact with multiple systems, retrieve enormous amounts of data, and perform a series of actions much faster than a person.

That means simply logging the user’s prompt is not enough.

Imagine someone asks an AI assistant:

“Find our current remote-access policy.”

The prompt is useful information, but I also want to know what happened next. Did the AI retrieve the current approved policy from a known repository? Did it search three documents? Did it search 30,000 files across HR, Finance, Legal, Security, and a forgotten SharePoint site containing lunch menus from 2014?

The prompt tells us what the user asked.

The activity tells us what the AI did.

Those are not always the same thing.

If AI is going to become an identity inside the environment, security teams need visibility into both.

Employees Make Mistakes. AI Hallucinates.

People make mistakes all the time.

We misread instructions. We remember things incorrectly. We use outdated information. We send email to the wrong person. We confidently answer a question in a meeting and realize halfway through the sentence that we have absolutely no idea where we are going with it.

Humans invented hallucinations long before artificial intelligence.

We just did not have a technical term for it.

The difference with AI is scale.

A human employee may make one bad decision.

An automated AI system may make the same bad decision 5,000 times before anyone notices.

That means AI mistakes have to be treated as operational risk. Higher-impact actions may require human review. Uncertainty needs escalation paths. Activity needs logging. Systems need boundaries.

Most importantly, AI needs to be allowed to say, “I don’t know.”

We sometimes treat that response as a weakness.

It may actually be one of the most important controls we can build.

There is nothing particularly dangerous about uncertainty.

Confidence combined with uncertainty is where things get interesting.

Employees Can Leak Data. So Can AI.

Organizations have spent decades trying to prevent employees from exposing sensitive information. We use access controls, data classification, DLP, security awareness training, email protections, monitoring, and countless other controls.

Then AI arrives and someone connects it to every document the organization has produced since Windows 95.

What could possibly go wrong?

AI does not need malicious intent to expose sensitive information.

Neither do employees.

A user may simply ask a question without realizing the answer requires information they should not see. AI may retrieve something from an unexpected repository. It may combine information from multiple sources in a way that suddenly makes previously disconnected data sensitive.

That is part of what makes AI powerful.

It can find relationships humans miss.

But that capability works both ways.

The problem is not necessarily that AI broke the rules.

The AI may be using exactly the access we gave it.

That should make security teams uncomfortable in a productive way.

When AI surfaces information it should not have, our first question should not always be, “Why did the AI show this?”

Sometimes the better question is:

Why could it see it in the first place?

We Already Know More Than We Think

The comparison between AI and employees is not perfect, and it is not supposed to be.

AI is not human. It does not have judgment in the same sense, professional ethics, loyalty, intent, or an inexplicable desire to schedule meetings at 4:30 on Friday afternoon.

But from an identity and security perspective, the similarities are useful.

AI needs to authenticate.

It needs access.

It needs organizational knowledge.

It needs rules.

Its activity needs to be monitored.

It can make mistakes.

It can expose information.

And someone needs to be accountable for what it does.

None of those problems are entirely new.

What is new is the type of worker creating them.

That should actually be reassuring. Cybersecurity does not need to throw away everything we have learned about identity simply because AI is involved. In many cases, we need to apply those lessons more consistently.

And perhaps borrow a few ideas from another department while we are at it.

HR has spent decades figuring out how to bring new employees into an organization. Before someone starts, there is supposed to be a job. Someone approves that job. Someone becomes the manager. Expectations are set. Training happens. Performance gets evaluated. Responsibilities change. Eventually, the employee leaves.

IT built systems around that lifecycle.

Yet with AI, organizations sometimes jump directly from “We bought Copilot” to “Let's connect everything” without stopping to define exactly what this new digital worker is supposed to be.

Maybe deploying AI is not really the right analogy anymore.

Maybe we should start thinking about hiring it.

And if we are going to hire AI, that raises an interesting question:

Does AI need an HR department?

That is where we are going next.