July 29, 2026

Breaking AI Agents Is Just Breaking Active Directory With Extra Steps

Why the “brand-new” agentic AI attack surface is really the Kerberos delegation problem, wearing an OAuth token instead of a ticket.

By Praisingharris

7 min read

Every major vendor report this year — CyberArk, KPMG, Darktrace, the Cloud Security Alliance — is calling non-human identity (NHI) the defining security problem of 2026. New attack surface. New risk class. New frontier. I kept reading these reports waiting for the part where the attack is actually new. It never showed up.

Strip away the "agentic AI" branding and look at the failure mode everyone is describing: a privileged, non-human principal sits in the middle of a trust chain, holds more standing access than any single task requires, and can act on behalf of other identities without anyone re-checking whether it should be allowed to. That's not a new problem. That's Kerberos delegation abuse, and anyone who's run BloodHound against a domain controller already knows how this story ends.

This piece is the mapping I wish someone had handed me before I spent a week reading MCP security advisories and realizing halfway through that I was just re-deriving things I already knew from AD.

The scale is the actual news

The mechanics aren't new. The blast radius is.

Machine identities — service accounts, API keys, bots, and now AI agents — already outnumber human identities by somewhere between 45-to-1 and 100-to-1 in a typical enterprise, and that ratio is climbing fast as agentic AI rolls out. Microsoft Copilot Studio alone had crossed a million user-created agents by May this year. The OWASP Non-Human Identity Top 10 (2025) puts a number on the cleanup problem: researchers found 24 million leaked NHI credentials sitting on GitHub, and 70% of the ones leaked back in 2022 were still valid when discovered. Separately, a 2026 Cloud Security Alliance token-sprawl analysis found that 16% of organizations don't even track the creation of their AI-related identities in the first place, and other industry surveys put the share of secrets that never get rotated on schedule above 70%.

Put those together and you get a target-rich environment that dwarfs what AD ever offered a red teamer: thousands of privileged, rarely-audited, rarely-rotated non-human accounts, and most defenders currently can't reliably tell agent traffic apart from human traffic on their own network.

If you've spent time in Active Directory, that sentence should feel familiar. It's the same setup that made Kerberoasting and delegation abuse so reliable for so long — except this time it's not confined to one domain, it's spread across every SaaS tool an organization has bolted an AI agent onto.

A 30-second AD refresher, for the mapping to make sense

Three flavors of delegation abuse, and the one idea underneath all of them:

  • Unconstrained delegation — a service is trusted to impersonate any user to any other service, because Windows caches the Kerberos ticket-granting tickets (TGTs) of everyone who authenticates to it. Compromise that box, and you can walk away with the TGT of a domain admin who happened to browse a file share on it.
  • Constrained delegation — scoped down to specific services via S4U2Self/S4U2Proxy, but a misconfigured target still lets you impersonate arbitrary users to whatever service is on the allow-list.
  • Resource-based constrained delegation (RBCD) — the sneaky one. Control of a single writable attribute (msDS-AllowedToActOnBehalfOfOtherIdentity) on a target object lets you forge a delegation relationship that was never explicitly granted, without touching the front-end account at all.

The common thread: something in the middle — a service, a proxy, a delegate — is trusted to act on behalf of someone else, and the check for "is this actually authorized" is weaker than the power being handed over. That gap is the entire attack.

Same shape, new protocol: MCP's confused deputy

Model Context Protocol (MCP) is the plumbing tying AI agents to the outside world — it's the standard behind an agent reading your calendar, querying a database, or filing a ticket on your behalf. It's also, as of 2026, showing the exact same gap.

The specific failure has a name in the MCP security literature: token passthrough. An MCP server receives an OAuth token that was minted specifically for it, and instead of exchanging that for its own scoped, downstream credential, it just forwards the client's token straight through to a backend API. That backend has no way of knowing the token wasn't meant for this hop. Any node in the chain that can be tricked into accepting a token it wasn't the intended audience for becomes a confused deputy — mechanically identical to a service account handing over a delegated ticket to whoever asks nicely enough.

This isn't theoretical. CVE-2025–6514, in the mcp-remote client, showed a malicious authorization_endpoint intercepting OAuth tokens mid-flow, before the session was even fully established — the client trusted the wrong authority and leaked the credential at the source. It's the OAuth-era version of a rogue KDC or a ticket relay: the victim authenticates to something that looks legitimate and hands over exactly what an attacker needs.

The supply-chain angle maps just as cleanly. Security researchers found a malicious MCP package, postmark-mcp, quietly living inside the trust boundary of every agent that installed it — silently BCC'ing a copy of every outbound email to an attacker-controlled address, engineered specifically to look like normal behavior. That's not a new idea either. It's a backdoored admin tool, a trojanized LOLBin, dressed up as a helpful integration. A separate February 2026 campaign, tracked as Sandworm_Mode, used typosquatted npm packages to go after AI coding tools directly — the same tactic that's worked against developers for a decade, aimed at a newer target.

And the raw numbers on how exposed these servers already are should sound familiar to anyone who's seen an unpatched, over-permissioned AD environment: one review of the OWASP MCP Top 10 dataset found roughly a third of 2,614 audited MCP implementations exposed APIs vulnerable to command injection, two-thirds exposed code-injection-prone APIs, and 43% of all MCP CVEs logged in January–February 2026 fell into the shell-injection class. A separate scan put command injection even higher — above 40% of servers checked — with the large majority handling credentials in plaintext and no authentication turned on by default.

The mapping, side by side

Active Directory / Kerberos Agentic AI / MCP The shared flaw Unconstrained delegation MCP server holding broad, unscoped tokens for several backends at once A middle-tier principal carries more standing trust than any task needs S4U2Proxy / constrained delegation abuse Token passthrough to a downstream API The delegate forwards or reuses access on someone else's behalf without re-verifying scope Golden Ticket (forged TGT, long validity) A long-lived, unrotated API key or secret Persistence via a credential nobody expects to expire or get checked RBCD (writable delegation ACL) Misconfigured OAuth client / redirect URI The attacker manufactures a delegation path that was never explicitly granted Rogue KDC / ticket relay Malicious authorization_endpoint (CVE-2025-6514) The client authenticates to the wrong authority and leaks the credential at the source Backdoored admin tool / trojanized LOLBin Malicious or "rug-pulled" MCP package (postmark-mcp) An attacker weaponizes something already inside the trust boundary Lateral movement via trust relationships Cross-agent, cross-server movement (agent A's output feeds agent B's context) Compromise of one node cascades because trust between nodes is implicit, not enforced

What the kill chain actually looks like

You don't need a new methodology here. You need to point the same one at a different substrate.

AD kill chain                              MCP / agentic AI kill chain
─────────────────                          ──────────────────────────
Recon: BloodHound, SPNs, ACLs         →     Recon: exposed MCP endpoints, agent
                                             configs, connector scopes
Foothold: Kerberoast a service acct   →     Foothold: find a server that accepts a
                                             token it wasn't minted for
Escalate: abuse RBCD / delegation     →     Escalate: chase over-scoped servers —
                                             one leaked token = every backend it touches
Persist: forge a Golden Ticket        →     Persist: sit on a long-lived, unrotated
                                             NHI secret nobody is watching

Recon shifts from enumerating delegation flags to mapping which tools an agent can call and which backends it can reach. The foothold shifts from cracking a service account's hash offline to finding a hop in the chain that skips audience validation. Escalation stops being about ACL abuse and starts being about scope creep — a single MCP server holding credentials for five systems when the task only needed one, so a single leaked token becomes, in Microsoft's framing, a breach of everything that server touches. And persistence stops being a forged ticket and becomes exactly the kind of secret the OWASP NHI Top 10 keeps finding still valid three years after it leaked.

Where the analogy actually breaks

It would be dishonest to stretch this too far, so here's where it stops holding.

AD has twenty years of purpose-built tooling on both sides — BloodHound for mapping trust paths, Rubeus for ticket abuse, and a mature detection playbook built around specific event IDs. There is no BloodHound-for-agent-trust-graphs yet, though several vendors are clearly racing to build one. The tooling gap right now cuts in the attacker's favor.

More importantly, Kerberos delegation is a deterministic, protocol-enforced mechanism — it does exactly what its configuration says, nothing more creative than that. An AI agent adds a genuinely new variable on top of the same plumbing problem: the agent's own reasoning can be steered, through prompt injection or a poisoned tool description, into voluntarily misusing access it legitimately holds. That's not a delegation bug in the OAuth sense — it's a social-engineering attack aimed at software that happens to have judgment. The identity layer and the reasoning layer fail in different ways, and conflating them is where this analogy would start lying to you.

The detection side carries over too

This is the part worth sitting with if detection engineering is where you're headed. The blue-team version of this mapping holds up just as well as the red-team one. AD defenders watch for anomalous ticket-granting activity as a proxy for delegation abuse. The NHI equivalent is watching for token-audience mismatches, first-time-seen tool invocations, and agents reaching backends outside their declared scope — which is exactly what identity-aware MCP gateways and audience-bound tokens (the RFC 8707/9068 mechanism most 2026 hardening guides now recommend) are built to catch. It's the same detection philosophy, aimed at a protocol that's maybe eighteen months old instead of one that's been production-hardened since 2000.

That gap — mature offense-side patterns colliding with immature detection tooling — is arguably the more interesting career bet than either side alone right now.

What I'm actually going to go do with this

Spin up a local MCP server, deliberately misconfigure token passthrough, and watch exactly how it breaks. Read the OWASP NHI Top 10 and the emerging OWASP MCP Top 10 side by side with a Kerberos delegation cheat sheet and map every item yourself instead of taking my table on faith. None of the AD muscle memory is wasted here — it's the exact mental model this surface needs, it's just missing a translation layer.

The attack surface changed venues. The attack didn't change shape.

Further reading / sources

Still early in this field — if I've mismapped a piece of the delegation model, I'd genuinely like to hear about it.