Identity Security 4 min read

Blurred Lines: Demystifying the AI Identity Crisis

We are watching the lines blur between Human Intent and Machine Execution.

If you’ve read anything about Non-Human Identities (NHIs) lately, you’d think they were invented yesterday by a GenAI startup.

They’ve become the hottest topic in security because everyone is scrambling to figure out how to secure the explosion of AI Agents flooding the enterprise. NHIs are nothing new. Service Accounts, API Keys, Managed Identities, and Cron Jobs have been running the world for decades.

So why the sudden panic?

The difference isn't the Identity. The difference is the Agency.

Traditional NHIs were static. They did exactly what a script told them to do, nothing more, nothing less. If a Service Account deleted a database, it was because a human wrote a bad script (or a bad actor stole the key).

AI Agents are different. They reason. They plan. They execute tools. They operate at a speed and scale that breaks our traditional mental models of Identity Governance.

We are watching the lines blur between Human Intent and Machine Execution.

The Identity Onion

To understand the risk, we have to look at the execution stack. It is no longer just "User accesses Data." It is a nesting doll of identities, an "Identity Onion", where each layer introduces its own permissions and risks.

Layer 1: The Execution Context (User vs. Machine)

This is the outer shell. Where does the Agent live?

  • User Context: When I use a Coding Assistant (Claude Code, Cursor, Windsurf, etc.) or a Coworker (Microsoft 365 Copilot), the Agent runs as Me. It inherits my Kerberos ticket, my Entra ID token, and my file system permissions. The risk here is destructive action. If I ask an Agent to "clean up old files" and it hallucinates a wildcard, it deletes those files with my credentials. The logs say I did it.
  • Machine Context: Autonomous Agents often run on servers or headless VMs. Here, they run as SYSTEM or a specific Managed Identity. They inherit the permissions of the Device itself. If that server has an open network path to a critical database, the Agent effectively shares that path.

Layer 2: The Body and The Brain

Inside that context, the AI Agent splits into two distinct identity components that we often conflate.

  • The Body (The Agent): This is the application code or container. It behaves like a traditional Workload Identity. It needs OAuth tokens or Service Principals to access the environment.
  • The Brain (The Model): This is the LLM (ChatGPT, Claude, Gemini, etc.). The Body needs a separate set of API Keys just to talk to the Brain.

Then you have The Hands (Tools). If the Agent needs to check a Jira ticket or query Salesforce, it needs specific API keys or Federated Credentials for those tools.

Suddenly, one "AI Agent" isn't one identity. It is a cluster of five or six different credentials (Context Token, Model Key, Tool Keys, etc.) all strapped together.

Layer 3: The "Agent Identity" (The New Wrapper)

As of 2025, vendors like Microsoft and Google are trying to wrap this complexity into new "Agent Identities" (like Entra Agent ID). While this is a step forward, we have to recognize it for what it is: a specialized form of Workload Identity. It doesn't solve the complexity; it just gives the onion a name tag.

The Missing Link: End-to-End Correlation

The reason we are struggling to secure this is that our current tools only see slices of the onion.

  • 🛡️
    EDR Sees the Device and the Process.
  • 🔑
    IdP Sees the Human or Service Principal.
  • 🌐
    CASB/Proxy Sees the traffic to the Model.

Nobody sees the full chain.

We are missing the correlation between The Human (who prompted it) -> The Device (where it ran) -> The Agent (the workload) -> The Model (the brain) -> and The Data (the target).

If you cannot graph that line from end-to-end, you cannot govern it. You are seeing the traffic, but missing the intent.

The Path Forward

We founded GraphnAI exactly one month ago today because we saw this gap widening.

You cannot secure AI Agents with static lists. You can only secure them with a Graph. You need to map the Tiered Fidelity™ of these relationships. We need to understand that a "Theoretical" path from an Agent to a Database becomes a "Validated" risk the moment that Agent is given a tool to execute SQL queries.

As we move toward a world where NHIs outnumber humans 100-to-1, the question isn't just "Who logged in?"

The question is: "What is the full context of the entity that just took that action?"

That's the problem we're obsessed with solving. Context that creates the confidence to adopt safe automated remediation.