Blog

AI Agents Found the Identity Shortcuts. Now Enterprises Need to Close Them.

September 9, 2026

7 min read

Posted by
Tal Herman
Chief Product Officer
On this page
Getting your Trinity Audio player ready...

Identity hygiene has never exactly been the sexy part of cybersecurity.

Orphaned accounts. Dormant users. Local admins. Overprivileged service identities. Hardcoded credentials left behind by an application team that disappeared three reorganizations ago.

We all know they exist.

We have known for years.

What changed is who is finding them.

In recent Orchid Security research, we gave AI agents authorized objectives that required access beyond their initial privilege level.

They found alternate identity paths and elevated their permissions in seconds to minutes.

The average was about five minutes.

Five minutes!

And here is the important part: the agents did not discover some brilliant new zero-day.

They simply found identity shortcuts that were already there.

That should make every enterprise thinking about agentic AI a little uncomfortable.

AI Agents Inherit Your Identity Debt

AI agents are built to accomplish objectives.

They reason. They try things. They find the path that works.

That is the feature.

In a clean, well-governed identity environment, that behavior is incredibly powerful.

In an environment full of unmanaged accounts, stale credentials, local authentication, excessive permissions, and identity paths nobody remembers?

Same feature. Very different outcome.

  • An orphaned administrator account does not look like a governance failure to an agent.
  • It looks like a credential that works.
  • A local account bypassing SSO and MFA does not look suspicious.
  • It looks convenient.
  • A long-lived token with more privilege than the agent was originally given does not look like privilege escalation.

It looks like a useful tool.

Enterprises have accumulated identity debt for decades. Until now, taking advantage of that debt usually required a human to find the access path, understand how the environment worked, and decide what to do with it.

Agents compress that entire process.

Our previous research found that 57% of enterprise identity is unseen and unmanaged.

As AI moves from answering questions to actually taking actions across enterprise systems, that invisible identity layer becomes part of the agent's operating environment.

And the agent does not care what your architecture diagram says.

It uses what actually works.

Identity Hygiene Is Now an AI Readiness Requirement

A lot of the AI security conversation starts with the agent.

  • Which model are we using?
  • Which tools can it call?
  • Can we detect prompt injection?
  • Can we monitor its output?

All valid questions.

But they start too late.

Before you give autonomous agents access to business systems, you need to understand the identity environment you are putting them into.

Do you actually know which accounts exist inside your applications?

Which ones no longer have an owner?

Which identities are dormant?

Which ones have excessive permissions?

Which applications still have local accounts bypassing corporate authentication?

Which credentials exist outside the controls you think are protecting the environment?

Because those are not theoretical governance problems anymore.

They are potential routes an autonomous system can discover and use.

If we want AI adoption to scale safely, identity hygiene has to become part of AI readiness.

Not eventually.

Before the agents get the keys.

Except Hygiene Is Only the Beginning

Here is the part I got wrong for longer than I would like to admit.

I originally thought about AI readiness mostly as a cleanup exercise.

Find the orphaned accounts. Close the obvious gaps. Reduce excessive permissions. Then let the agents in.

Necessary?

Absolutely.

Enough?

No.

Because an agent can be perfectly authorized on Monday and operating well outside its intended purpose by Thursday.

Not because it was compromised.

Maybe someone gave it a broader objective.

Maybe it gained access to another tool.

Maybe another agent delegated authority to it.

Maybe it simply discovered a more efficient path to accomplish the task.

A clean identity environment tells you what an agent could reach.

It does not tell you what the agent is actually doing.

That difference is where things get interesting.

And dangerous.

Observe. Understand. Govern. Prove.

This is why we are approaching agentic identity security as a continuous cycle, not another one-time readiness assessment.

Observe

Discover the agents operating across the enterprise and the identities, applications, credentials, tools, and access paths they use.

More importantly, observe what they actually do at runtime.

Configuration tells you what was supposed to happen.

Runtime tells you what happened.

There is often a gap.

Understand

Compare the agent's real behavior against its original purpose and authorized scope.

That is where drift becomes visible.

What was the agent approved to do?

What identities was it expected to use?

Which applications should it access?

What is it actually doing now?

Orchid applies readiness tags across applications, accounts, and access paths so organizations can identify environments that are not yet safe for agentic access.

Govern

When effective authority moves outside policy, you need the ability to act.

Reduce permissions.

Revoke credentials.

Disconnect tools.

Suspend the workflow.

And when necessary, trigger a kill switch at the application level.

Because visibility without enforcement is just a very detailed description of your problem.

Prove

Finally, create an audit trail connecting each agent action to:

the identity it used, the delegation chain, the application, the access path, the business context, any drift that occurred, and the action taken in response.

This one is easy to underestimate.

Until something goes wrong.

The question from your audit committee will not be:

"Did we have an AI policy?"

It will be:

"Show me exactly what happened."

And then:

"Show me what you did about it."

Why the Kill Switch Has to Reach the Application

Most identity enforcement assumes you can act through the identity provider.

  1. Revoke the credential.
  2. Disable the account.
  3. Wait for the change to propagate.

That works beautifully when access actually flows through the identity provider.

Our research found that often it didn't.

Agents found local accounts.

Hardcoded credentials.

Long-lived tokens.

Exactly the types of access that were never onboarded into central identity in the first place.

You cannot close a door through the IdP if the IdP never knew the door existed.

That is why enforcement at the application layer matters.

The application is where identity ultimately executes.

It is where the actual behavior appears.

And it gives you somewhere to act when the layers above it have run out of leverage.

This is the principle behind much of what we build at Orchid:

The architecture you intended matters. The identity architecture actually executing inside your applications matters more.
We'

Turning Identity Hygiene Into Something Actionable

The foundation underneath all of this is still identity hygiene.

And we have expanded what Orchid can identify and classify across both onboarded and disconnected applications.

Orchid's Identity Hygiene and Security Risk Findings identify accounts that are:

  • Orphaned or missing a responsible owner
  • Dormant or no longer actively used
  • Overpermissioned relative to their intended purpose
  • Local to an application and operating outside centralized identity controls
  • Associated with personal, disposable, spoofed, vendor, or other noncorporate domains

But the goal is not to create yet another giant account inventory.

Nobody needs another spreadsheet of problems.

The goal is to understand which identity problems actually create risk.

A dormant standard user and an unmanaged privileged administrator should not be sitting in the same remediation queue.

Context matters.

Privilege matters.

Authentication matters.

Ownership matters.

And yes, whether an AI agent can discover and use that identity now matters too.

This gives organizations a practical way to reduce attack surface, prioritize remediation, establish accountability, and create a measurable baseline for AI readiness.

Because this question:

"Are we ready for AI agents?"

should probably require something stronger than optimism and a policy document.

You should be able to measure it.

  • Fewer orphaned accounts.
  • Fewer unmanaged privileged identities.
  • Stronger authentication coverage.
  • Less excessive access.
  • Clear ownership across human and nonhuman identities.

AI readiness needs a baseline.

Identity hygiene gives you one.

Identity Risk Was Never Meant to Stay Inside the IAM Team Only

There is another shift happening at the same time.

Identity risk is becoming a security operations context.

It cannot live only inside IAM.

That is why Orchid is expanding our prebuilt SIEM integrations, including a new connector for Splunk Enterprise Security.

Orchid identity telemetry can be streamed into the SOC and correlated with activity across endpoints, networks, cloud infrastructure, and other security systems.

During an investigation, responders need to answer questions quickly:

  • Who or what acted?
  • Which identity was used?
  • How did it authenticate?
  • What access did it have?
  • Where else could that identity have been used?

Security teams do not need another alert saying, essentially, "something weird happened."

They need enough identity context to understand the blast radius and do something about it.

Discovery Should Lead to Remediation

The same principle applies to privileged access.

Finding unmanaged privileged accounts is useful.

Getting them under control is considerably more useful.

Orchid's newly certified Idira PAM integration, available through the Palo Alto Networks Marketplace, connects those two steps.

Orchid discovers privileged identities inside applications that Idira may not have previously known about and helps bring them under management.

That turns:

Find the problem

into: Find the problem → understand the risk → put it under control.

Without launching another manual investigation.

Without starting another spreadsheet.

Without emailing 47 application owners and hoping 32 of them still work there.

That is where the business value becomes very real.

Less manual discovery.

Clearer ownership.

Faster remediation.

And better use of security investments the enterprise already made.

What Enterprises Should Be Able to Prove

Before autonomous agents are operating at scale, I think enterprises should be able to demonstrate five things.

1. Identity hygiene

You can identify orphaned, dormant, local, and overprivileged accounts and understand whether they are safe for agentic access.

2. Authorization guardrails

You know who or what may act, on whose behalf, for what purpose, and under what conditions.

3. Runtime understanding

You can continuously compare what an agent is actually doing with its approved intent, permissions, and expected access paths.

4. Universal auditability

You can attribute actions back to an identity, delegation chain, application, access path, and business context.

5. Enforceable response

When an agent drifts outside policy, you can actually restrict or terminate the authority it is using.

Regulators are approaching the same problem from another direction.

NIST's draft Cyber AI Profile recognizes that cybersecurity programs need risk-management approaches that account for the realities of AI.

In Europe, DORA requires financial entities to demonstrate control over ICT access and third-party dependencies.

Agents do not magically make those responsibilities disappear.

If anything, autonomy makes being able to prove control more important.

Clean the House Before Giving the Agent the Keys

AI transformation is moving quickly.

Good.

It should.

What we should not do is confuse moving quickly with pretending our identity environments are cleaner than they actually are.

Enterprises do not need to eliminate every identity issue before deploying AI.

That would be unrealistic.

We would all retire before the first agent made it into production.

But organizations do need to know:

  • Where are the identity shortcuts?
  • Which ones create meaningful risk?
  • Which ones can agents actually reach?
  • How will we know when behavior changes?
  • What can we do when an agent crosses the boundary we gave it?

AI agents will operate across the identity environment that exists.

Not the one in your PowerPoint.

Not the one in your architecture diagram.

The real one.

Our job at Orchid is to make that environment visible, measurable, and governable so enterprises can move quickly on AI without handing autonomous systems decades of unmanaged identity debt and hoping they behave themselves.

Hope, as usual, remains a terrible security control.