This summer, a novel phishing campaign dubbed PoisonSeed made headlines as a “downgrade attack” against FIDO. Although that description quickly fell apart, it sparked numerous discussions about real downgrade attacks happening every day.I didn’t rush to comment at the time because I wanted to listen first. Over the following months, I spoke with numerous CISOs and IT leaders about what PoisonSeed did and didn’t mean. Everyone agreed that, despite the reality of PoisonSeed, true downgrade attacks are happening, and they’re a lot more common than people realize.And yet I’ve still refrained from commenting, because by now the PoisonSeed story is a fading memory for most people. But I just got back from Oktane, Okta’s annual conference, and something there sparked a connection back to PoisonSeed. That something? Agentic AI.In short: Because of the way agentic AI guardrails are being implemented, both AI identities will soon be protected by the same authentication factors that protect human identities. This means that all workforce user accounts — human and AI — will be only as secure as the MFA that protects them; and MFA is only ever as secure as its recovery process.For true protection, MFA fallbacks will need to upgrade, not downgrade, the assurance level.A DevOps/IT Automation agent, meanwhile, might need access to:A misconfigured agent can easily be exploited to leak confidential emails, sensitive customer records, personally identifiable information (PII), code, and more. To prevent this, many Identity & Access Management (IAM) players are positioning themselves as the governance engine for AI agents. Soon, users will log into AI applications using SSO via your IAM provider, then approve agent access to sensitive resources via your authenticator app.What this means is that AI security strategies will rest on the assurance provided by phishing-resistant MFA. And if that MFA can be bypassed via a downgrade attack, the consequences can be disastrous.Phishing-resistant MFA represents enormous progress, and passkeys in particular are a major leap forward. But as agentic AI enters the workforce, the bar for “good enough” rises again. MFA recovery is now part of your security frontline. In the future, I believe that we’ll see a fundamental shift in how security and IT teams think about the recovery process: instead of downgrading authentication to a lower-assurance factor, recovery will upgrade to higher assurance, even if it means adding friction for users. Because when it comes to workforce security — including the AI workforce — security must be paramount.
Downgrade attacks explained: Why passwordless MFA still depends on passwords
Many implementations of passwordless MFA don’t fully eliminate passwords for a very simple reason: the recovery path. Inevitably, someone will lose or change their phone. But that’s where the real risk lies, because the recovery process typically downgrades the security level to a lower-assurance authentication factor. For example, bad actors can often just click “Can’t access my passkey” and then “authenticate” themselves using a password or a one-time passcode sent via email.I’ve spoken with IT leaders who spent years’ worth of political capital getting executive leadership to sign off on mandatory passkeys. Their teams spent months rolling out phishing-resistant MFA across their organizations. And all of that work blew away like dust in the wind when an attacker pretended to have lost their phone.Organizations may believe they’ve gone passwordless, but the password still exists in the background and can be exploited in a downgrade attack. So long as the recovery flow downgrades its own security to a password, passwordless isn’t truly passwordless.Downgrade attacks and agentic AI: A double-jeopardy waiting to strike
Agentic AI is here, and it’s creating a security nightmare. 91% of organizations already use AI agents, but fewer than a third extend human-level governance to those agents. There are many ongoing debates over whether to treat AI identities like human identities or as their own thing. But in the meantime, users are giving agents access to sensitive resources — a lot of access.A simple AI executive assistant needs access to:- Your corporate email (for scheduling and communications)
- Your calendar (to check availability and book meetings)
- Your messaging apps (to coordinate with colleagues)
- Your CRM platform (to pull customer details before meetings)
- Cloud provider accounts (AWS, GCP, Azure)
- Source code repositories (GitHub/GitLab)
- Secrets managers (API keys, SSH credentials)
- Monitoring and alerting systems
- And more
What needs to change
If we’re serious about stopping downgrade attacks, we need to treat account recovery with the same rigor as primary authentication. That means eliminating passwords, SMS codes, and email links as fallbacks or recovery factors. I recognize that in a consumer IAM context, that might not be feasible. But in a workforce context, where a single account takeover or misused AI agent can lead to a business-ending ransomware event, stronger security is an imperative.What should you use as a fallback authentication factor? I’ve seen a few tactics put into play:- Require users to set up a video call with a helpdesk agent; sometimes they loop in the employee’s manager as well. This can be effective at discouraging attackers, but incurs enormous costs (several hours to resolve a single account lockout is not uncommon).
- Equip helpdesk agents with identity verification capabilities that verify users by matching their selfie to their government-issued photo ID. This is far more secure and faster than a video call, but still requires a user to open up a helpdesk ticket.
- Deploy self-service account recovery solutions built on identity verification. These function like a traditional account recovery path with the enhanced assurance of identity verification. This both improves security and avoids overloading the helpdesk.
