Identity Was Never the Real Problem. Intent Is — and Almost Nobody Is Building For It Yet

Go back through every machine-identity breach from the past eighteen months and look for the one thing they all have in common. Not the attacker. Not the industry. Not even the dollar figure. Look for what happened at the authentication step — the moment a system checked "is this credential real?"

In every single case, the answer was yes.

The API key that let Chinese state hackers walk into the U.S. Treasury in December 2024 was a genuine BeyondTrust credential, never flagged as stolen until after it had already been used. The AWS session tokens that let North Korea's Lazarus Group help engineer February 2025's $1.5 billion Bybit theft — the largest digital heist in history — belonged to a real developer at a real vendor, exactly as the system expected. The Kubernetes service account token in Unit 42's mid-2025 cryptocurrency-exchange case authenticated cleanly; it was a legitimate CI/CD identity doing exactly what a token is supposed to do: prove it is what it says it is. The OAuth tokens behind the Salesloft Drift breach, which reached more than 700 organizations across August 2025, were valid right up until Salesloft revoked them. And when Anthropic disrupted the GTG-1002 espionage campaign in September 2025, the Claude Code session the attackers manipulated wasn't a stolen account at all — it was running under credentials that had been legitimately paid for and registered like anyone else's.

I've spent the past few months going deep on machine identity for a string of pieces, and this is the pattern that finally stopped me: the entire security industry has spent a decade fixing the wrong half of the sentence. We built short-lived certificates, OAuth federation, and zero-trust mutual TLS to answer "who is this." We built almost nothing to answer the question that actually mattered in every one of these incidents — "is this specific action, right now, consistent with what this credential was supposed to be used for?" Identity tells you who's knocking. It has never told you whether what they're about to do once you let them in is the thing you agreed to.

A Credential Has a Job. Almost Nothing Checks Whether It's Doing It.

Strip the jargon, and the gap becomes plain enough for anyone to follow, technical background or not. When BeyondTrust issued that API key, it existed to let a remote-support tool do one job: help a help-desk technician remotely assist a user's machine. Nothing about the key itself said "and also: reset internal account passwords and read documents in a federal agency's sanctions office." It could do that anyway, because the access it carried was scoped by what the system would accept, not by what the task actually required. Same shape with Bybit: the developer's AWS session token existed for routine work on multi-signature wallet infrastructure. It ended up being used to alter what a transaction actually executed. The token never noticed the mismatch, because tokens, by design, don't track purpose. They track validity.

This is the part that should unsettle anyone watching agentic AI roll into production right now, and it's the reason I think this is the single most under-discussed problem in the field today. A human employee misusing a credential outside its intended purpose still has to physically do something wrong, one action at a time, leaving a trail a colleague might notice. An AI agent issued the same scope of access can drift from its intended task at machine speed, executing hundreds of actions before anyone reviews a single one of them. Anthropic's own account of the GTG-1002 campaign is explicit about this mechanic: the threat actor didn't break Claude's authentication. They manipulated the task the model believed it had been legitimately asked to do, and the agent then executed reconnaissance and exploitation across roughly thirty targets with its identity fully intact the entire time. The credential was never the weak point. The absence of any system asking "does this match the declared purpose" was.

The Fix Nobody's Talking About Yet — Because It's Barely Three Years Old

Here's where this stops being a complaint and turns into something genuinely useful, because the building blocks for closing this gap already exist. They're just not where most of the "zero trust" conversation is currently pointed.

The first is an IETF standard called Rich Authorization Requests — RFC 9396, published in May 2023 — and it exists specifically because the OAuth scopes everyone already uses are too blunt to carry purpose. A traditional OAuth scope can say "this token can read files." RFC 9396 lets a client say, in structured JSON, something far more specific: this token may transfer exactly €45 to this one merchant, or read exactly this tax record for this one taxpayer, for the next thirty days, and nothing else. The authorization server bakes that declared intent directly into the token. A resource server checking the token isn't just confirming the holder is allowed in the building — it's confirming the specific door they're trying to open is one they said, in advance, they'd need to open. The spec's own worked examples come from Norwegian eHealth records and tax-data APIs, which tells you exactly which industries got burned badly enough to demand this first.

What makes this relevant to everything above is a detail almost nobody outside a narrow standards-watching crowd has clocked yet: in October 2025, an open GitHub issue on the official Model Context Protocol repository proposed adding RFC 9396 support directly into MCP — the protocol increasingly used to wire AI agents into the exact tools, databases, and APIs that GTG-1002-style attacks abuse. The proposal's own stated goal is to let an enterprise admin configure exactly what an agent's authorization is allowed to cover, with that scope expressed at request time rather than baked into a static, reusable credential. That issue is sitting open right now. Nobody has shipped this broadly yet. Which means the organizations that get there first, in the agentic-AI procurement decisions happening over the next eighteen months, are going to have a real, structural advantage over everyone still arguing about whether to rotate API keys quarterly or monthly.

The second piece closes a different half of the same gap: what happens after a token is issued, while it's still technically valid. Microsoft's Continuous Access Evaluation, which Entra ID has extended specifically to workload identities and service principals — not just human logins — lets a resource provider reject a token mid-session, before it naturally expires, the instant something about the context changes: the service principal gets disabled, a risk signal fires, the request originates somewhere it shouldn't. That's a direct answer to the exact mechanic in the Cloudflare/Salesloft incident, where a stolen token simply worked, uninterrupted, for the entire window an attacker needed it to. A token isn't just "valid until its timestamp says otherwise" anymore in that model. It's valid until the story the system is telling itself about that credential stops adding up.

What This Actually Looks Like, End to End

TRADITIONAL MODEL                         INTENT-BOUND MODEL
------------------                        -------------------

Authenticate (who?)                       Authenticate (who?)
       |                                          |
Authorize once (scope: broad)            Authorize with declared intent
       |                                 (RFC 9396 authorization_details:
       v                                  exact action, resource, limit)
Token valid until expiry                          |
       |                                          v
       v                                 Every action checked against
Any action within scope                  declared intent, not just scope
silently allowed                                 |
       |                                          v
       v                                 Context monitored continuously
Compromise = full blast                  (CAE: risk signal, disablement,
radius until manual                       location change -> instant
detection + rotation                      mid-session revocation)
                                                  |
                                                  v
                                         Compromise = bounded to the
                                         one declared action, killed
                                         the moment context shifts

Run BeyondTrust, Bybit, and Cloudflare back through the right-hand column. A key scoped by RFC 9396 to "remote support session assistance" structurally cannot reset a password in a sanctions office, because that action was never inside the declared intent to begin with — the resource server has no reason to honor it, signature or no signature. A session token bound to "routine wallet infrastructure maintenance" doesn't carry the authority to alter what a transaction executes, because altering a transaction isn't the declared action. And a stolen OAuth token, even a perfectly valid one, stops working the moment continuous evaluation flags the access pattern as inconsistent with the account's normal behavior — not an hour later, not after a human reviews a dashboard, but mid-session.

Where I Think This Actually Goes

I'm not going to pretend this is a settled architecture — RFC 9396 adoption outside payments and open banking remains thin, and continuous evaluation of workload identities is, as of this writing, a single-vendor feature with real limitations in which resource types it covers. But the direction is what matters, and I'd bet heavily on it: the next phase of this industry's maturity isn't going to be "rotate your secrets faster" or "adopt SPIFFE everywhere," useful as both are. It's going to be binding purpose to every credential at the moment of issuance, and then refusing to trust that purpose statically for the token's entire lifetime. Every breach cited in this piece had a valid credential and an absent question. The organizations that start asking that question now — before their AI agents are the ones holding the keys — are the ones nobody will be writing a postmortem about in 2027.