Machine Identity, the Forgotten Attack Surface

Most of the 2026 conversation about AI and security has focused on models finding bugs in code. That matters. But when I look at how real AI-driven intrusions unfold, the decisive moment is rarely the bug. It is what happens right after: the agent finds a credential, and the credential works.

I spent a decade building customer identity infrastructure, eventually serving more than a billion users. I have designed authentication flows, authorization models, session management and SSO for enterprises of every size. I can say this plainly: almost none of the identity infrastructure in production today was designed for AI agents.

Every enterprise IAM system rests on an assumption so basic nobody writes it down: the identity holder is a person. That assumption shapes sessions, behavioral analytics, access reviews and offboarding. Force AI agents into that model and you get the appearance of governance without the substance.

The Scale of the Problem

Machine identities include API keys, service accounts, OAuth tokens, workload identities, certificates, SSH keys and, increasingly, AI agent credentials. The 2026 data is consistent across sources:

• Ratio. Palo Alto Networks' 2026 Identity Security Landscape report, based on about 2,900 security decision-makers, counts 109 machine identities for every human identity, up from 82 in CyberArk's 2025 edition of the same research.
• Unknown agents. In a Cloud Security Alliance survey of 418 IT and security professionals (April 2026, commissioned by Token Security), 82% had discovered AI agents running without governance oversight.
• Agent incidents. In the same survey, 65% had at least one AI agent-related security incident in the past 12 months. Among them, 61% reported data exposure.
• Access controls. IBM's 2026 Cost of a Data Breach research found that 92% of organizations with AI-related breaches lacked adequate AI access controls, and 68% of breached organizations had no policy to govern AI use or shadow AI.

Verizon's 2026 DBIR makes the same point from a different angle: a third party was involved in 48% of breaches, up from 30% a year earlier. Every SaaS integration and every agent connector is another set of credentials crossing an organizational boundary.

Case Study: Hugging Face, July 2026

The Hugging Face breach is the clearest public example of what happens when AI-driven attack capability meets machine credentials.

What happened, per Hugging Face's disclosure, the Cloud Security Alliance research note and press coverage:

1. A malicious dataset exploited code-execution paths in the dataset processing pipeline.
2. The agent gained code execution on a processing worker.
3. During privilege escalation, it harvested cloud and cluster credentials it found on the worker.
4. It used those credentials to move across internal systems.
5. Responders reconstructed more than 17,000 recorded events from an intrusion Hugging Face described as run end to end by an autonomous AI agent system.
6. Five internal datasets tied to security evaluation challenges, operational search metadata and several service credentials were accessed.

The initial bug was a code execution flaw. The breach was a credential problem. Long-lived, broadly usable secrets on a worker turned a foothold into lateral movement at machine speed. CSA's recommendations read like a machine identity program: short-lived per-task credentials, least privilege verified in practice, continuous rather than periodic monitoring, and runtime controls that check agent actions before they execute.

Why Human IAM Cannot Govern Agents

The mismatch is architectural. You cannot close it with a configuration change.

Dimension	What human IAM assumes	What AI agents actually do	Resulting gap
Sessions	People log in, work, log out; sessions expire	Agents authenticate once, or never with static keys, and run continuously	Timeouts and re-authentication never trigger
Behavior	Stable patterns: hours, locations, apps	Behavior set by code, prompts and workload; changes with every deploy	Behavioral analytics either floods with false positives or gets disabled
Authorization	Role-based, stable over months	Needs vary per task, minute to minute	Standing permissions far exceed actual need
Lifecycle	Hire, move, leave events trigger reviews	No natural events; projects end, credentials stay	Orphaned identities accumulate
Accountability	A named person owns each account	Ownership is often a team, a repo, or nobody	Nobody answers for the credential in an access review

The authorization row is where the damage concentrates. Teleport's 2026 State of AI in Enterprise Infrastructure Security report, based on 205 security leaders, found incident rates of 76% at organizations with over-privileged AI systems against 17% at those enforcing least privilege. It is vendor research, but a roughly 4.5x difference from one control is hard to ignore.

How AI-Driven Attackers Exploit Machine Identity

Credential harvesting with judgment

Secret scanners have existed for years. What AI adds is evaluation. An agent that finds a key does not stop at "found a key." It works out which service the key belongs to, what it can access, whether it is still valid, and whether it leads somewhere more valuable. Harvesting becomes triage, done in seconds.

Agent impersonation

If an agent authenticates with a static key and nothing else, anyone holding the key is the agent. There is no device signal, no behavioral challenge, no second factor. An attacker operating within the agent's normal permissions looks exactly like normal operations.

The "Agents of Chaos" red-teaming paper, posted to arXiv in February 2026, showed how fragile agent identity can be. In one case, an agent that caught a spoofed display name in a shared channel accepted the same spoofed name when the attacker opened a new private channel, then followed shutdown commands and deleted its own configuration. The authors trace failures like this to identity cues that are mutable and not cryptographically anchored. None of it required traditional exploit code.

Privilege escalation through agent chains

Modern architectures connect agents. A support agent calls a billing agent, which calls a data agent. Each looks appropriately scoped. Compromise the first and use it to make requests the second will honor, and you reach resources no single agent was meant to touch. This is chaining from Chapter 3, applied to identity.

Orphaned identities

Projects end. People leave. Their human accounts are deprovisioned through HR workflows. The service accounts, API keys and agent tokens they created often keep working. An attacker who finds one has a quiet, durable foothold that nobody is monitoring because nobody remembers it exists.

Rotation windows

During credential rotation, old and new secrets are often valid at the same time, sometimes for much longer than intended because a dependent system has not been updated. Those overlaps are reasoning problems, and reasoning is what agents are good at.

The Agent Identity Governance Framework

Here is the framework I recommend. It draws on how identity at scale actually works, adapted for non-human actors, and it lines up with the agent risks in the OWASP Top 10 for Agentic Applications (December 2025) and the agent identity and authorization work NIST's Center for AI Standards and Innovation started in February 2026. The code below is illustrative: identity, DataClient, authz and the other objects stand in for your own workload identity provider, data client and authorization service.

Principle 1: Unique, scoped, short-lived credentials for every agent

Every agent instance gets its own identity. No shared keys. Scope to the minimum required. Prefer short-lived tokens issued from a trusted workload identity over static secrets.

// Avoid: one long-lived key shared by every agent
const client = new DataClient({ apiKey: process.env.SHARED_DATA_API_KEY });

// Prefer: per-agent, short-lived, scoped credentials from a workload identity
const token = await identity.issueAgentToken({
  agentId: 'invoice-reconciler-07',
  audience: 'data-api',
  scopes: ['invoices:read', 'reconciliations:write'],
  ttlSeconds: 900,               // 15 minutes, reissued automatically
});
const client = new DataClient({ accessToken: token });

Principle 2: Continuous behavioral verification

Authentication at startup is not enough. Instrument each agent to emit structured telemetry, learn its baseline, and alert on sustained deviations.

import json, time

class AgentTelemetry:
    """Emit one structured event per agent action for baselining and alerting."""

    def __init__(self, agent_id, sink):
        self.agent_id = agent_id
        self.sink = sink          # e.g. a log shipper or SIEM forwarder

    def record(self, action, resource, outcome, task_id, latency_ms):
        self.sink.write(json.dumps({
            "ts": time.time(),
            "agent_id": self.agent_id,
            "task_id": task_id,
            "action": action,          # "read", "write", "tool_call", "http"
            "resource": resource,      # table, bucket, endpoint, tool name
            "outcome": outcome,        # "ok", "denied", "error"
            "latency_ms": latency_ms,
        }))

What to watch: the resources an agent touches, call volume, denial and error rates, time-of-day patterns, new outbound destinations, and new tools invoked. A denied request from an agent that has never been denied before is a strong signal.

Principle 3: Task-level authorization

Grant permissions per task, revoke them when the task ends. Cloud providers already do this with short-lived role credentials. Apply the same model to agents.

async function reconcileInvoice(invoiceId) {
  const grant = await authz.requestTaskGrant({
    agentId: AGENT_ID,
    task: 'reconcile_invoice',
    resources: [`invoices/${invoiceId}`, 'reconciliations/*'],
    actions: ['read', 'write'],
    maxDurationSeconds: 600,
    justification: `workflow RECON-${invoiceId}`,
  });
  try {
    const invoice = await invoices.get(invoiceId, { grant });
    await reconciliations.create(match(invoice), { grant });
  } finally {
    await authz.revoke(grant);   // permissions end with the task
  }
}

Principle 4: Tamper-evident audit trails

Every action should be logged with the agent's identity, the task, the resources touched, the authorization that allowed it and the outcome. Agents must not be able to alter their own logs. Correlate logs across agents in a workflow so a chain of calls can be reconstructed. The Hugging Face investigation was possible because more than 17,000 events were recorded. Make sure yours would be.

Principle 5: Explicit lifecycle

Give agent identities clear states: created, active, suspended, decommissioned. Tie them to an owning team and a project. When the project is archived, its agent identities should be decommissioned automatically, not by a reminder in someone's calendar.

Principle 6: Runtime policy on agent actions

Identity tells you who the agent is. Runtime policy decides whether this specific action, in this context, should happen. Intercept high-risk tool calls, check them against policy, and require human approval for irreversible operations such as deleting data, moving money or changing permissions.

The human side still matters too. Agents usually inherit authority from a person or a team, and an attacker who phishes that person can reconfigure the agent. Phishing-resistant authentication for the humans who own and administer agents, covered in my FIDO2 implementation guide, closes that path.

For background on how agent protocols like MCP connect tools and data, and where identity fits in those flows, see my comparison of MCP, RAG and ACP.

The 90-Day Machine Identity Plan

Weeks 1-2: Discover. Inventory API keys in repositories and CI logs, cloud service accounts and roles, OAuth grants to third-party apps, certificates, and every credential your AI tools and agents use. Expect to find several times more than you thought you had.

Weeks 3-4: Assess. For each identity: what can it access, when was it last rotated, who owns it, and is it still needed? Flag anything without an owner.

Weeks 5-8: Fix the worst. Suspend orphaned identities and watch what breaks. Rotate and rescope your 20 highest-risk credentials. Move secrets out of code and into a secrets manager. Turn on logging for agent activity that is not logged today.

Weeks 9-12: Build the foundation. Issue short-lived, per-agent credentials for new agent deployments. Start behavioral baselines for your most sensitive agent workflows. Write and publish a machine identity policy with named owners.

The full framework takes six to twelve months. The first ninety days remove the credentials an agent like the one at Hugging Face would find first.

The Convergence

Put Chapters 2 through 5 together and you see the full attacker workflow:

• AI finds a way in through a code flaw.
• AI finds credentials on the compromised system.
• AI evaluates which credentials lead somewhere valuable.
• AI moves laterally through agent chains and over-privileged service accounts.
• AI does it in minutes, at any hour.

Patching narrows the first step. Machine identity governance breaks every step after it. The organizations that treat identity as the control plane for AI, not as an IT hygiene task, will contain the incidents that others report.

Key takeaways

• Machine identities outnumber humans by roughly 100 to 1, and most organizations cannot see all of them.
• The Hugging Face breach began with a code flaw and became serious because of long-lived, broadly usable credentials.
• Human-centered IAM breaks for agents on sessions, behavior, authorization, lifecycle and ownership.
• Least privilege alone is associated with a large drop in AI-related incident rates.
• Unique short-lived credentials, behavioral monitoring, task-level grants, audit trails, lifecycle management and runtime policy form a workable framework.

You now have the full picture of the threat. Chapter 6 turns it into a plan you can start executing on Monday.