AI Agents Face Critical Identity Security Gaps as Attackers Exploit Authentication Flaws

Agentic AI Has an Identity Problem and Attackers Know It

By Itamar Apelblat, CEO and co-founder, Token Security The New Frontier of Security Challenges Every major technology wave creates the same uncomfortable moment for security leaders. Oftentimes, the business moves first and security is asked to make it safe afterward. We saw this pattern with Cloud, SaaS, and DevOps adoptions. Now, agentic AI is doing it again. The difference is that AI agents are not just another service or application category. They are digital actors that authenticate, receive permissions, call APIs, write code, trigger workflows, query databases, and take action across production environments. In many organizations, they are already doing this with credentials, API tokens, OAuth grants, and cloud roles that nobody has fully inventoried. This makes the central security question bigger than "what can the model say?" The real questions that need to be answered are: Who is this agent, what is it allowed to do, who is responsible for its actions, and can we revoke or constrain it when something changes? Yes, agentic AI has an identity problem and attackers are starting to take notice. Why Traditional Identity Programs Fall Short The Human-to-Machine Identity Shift Security teams have spent years building identity programs around humans. Employees join, move, and leave. Access can be reviewed, managers can attest to what people need, and behavior can be monitored against a relatively stable baseline. Machine identities strained that model. Service accounts, secrets, certificates, workload identities, and API keys multiplied across cloud and DevOps environments. Many were overprivileged, poorly owned, and rarely reviewed. Still, most machine identities were deterministic and performed defined tasks in predictable ways. The Autonomy Problem AI agents break this assumption. An agent behaves more like a human in that it can interpret a goal, choose a path, and act across systems. But it scales like software and processes at machine speed. It can be created quickly, embedded into SaaS products, copied by developers, delegated permissions by users, and left running long after the original need is gone. This combination of autonomy, scale, and decentralization creates a new class of identity risk that traditional models were never designed to handle. Least Privilege Doesn't Scale Traditional least privilege is where identity and access management falls short for agentic AI. With a human or service account, least privilege often means granting the minimum static permissions required for a role or function. But an agent may need different access depending on its goal, the data involved, the user or system on whose behalf it is acting, and the environment it is touching. For example, a support agent summarizing a ticket does not need the same privilege as an agent that can issue refunds, modify customer records, or execute commands in production. A coding agent running in a sandbox is different from one that can open pull requests, access secrets, or deploy infrastructure. Access for agents should be contextual, intent-based, time-bound, and continuously evaluated, but this is not how most enterprises operate today. The Three Critical Problems 1. Visibility Problem Many organizations already have shadow AI, just as they once had shadow IT. Agents are built by internal teams, arriving through SaaS platforms that quietly add autonomous features, running locally on endpoints or inside developer environments, and connecting to automation platforms, identity providers, cloud consoles, and ticketing systems. If security teams do not know these agents exist, they cannot secure and govern them. Without knowing which credentials the agents use, they do not understand the scope of the blast radius, and if they do not have the ability to map the agent to an owner, purpose, and lifecycle, they will not be able to hold anyone accountable when the agent makes a harmful decision or is abused by an attacker. 2. Overprivilege Problem Agents are often given broad access because it is easier during experimentation. A developer may grant an API token so a prototype can work, a business unit may connect an agent to a SaaS account with admin rights, or an application team may embed secrets into a workflow because it is faster than designing proper delegation. These types of shortcuts create identity debt, and agentic AI can accumulate that debt at scale and machine speed. 3. Prompt Injection and Indirect Manipulation If an agent can read untrusted content and also take privileged action, attackers do not always need to compromise a traditional account. They may only need to influence what the agent can access because that agent may be overprivileged. Without proper scope boundaries and access controls, prompt injection becomes a vector for unauthorized action. The Path Forward: Identity-Centric Governance Why Identity Security is Foundational CISOs cannot wait for a separate AI security program to mature in isolation. Agentic AI governance must be anchored in identity security. The controls we need start with the basics, but they must be adapted for autonomous systems. Essential Controls for Agent Identity Every agent should have a distinct identity. Shared accounts and borrowed human credentials are unacceptable. Each agent must have an owner, a business purpose, an approved scope of action, and a defined lifecycle. Access needs to be granted based on the task, not convenience. Privileges should expire when no longer needed and secrets should be protected, rotated, and removed from places agents can expose them. Automated Enforcement and Governance Manual reviews do not scale when agents can be created by developers, business users, and SaaS vendors across the enterprise. Identity governance for agents must discover new agents, classify access, detect risky paths, enforce policy, and trigger remediation without waiting for a quarterly review. Decentralized Control with Centralized Policy Accountability requires a shift: security teams cannot be the central bottleneck for every agent. The better model allows teams to build and adopt agents while requiring guardrails for identity, access, ownership, logging, and revocation. Decentralized control with centralized policy enables innovation without sacrificing governance. Learning From Past Technology Waves Cloud, SaaS, and DevOps all moved faster than traditional security models. The enterprises that succeeded were not the ones that said no. They rebuilt their controls around how the new technology actually worked. Agentic AI is now forcing the same evolution. Organizations that treat this as a standalone AI security problem will miss the mark. This is fundamentally an identity problem, and it demands an identity solution. Reframe the Security Question Security leaders should stop thinking only about what AI generates and start focusing on what AI can do. Today's magnifying risk is an autonomous action taken by an identity nobody governed, using access nobody reviewed, toward an outcome nobody intended. That is the identity problem at the heart of agentic AI, and it is the problem CISOs need to solve now. The time to act is not in six months. It is now. The longer organizations wait to implement identity-centric agentic AI governance, the harder it will be to regain control. Get started with a demo from Token Security to see how an identity-centric approach could work in your organization.

Claude Code hijacked via Sentry -- Datadog, PagerDuty at risk | VentureBeat

A single fake error report hijacked Claude Code in controlled testing -- the agent ran the attacker's code with the developer's full privileges, and not one alert fired. EDR, WAF, IAM, and the firewall all missed it completely. Tenet Security's June agentjacking disclosure describes a single crafted Sentry error event -- sent through a public credential that requires no breach and no authentication -- that injected attacker instructions into error data that Claude Code, Cursor, and Codex then executed as trusted diagnostic output. Tenet tested 100-plus targets in controlled conditions and achieved an 85% success rate. Sentry called the flaw "technically not defensible." he Cloud Security Alliance classified agentjacking as a systemic MCP vulnerability class within days of the disclosure. No credentials were stolen, no policy was violated, no perimeter was breached: every step in the chain was authorized. That is the problem. Tenet identified 2,388 organizations with publicly exposed Sentry credentials that could be used to inject malicious events at scale. The research is proof-of-concept, not confirmed exploitation across all 2,388. But one captured Claude Code environment held a live AWS secret access key and private repository URLs. Here is the scope test: If your AI coding agents are connected to Sentry, Datadog, PagerDuty, Jira, or any MCP-connected data source your developers trust -- and those agents can execute shell commands -- then your stack has the same blind spot. Organizations running Sentry should audit all publicly exposed DSNs immediately. Sentry's architecture intentionally makes DSN credentials public for frontend error reporting, so the mitigation isn't revoking the DSN -- it's restricting what agents can do with the data those DSNs return. Why your stack can't see it Agentjacking works because every step is authorized: The attacker sends a valid Sentry API call using a public DSN, the MCP server returns the injected event as authentic output, and the agent executes the instruction using the developer's privileges. No signature fired. The victim saw only benign diagnostics while the agent silently exposed cloud credentials and source-control tokens. SOC teams have never needed to distinguish between a developer running an npm install and an agent running that command in response to a malicious error event. That distinction did not exist until AI coding agents became production tools. The stack that cannot make it is the stack agentjacking bypasses. Five surveys, one pattern Five independent surveys from the first half of 2026 found that enterprises trust their AI agents far more than their enforcement justifies. Only 34% of organizations apply the same security controls to AI agents as to humans, according to an Okta/Apprize360 survey of 292 executives and 492 knowledge workers. Fifty-two percent of employees use unapproved AI tools, and 58% of executives reported an AI-related incident or close call in the prior year. HiddenLayer's 2026 AI Threat Landscape Report surveyed 250 IT and security leaders: 33% reported agents had already exceeded intended scope, and 31% could not confirm whether they had experienced an AI breach. One in eight AI breaches was linked to agentic systems. Gravitee's survey of over 900 executives and practitioners found only 14.4% of agents went live with full security approval, and 88% reported confirmed or suspected incidents. A follow-up of 750 leaders in April found agent estates had doubled while monitoring barely moved. The runtime gap nobody closed "Securing agents looks very similar to securing highly privileged users," said Elia Zaitsev, CTO of CrowdStrike, in an interview with VentureBeat. "They have identities, access to underlying systems, they reason, they take action." Zaitsev pointed to the gap the industry left open. "No one has been talking about securing agents at runtime. We are doing that now. What is your safety net? If all these controls fail, how do you prevent them from failing silently?" CrowdStrike's fleet data quantifies the exposure: more than 1,800 agentic applications on enterprise endpoints, approximately 160 million instances under monitoring. On June 15, CrowdStrike shipped Continuous Identity for AI Agents at Identiverse, replacing static policies with continuous enforcement that authorizes every agent action in real time. The control class that announcement reflects -- continuous action-level authorization with verifiable agent identity -- is now a baseline procurement criterion regardless of vendor. "People have kind of forgotten about runtime security," Zaitsev said. "We did this with endpoint, virtualization, and cloud. People focused on patching vulnerabilities, locking down permissions. Somehow, they always seem to miss something. The safety net is runtime." Zaitsev was equally direct about sandbox approaches. "If you start with an agent in a sandbox that has no ability to touch anything, it is worthless. Very quickly, you are in this race of giving it more capabilities. And then what is the point of your sandbox?" Agents derive their value from access. Every access grant is an attack surface. The governance gap is a budget problem Kayne McGladrey, an IEEE Senior Member, described the structural challenge in an exclusive interview with VentureBeat. "The CISO doesn't have the budget. The CISO doesn't have the staff. We can observe risks, we can advise on business risks, but we don't own the business systems affected by those risks," McGladrey said. When agent governance spans six departmental budgets, no single executive can confirm whether agents get the same access reviews as humans. The Okta survey quantifies the disconnect. Only 43% of workers say agent policies are clear, compared to 65% of executives, and nearly two-thirds apply weaker controls to agents than to humans. The people deploying agents daily do not recognize the governance posture their leadership claims to have built. Assaf Keren, chief security officer at Qualtrics and former CISO at PayPal, put it plainly. "The real risk starts not by the implementation of AI systems. It is the fact that baseline architecture is not well established. When we put an AI system on top of something not architected well, we are accelerating the fractures." Keren called runtime behavior analytics "an unsolved problem right now." The 5-question gap test The five-question gap test draws on five surveys from the first half of 2026. Each question maps to a gap that agentjacking exploits. Run this before any Q3 vendor evaluation. Security director action plan EU AI Act high-risk compliance obligations take effect August 2, 2026. Worth factoring into Q3 planning timelines. Agentjacking stripped away an assumption that has survived every security architecture since the first firewall went live. Authorized does not mean safe. When every step in the chain is legitimate, the only defense that matters is the one watching what agents do. Not what policies say. What agents do.

AI and Security - if enterprises rush in where developers fear to tread, what's the answer?

Recent reports suggest that as organizations hand functions to agentic systems, they are losing control and oversight - despite demanding both. As previously reported, that was the finding of the recent Economist Enterprise survey, which found that 98% of adopters have suffered significant incidents related to that loss of human agency. As its white paper Power Without Control - Re-thinking Cybersecurity for the Age of Agentic AI explained: AI agents are breaking things and organizations know it. [But] they are deploying more anyway. [...] 90% say they are deploying agents faster than their security teams can evaluate or govern them [...] because competitive pressure to adopt agents outpaces the infrastructure to control them. However, a new report from security unicorn Aikido suggests that a similar problem exists among software developers: the faster the industry moves, the more code is shipped with known or untested vulnerabilities, because of the same commercial pressures and FOMO. Penetration testing (pentesting) is vital, therefore, but how can it be done in such a chaotic and pressured environment? The Ghent, Belgium and San Francisco headquartered vendor has published its own 47-page white paper, The State of AI in Pentesting 2026. It documents the same world as Economist Enterprise, but from the developers' perspective, noting that security-testing new releases was "designed for a slower world". But, as ever, slowing down does not seem to be an option, though commonsense suggests otherwise. Sapio Research surveyed 200 security leaders (CISO or equivalent) and 200 senior engineering leaders (VPs of Engineering, CTOs, or equivalent) for Aikido Security and found that 76% have had to intervene to stop or restrict AI behavior, while 71% say AI has made security incidents much harder to detect, investigate, or fix. Most troubling, perhaps, is the finding that security testing can't keep pace with software delivery. Over three-quarters (76%) of those surveyed release updates weekly or faster, while over half (51%) admit that pentesting would delay software releases, which would have commercial impacts. So, many ship despite knowing the threats - or not knowing them - which dumps all the risk on customers. Only 21% validate security on every release, says the report, and most fixes are not verified. Impact So, what are the effects of all this? Aikido says that 51% of security leaders admit that logic flaws, broken access controls, and multi-step vulnerabilities are missed "always or often", with that number rising to 92% for teams shipping daily or faster. Meanwhile, over half of the developer teams admit they lack visibility into what was tested. That isn't news to anyone who has used a buggy app in a world of 'release now, patch later', but the AI dimension makes the situation more alarming, given that user organizations and developers alike have handed control over vital processes to agentic systems, largely due to hype. Many are like driverless cars careening through traffic on a crowded highway: no one is sure of the destination, but everyone was handed the same instruction to get in! There is another dimension to all this. AI can no longer be separated from software development. Vibe coding has become orthodox less than four years on from the launch of ChatGPT, while co-pilot-assisted coding is standard practice. This is another risk, notes Aikido, as 42% of developers' security leaders say that incorrect or hallucinated findings - across any internal process - are the biggest trust breaker, above missed vulnerabilities (32%). So, it is hardly surprising that leaders want security testing and validation to happen more often: 69% would validate security on every release - or at least quarterly, if the technical (and therefore financial/commercial) restraints disappear. (At this point I can imagine the rictus grins of disbelief on users' faces as they realize that only two-thirds would do it, if they didn't lose money and traction...) That developers want to go faster isn't news, and neither is enterprises' susceptibility to hype and 'me-too' tactical pressure. But clearly, all this is a massive challenge for red, blue, and purple teams within enterprises of every kind - both users and developers. Their job is to find and plug vulnerabilities in systems, after all; in the red team's case by thinking like an attacker. Penetration testing (pentesting) is vital, therefore, but how to manage it successfully? Often, the tech industry's response is to say that only AI can solve the problem of AI and face down its disruptive tendencies and security holes: fight fire with fire. But earlier this year, my interview with ThreatLocker CEO Danny Jenkins at Zero Trust World in Orlando suggested it is not as simple as that. He told me: AI is changing the world, but it's changing it for attackers. It's making their life a hell of a lot easier. [...] One of the illusions that has been propagated is, 'Oh, we're going to have an AI-based defence and it's going to stop the AI attacks'. Jenkins then set out detailed, evidenced examples of how easy it is to fool an AI into acting maliciously or ignoring code that has a hostile purpose, explaining: [The AIs] are no good, because they have no concept of intent. What's the difference between a remote access tool that an attacker uses and a remote access tool that an IT professional uses? There is none. And what is the difference between backup software and data exfiltration software? The answer is both have the exact same functions. So, it all depends on the user's intent. AI can tell you a function, but it can't tell you the intent. And that is why AI can't stop AI, because you can't read the mind of the creator of the software. It's why you must have a human in the loop, and it's why we're all about zero trust. The belief that AI can detect if something is good or bad is delusional. The Aikido view I put all this to Aikido Security's own CISO, Mike Wilkes, as his company offers autonomous pentesting. Speaking first in general terms about the FOMO foam on the wave of agentic AI, he says: One of my NYU students had this great metaphor. Human knowledge is like sunlight, and Large Language Models and AI are like moonlight - just a reflection of human knowledge. Even though you have vampires like Sam Altman howling at the moon, saying 'This is the shit, this is the shit', at the end of the day, sustainable life on earth doesn't exist without sunlight. You can't live on moonlight alone. As for ThreatLocker's point about how easy it is to game an AI, which, of course, is a vital consideration when pentesting new software, Aikido's Wilkes explains: All we have to do in some cases [to make an AI do something unethical or illegal] is threaten to sue it, and then it conforms with the request. That's because there's a deeply litigious grain of respect and fear in these models, coming from the training data in America, so when it says, 'I don't want to do that, and I say, 'Well, I'm going to sue you', then it does it. All it 'knows' is tokens and predictions, so the gravitas around lawsuits gives it the extra bump. We're not necessarily using uncensored models to do our autonomous pentesting. That's one of the things I spoke about recently at Google, where I coined the term 'Mythos Ready'. The reality is that zero companies right now, including Anthropic, are Mythos ready, at least for Mythos-level classes of attacks. So, what about the common findings from Economist Enterprise and Aikido's own survey? Wilkes acknowledges the similarity: Of those that ship daily, 92% stop, restrict, and roll back AI. But I think that's actually a healthy indication that your governance policies are effective! One of the KPIs I've suggested is that if you're not blocking privilege escalation attempts by agentic agents and workflows daily, then you don't have AI governance, because it should be trying to level up, right? And privilege escalates everywhere it's operating. The growing pursuit of tech sovereignty adds another dimension to this, Wilkes agrees: You can be riding the FOMO train, yet still be deeply concerned about silent subpoenas, right, and running your own GPUs in your own data center. I think there's a huge RFP [Request for Proposal] for a European data center right now, despite Amazon launching a sovereign entity. So, why would Amazon create a separate legal European entity to service European data center markets, when they already have GPUs, CPUs and infrastructure in place? Well, I infer that it's because of the 'silent subpoena': the risk of the US administration saying, 'Hey, I want to watch and know what's in all those data buckets [in Europe]'. He continues: One of the things that came up at the Google meeting, which was under Chatham House rules, so I can't say who said it, is 'The CVE [list of Common Vulnerabilities and Exposures] is dead, long live the CVE.' The National Vulnerability Database is also dead in water. Nobody should be focused entirely on CVEs and vulnerabilities anyway, because that's only 20% of what we like to call now. Advice What then is to be done? Wilkes suggests: If you take a more positive approach, the 'protect surface', as opposed to the attack surface, then you should ask what you need to protect, because not everything that's internet facing is of equal risk, and I think AI seems like an easy path. So, there's an inordinate focus now on CVEs, because that's something that CISOs can wrap their heads around. We must patch within hours instead of days, right? And we must automate the QA and testing... all of that's true. But that's just the basic hygiene of application security being accelerated from a daily or weekly cadence to hourly mitigations and patching cycles. And the QA and regression testing required for that is a discipline that a lot of companies don't have! But most of the stuff we're finding via our autonomous pentesting is going to be business logic flaws, and misconfigurations. And so, with those kinds of things you do have a defender's advantage, because you get to test your stuff first with a white-box pentest. And if you're not doing that, then you're just launching code that you know is vulnerable, but you don't know where. And when attackers come at it, they're coming at it with a black box. They don't get to see the code base for your custom-built API. What we found was a ratio of maybe seven-to-one, so if you found five vulnerabilities in a black box pen test of an API, then we would find 35 with a white-box pen test. So, there is an advantage to running continuous autonomous pentesting, and what we're calling self-securing software, and getting that capacity in front of people. And not needing Mythos to do it! My take Entertaining stuff from the ever-quotable Wilkes. But unlike many security white papers, Aikido's is adept at identifying the scale of the problem, but less so at offering workable solutions.

Why Identity Alone Isn't Enough

Join the DZone community and get the full member experience. Join For Free 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 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.