A CEO calls his security team about a finance department incident. Did money move? Was vendor data exposed? Who owns this AI agent, and why does it have this much reach into the payment system? The agent had been quietly reconciling invoices and flagging unusual payment activity for months. Nobody thought twice about it, because it was doing its job. Then the employee who set it up left the company, and the OAuth grant connecting it to the spend management platform just kept running. No one revoked it. No one was watching it. That’s not a hypothetical. It’s the shape most cybersecurity failures take now: not a broken password, but a live authorization that outlived the reason it existed.

Three stories this week point at the same blind spot from three different directions. An AI agent with a stale OAuth grant. A phishing kit that abuses a legitimate Microsoft authentication flow instead of faking one. A browser flaw that steals your session without ever asking for a password. None of them are exotic. All of them exploit the same gap: security teams are still built to watch logins, and attackers have moved on to watching what happens after the login.

Nobody Revoked It, So It Still Worked

The finance-agent scenario from Help Net Security’s writeup is the cleanest illustration of the problem. The agent wasn’t compromised by malware. It wasn’t tricked by a phishing email. It had legitimate, standing access, granted by a real employee, approved through a real workflow, and it kept that access long after the person who set it up was gone.

This is the part traditional incident response playbooks handle badly. Offboarding checklists were built for humans: disable the account, collect the badge, revoke VPN access. They were never built for the OAuth grants, API keys, and service accounts an employee spins up on the way to doing their job. An AI agent connected to a spend management tool doesn’t show up on a standard access review unless someone specifically goes looking for it.

The breakdown occurred when the employee who configured it left and the OAuth grant remained active, allowing the agent to keep operating with no owner and no oversight.

Scale that across a mid-size company running a dozen AI agents wired into finance, HR, and customer data, and you have a population of standing credentials that nobody is accountable for. That’s not a future risk. That’s the current state of most environments running agentic tools today.

The Login Screen Was Real. That Was the Trick.

Illustration representing device code phishing attack via a legitimate Microsoft login flow
Device code phishing abuses a real Microsoft authentication flow, not a fake one.

Securelist’s research on device code phishing makes the same point from the credential side. OAuth 2.0’s device authorization grant exists so a Smart TV, printer, or streaming stick without a keyboard can still let you sign in: the device shows a short code, you type it into a real Microsoft login page on your phone or laptop, and the device gets authenticated. It’s a sound design for hardware that can’t handle a password field.

Attackers have figured out they can generate that code themselves, send it to a target in a convincing email, and ask the victim to enter it on the actual, legitimate Microsoft site. The user checks the URL. It’s correct. There’s no fake login page, no cloned domain, no telltale typo to catch. The user is authenticating themselves, on the real site, into a session the attacker controls. Every instinct we’ve trained users to rely on, “check the address bar,” fails here, because the address bar was never the lie.

This is why phishing training that stops at “verify the URL” doesn’t hold up anymore. The flaw isn’t in the site. It’s in a protocol behaving exactly as designed, pointed at the wrong target.

A Single Page Visit Was Enough

Illustration of the Opera GX browser data leak flaw
A malicious site could silently install a mod in Opera GX and read data from other pages a user visited.

Then there’s the Opera GX flaw, patched this week, where a malicious website could silently install a browser mod and use it to lift data from pages the victim wasn’t even actively viewing. Researchers reconstructed a signed-in user’s full Gmail address from a single, no-click visit. No phishing email. No password prompt. No user error at all, really, beyond opening a webpage.

Put these three together and the pattern is obvious. The password, the login screen, the “did they click something suspicious” question, none of that is where the real exposure sits anymore. It’s in what happens after authentication: the token that outlives its purpose, the session that gets hijacked silently, the grant nobody remembers approving.

Defense in Depth Means Auditing What Already Has Access

None of this requires exotic tooling to address. It requires treating standing access as a monitored asset instead of a one-time approval. Concretely:

  • Inventory every OAuth grant, API key, and service account tied to AI agents and integrations, not just human user accounts, and assign a named owner to each one.
  • Add access revocation to offboarding as a required, checked step, covering agent and integration grants alongside VPN and email.
  • Restrict or disable the OAuth device code flow at the identity provider level unless a specific business case needs it, and alert on device code sign-ins from unmanaged locations.
  • Set expiration and periodic re-approval on all non-human credentials, so an unused grant lapses instead of running indefinitely.
  • Lock down browser extension and mod installation via policy, and monitor for unexpected new extensions the way you’d monitor for unexpected new local admin accounts.
  • Feed authentication and session logs into your threat detection pipeline with rules tuned for anomalous grant usage, not just failed logins or brute-force patterns, since those are already well covered by rate limiting and firewall rules.

Security hardening built around the login moment, strong passwords, MFA prompts, firewall rules against brute-force attempts, is still necessary. It’s just not sufficient anymore. The three incidents above all cleared that bar. What they share is a second bar most organizations haven’t built yet: a routine, ongoing check on everything a user, agent, or session was granted, long after the moment it was granted. Defense in depth used to mean stacking controls at the perimeter. Now it has to mean auditing the standing access sitting quietly behind it.

Sources

Take Control of Your Server Security

Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.

Secure. Automated. Lightweight.

Stay up to date with the latest news, releases and more.

Take Control of Your Server Security

Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.

Secure. Automated. Lightweight.