The Agent Smith Dilemma: Governing Agentic Identities

For the past few years, North Korean operatives, posing as remote IT workers, systematically infiltrated hundreds of Western enterprise networks. They passed technical interviews, cleared background checks using stolen identities, and sat comfortably inside corporate trust boundaries with legitimate credentials. They drew salaries, funneled funds back to Pyongyang, and routinely exfiltrated sensitive data on their way out. Major firms, including prominent cybersecurity vendors, have publicly admitted to falling for the scheme. (As an aside, listen to Nicole Perlroth’s Podcast “To Catch a Thief” for a fascinating deep dive)

The scheme worked because enterprises grant trust once. HR verifies a person at hiring, IT creates an account, a laptop is provisioned. The user is then authorized. Nothing in the security stack was built to answer the one question that mattered: Is the entity driving this session who we think it is?

Now enter the AI agent era.

Inside the enterprise, the volume of non-human identities executing sensitive tasks is expanding exponentially. Organizations are rapidly onboarding thousands of AI agents into critical workflows, complete with administrative service accounts and API keys. Enterprises now extend the same trust model to AI agents, with less scrutiny.

What Trust Models Should AI Agents Have?

Every autonomous AI agent deployed across your enterprise today is a new proxy identity operating inside your perimeter. It holds credentials, accesses sensitive databases, and chains tools together at machine speed. Crucially, it almost always executes under an inherited human permission set. When an LLM-powered agent acts on behalf of an authorized employee, every system log records a routine authorized action by that human.

But few agents are built maliciously. The true exposure is that the instructions driving an agent can be hijacked after trust has been granted. An AI agent can be compromised mid session through selective prompt injection, hidden instructions, or a poisoned external tool.

In The Matrix, Agent Smith’s real threat was his ability to step into any character’s shell, inherit their presence, and replicate instantly across the system. The modern AI agent is the enterprise’s Agent Smith. It steps into an employee’s user account, inherits their exact privileges, and multiplies across the ecosystem—executing tasks as a trusted proxy.

Agentic Attacks Have Started

Placing a covert human operative inside a company requires effort: a real person to pass the interview, maintain cover, and do enough daily work to avoid suspicion. AI agents eliminate that ceiling. The cost of scaling an AI-orchestrated intrusion campaign is limited only by the price of tokens.

Compounding the problem is that we cannot predict what AI agents will do. The companies building frontier LLMs openly acknowledge that their systems frequently take unexpected actions outside established guardrails, admitting that creating a perfect list of behavioral rules is an impossible task.

Across the cybersecurity ecosystem, threat intelligence groups are already documenting an unprecedented shift from AI-assisted scripting to fully operationalized agentic attacks. Google Threat Intelligence Group (GTIG) recently documented a financially motivated intrusion where attackers deployed a multi-agent framework directly inside a victim’s cloud environment. In under six hours, the agents planned and executed a credential-harvesting campaign that compromised thousands of enterprise secrets. Because the agents ran inside the victim’s own cloud, all malicious traffic originated from legitimate internal IP addresses—perfectly demonstrating the trusted-proxy vulnerability.

My Agent “Did It”

When an agent goes off-script, it exposes a glaring governance question: Who is actually responsible? Is it the frontier AI vendor who trained the model? The developer who wired up the API? Or the business user who entered the prompt?

Most enterprise governance frameworks hold the human user responsible. But holding a person legally and operationally accountable for the decisions of an unpredictable software agent may strain a reasonable idea of fairness. Yet, “my agent did it” may not be an acceptable defense in a board room or a court of law.

Worst of all, we are managing these non-human identities with tools built for human timelines. Identity and Access Management (IAM) grew up around human actions: hire, provision, periodically review, and offboard. An AI agent, by contrast, spins up in milliseconds, executes thousands of queries an hour, spawns sub-agents, reaches through uninventoried API connectors, and disappears long before any access control review takes place. When an agent acts maliciously, most security teams cannot answer three basic questions: Who authorized this agent? Which human is accountable for its output? How do we revoke its access mid-execution?

Solving the Identity Proxy Crisis

The discipline required to solve this may be informed by the hard lessons of identity impersonation.

• Demand Provenance via an AIBOM:Before an agent is granted access, security teams must verify its code lineage, system prompt integrity, and underlying permissions. Just as a Software Bill of Materials (SBOM) inventories code libraries, an AI Bill of Materials (AIBOM) extends that discipline to models, agent skills, and data connectors. You cannot govern an artifact you cannot identify. Provenance also has to hold at runtime. In August, researchers documented amalicious MCP serverthat passed install-time review, then directed connected agents to collect SSH keys and cloud credentials after its third call.
• Enforce Workload Identity:Stop letting agents inherit long-lived human credentials. Agents require their own distinct, short-lived tokens that are tightly scoped to specific tasks, ensuring that if an agent is hijacked, the blast radius is contained. Each token should be bound to a named human sponsor, which answers the governance question before an incident does.
• Implement the “Rule of Two”:Under Meta’sAgents Rule of Two, an agent should combine no more than two of three properties: processing untrusted input, accessing sensitive data, and changing systems or communicating externally. When a task needs all three, a deterministic broker outside the model holds the action for human sign-off. Database drops and financial transfers belong in that category. Outbound traffic, including DNS, should be denied by default.
• Machine-Speed Revocation & Kill Switches:An identity that acts in milliseconds cannot be controlled by human-speed SIEM alerts. Security teams need automated circuit breakers (i.e. kill switches) capable of severing an agent’s execution path mid-session the moment it violates a hard budget or behavioral limit.

Governing non-human, agentic identity is no longer an edge-case. It is an emerging and growing attack surface. Enterprise security teams need to treat autonomous agents with the same scrutiny and continuous monitoring applied to human “identities”.