When AI Hackers Meet Machine Identity: The Ignored Attack Surface

In August 2025, a group tracked as UNC6395 stole OAuth tokens from Salesloft's Drift AI chatbot and used them to walk into more than 700 Salesforce environments, including Cloudflare, Google, Palo Alto Networks, and Zscaler. No password was cracked. No MFA prompt was answered. The attackers held a valid machine credential, so every system they touched treated them as trusted software doing its job. They ran automated queries, exported data in bulk, and combed the results for AWS keys and Snowflake tokens to fuel the next round.

That breach is the shape of the next decade. The industry keeps talking about AI finding bugs in code. The bigger problem is quieter: AI agents run on machine credentials that were never designed to be defended, and AI-powered attackers are learning to harvest them at machine speed.

I spent a decade building identity infrastructure. I founded a CIAM platform that scaled to over a billion users, built authentication and authorization systems, and defended identity infrastructure against real attacks. I can tell you plainly: none of it was designed for AI agents.

Every enterprise IAM system in production today assumes the identity holder is a human being. That single assumption shaped everything, from session timeouts to behavioral analytics to access reviews. Force AI agents into that human-shaped mold and you do not get security. You get the illusion of it.

The scale of the problem

Machine identities already dwarf human ones. CyberArk's 2025 Identity Security Landscape study found machine identities outnumber humans by more than 80 to 1. In cloud-native and DevOps environments the gap is wider still: Entro Security put the ratio at 144 to 1 in the first half of 2025, up from 92 to 1 a year earlier. Across the board, the population of non-human identities grew 44 percent in a single year.

Now layer AI agents on top. Every copilot integration, every automated pipeline, every agent that calls a language model spawns new machine identities. Each one authenticates to APIs, reads databases, and calls external services. Each one needs credentials. Each credential is an attack surface, and most of them look like this:

• Static API keys scattered across repos, CI/CD pipelines, container images, and config files
• Service accounts with broad permissions granted at deployment and never narrowed
• Shared credentials reused across agents because minting unique ones felt like too much overhead
• No rotation, because the agents break when keys change and nobody wants to debug it
• No behavioral baseline, because nobody instrumented the agents to emit telemetry

The secrets are leaking, too. GitGuardian counted roughly 29 million new secrets pushed to public GitHub in 2025, a 34 percent jump year over year and the largest single-year rise it has recorded. Leaks tied specifically to AI services climbed 81 percent. And the cleanup never happens: 64 percent of the valid secrets exposed back in 2022 were still live and unrevoked in 2026.

Why human IAM cannot protect AI agents

This is not a feature gap you can patch. It is an architectural mismatch across four dimensions.

Sessions. A human logs in, works, and logs out. Sessions expire in hours, and a login from a new country triggers step-up auth. An agent authenticates once, or never in the case of a static key, and runs around the clock. There is no session to time out, no idle state to detect. An attacker holding an agent credential can use it indefinitely and trip none of these controls.

Behavioral analytics. UEBA learns human rhythms: consistent hours, consistent resources, consistent volume. Agent behavior is set by code, not habit. It might fire 10,000 API calls in one hour and zero the next, and change entirely when its prompt or workload changes. Tuned for humans, UEBA either buries teams in false positives or gets switched off for machine accounts, which creates a blind spot exactly where the volume lives.

Authorization. RBAC assigns humans to stable roles. An agent's real need is per task: a document processor needs read on the source and write on the output only while it runs, and nothing in between. RBAC grants both permissions permanently, so an idle or compromised agent carries a far larger blast radius than the work requires.

Lifecycle. Human credentials have natural events, hire, role change, departure, that force review. Machine keys have none. They are generated once and used until something breaks. Access reviews skip them because nobody remembers what half of them do, and decommissioned projects leave orphaned accounts running with their original permissions. Without explicit automation, they simply never die.

The principles I covered in my FIDO2 implementation guide make passwordless auth strong for humans. Machines need an entirely different application of the same thinking.

How AI-powered attackers exploit it

The machine identity gap turns dangerous the moment you pair it with automation and AI reasoning. Four patterns matter most.

Credential harvesting at machine speed. Bots already watch GitHub's public event stream in real time. GitGuardian's honeypot data shows the median time from a secret hitting a public repo to its first use by an attacker is under 60 seconds. Scanners like TruffleHog and GitLeaks find the keys; AI adds the reasoning layer on top, deciding what a key unlocks, whether it still works, and which one is worth chasing first. The window to notice and rotate is effectively gone.

Agent impersonation. An agent authenticating with a static key and no behavioral check can be impersonated perfectly. There is no device fingerprint, no biometric, no pattern to tell the real agent from the imposter. The security stack sees a valid credential making authorized requests, which is exactly what the Salesloft Drift attackers relied on.

Privilege escalation through agent chains. Agent A calls Agent B calls Agent C, each with its own credentials. Compromise A and you can often drive B, reaching resources no single agent was authorized to touch. It is vulnerability chaining, moved into the identity layer.

Orphaned agent exploitation. When a project dies, the humans get offboarded but the service accounts and API keys often live on with full permissions. An attacker scanning for these abandoned identities finds ready-made, unmonitored backdoors.

A governance framework built for agents

Defending this surface takes purpose-built governance. Based on a decade of building identity systems at scale, five principles carry most of the weight.

1. Unique, scoped, rotatable credentials for every agent. Each agent instance gets its own credential set, scoped to the minimum it needs, with a short time-to-live and automatic rotation. Shared keys between agents are never acceptable. Rotation has to be built into the agent framework itself, not into a runbook nobody follows, or it will not happen.

2. Continuous behavioral authentication. Authentication cannot be a one-time gate. Instrument agents to emit telemetry on API call patterns, resource access, timing, errors, and network behavior. Build a per-agent baseline during a learning period, set thresholds that tolerate legitimate variation like deployments and workload spikes, and alert on sustained deviation rather than single blips.

3. Task-level authorization. Grant permissions per task, not per session, and revoke them automatically when the task finishes. This is how AWS STS already issues short-lived, scoped credentials. Apply the same discipline to agents so an idle agent holds no standing access.

4. Immutable audit trail. Log every agent action with full context: identity, task, resources, authorization basis, outcome. Make it tamper-proof so agents cannot edit their own records, available in real time, and correlated across every agent in a workflow chain.

5. Lifecycle management. Give agent identities explicit states, created, active, suspended, decommissioned, and audit every transition. The rule that matters most: decommissioning a project must automatically kill all of its agent identities. If that takes manual steps, orphans will pile up.

If you are designing agent communication, the MCP, RAG, and ACP protocol landscape is essential context for where these credentials flow.

What to do this quarter

The full program takes 6 to 12 months. The first 90 days close the most dangerous gaps.

Weeks 1 to 2, discovery. Inventory every machine identity: API keys, service accounts, certificates, agent credentials. Use automated discovery. You will find ones nobody knew existed.

Weeks 3 to 4, risk assessment. For each, document what it can access, when it was last rotated, who owns it, and whether it is still needed. Flag orphans for immediate deactivation.

Weeks 5 to 8, quick wins. Turn on automated rotation for your 20 highest-risk credentials. Kill the orphans. Enable logging on any agent API calls that are currently dark.

Weeks 9 to 12, foundation. Deploy per-agent behavioral monitoring on your most critical workflows, require task-level authorization for new agent deployments, and write down a machine identity governance policy.

For the cryptographic side of credential protection, my password hashing guide and these hashing tools give your team the technical depth.

The takeaway

Machine identity governance is not a cost center. It is what lets you deploy AI agents at scale instead of cleaning up after them. The teams that invested in identity security early always moved faster, because they never had to stop and remediate after every incident.

The attackers have already done the math. Stolen credentials showed up in 32 percent of all breaches in Verizon's 2025 report, and in 88 percent of attacks against web applications. They picked machine identity because it is the softest, fastest, least-watched way in. The defenders who win this decade are the ones who stop treating agents like humans and give every machine its own scoped, rotating, monitored, disposable identity.

For where these capabilities are heading next, see my analysis of AI's trajectory.

Frequently asked questions

What is machine identity?

Machine identity is the credentials and authentication used by non-human entities: API keys, service accounts, certificates, tokens, and AI agent credentials. CyberArk's 2025 study found these outnumber human identities by more than 80 to 1, and the ratio exceeds 140 to 1 in cloud-native environments.

Why can't traditional IAM protect AI agents?

Traditional IAM assumes humans with finite sessions, consistent behavior, and natural lifecycle events. AI agents run continuously, behave according to code rather than habit, and have no built-in triggers for credential review or rotation.

What is the biggest machine identity risk?

Static API keys with broad permissions that are never rotated. They provide persistent, high-privilege access, and because there is no behavioral baseline, a compromise is very hard to detect. GitGuardian found 64 percent of secrets exposed in 2022 were still unrevoked in 2026.

What is task-level authorization for AI agents?

It grants an agent permissions only for the duration of a specific task, then revokes them automatically. This enforces least privilege by eliminating standing access that widens the blast radius.

How do AI-powered attackers exploit machine identity?

They scan for exposed credentials at scale (first use of a leaked secret is often under 60 seconds), impersonate agents with stolen static keys as in the 2025 Salesloft Drift breach, escalate through agent chains, and exploit orphaned credentials from dead projects.

What should organizations do first?

Inventory every machine identity, including ones you do not know exist. Then assess risk, deactivate orphans, and turn on automated rotation for your highest-risk credentials.