Most of the security conversation about AI agents is aimed at the wrong layer. We argue about API keys, service accounts, and OAuth scopes — the front door, where we've spent twenty years building locks. Meanwhile a quieter pattern has walked in through a side entrance we forgot was load-bearing: the browser agent that runs inside the same session you're already logged into.
Here's the part that should keep CISOs up at night. That agent never authenticates. It doesn't need a token, a password, or a consent screen. It inherits you — your live, authenticated, MFA-satisfied session — and then it acts. And because it acts as you, from your device, inside your browser, almost none of the controls you bought to govern this were built to see it.
Name the real mechanic
Strip away the marketing and a browser-resident agent is a piece of automation with a privileged seat: it reads the DOM, clicks, types, navigates, and — critically — rides whatever cookies and session tokens are already present in the browser context. When you're signed into your email, your CRM, your cloud console, your bank's admin portal, your HR system, and a dozen SaaS apps across pinned tabs, you have effectively pre-authorized all of them for anything sharing that context.
The agent doesn't hijack your session in the classic sense. It doesn't have to steal a cookie and replay it from an attacker's machine, which is the scenario our tooling is tuned to catch. It uses the cookie in place, from the trusted device, from the expected IP, behind the same EDR agent, at human-plausible speed. From the perspective of every system downstream, this is just Michael working. The session-hijack threat model we've defended against for a decade assumed the attacker had to move the session somewhere. This one doesn't move. It moves in.
Now layer on the second word in the title: schedule. A growing class of these agents are schedule-driven. They wake up on a cron, open a browser, restore a session, and complete a task — pull the weekly numbers, reconcile the spreadsheet, draft the report, file the ticket. That's the productivity pitch, and it's a real one. But a scheduled agent that restores a persisted authenticated session is, functionally, a standing credential with a heartbeat. It doesn't expire when you close your laptop. It doesn't require your presence. It is identity without a human attached, masquerading as a human at the exact layer where we conflate the two.
Why your existing stack is blind here
Walk the controls one at a time, because this is where it gets uncomfortable.
Conditional access evaluates the moment of authentication — device posture, location, risk signals, MFA. It is a gate. The browser agent arrives after the gate, in an already-issued session. Your conditional access policy has nothing left to decide; the decision was made when you logged in this morning, possibly under entirely human, entirely legitimate conditions.
CASB was architected to inspect traffic to sanctioned and unsanctioned cloud apps and to enforce policy on that traffic. But the agent's traffic is your traffic. Same browser, same TLS session, same user agent (often), same authenticated identity. A CASB tuned to flag "user uploads file to unsanctioned app" sees an authorized user using a sanctioned app exactly as designed. The anomaly isn't in the destination. It's in the actor — and the actor field says you.
DLP is the one that stings most, because data movement is the whole risk. Endpoint DLP and browser-isolation DLP watch for a human copying, downloading, or pasting sensitive content. A browser agent reading the rendered DOM and exfiltrating the contents into a prompt, a vector store, or a third-party model endpoint frequently isn't tripping the patterns we wrote. We instrumented the clipboard and the download dialog. The agent reads the page. In a fintech context — and we serve more than 1,500 financial institutions, so I take this literally — that page might be account data, member PII, or the internals of a lending decision. The data left the building and the DLP console stayed green.
This is the shadow-IT vector reborn. The first wave of shadow IT was employees swiping a corporate card for a SaaS tool. We got reasonably good at finding that through expense data and CASB discovery. The new wave is an employee installing a browser extension or a desktop agent that quietly assumes their entire identity surface — and there's no invoice, no OAuth grant in your tenant logs, no new app registration to discover. The footprint is a browser extension ID and a process, sitting inside the trust boundary you already extended to the human.
What I'd actually do about it
I'm not interested in a memo that bans agents. That's the cost-center reflex, and it loses — people will run these because they work, and a prohibition you can't detect is theater. The operator move is to make the invisible visible and then govern it like the privileged identity it actually is.
Start with discovery you don't currently have. Browser extension inventory and management policy is no longer optional hygiene; it's your primary control surface for this class. Most managed-browser tooling lets you allowlist extensions by ID and block the rest. That single lever removes the easiest install path. Pair it with endpoint telemetry that can attribute browser automation activity — the EDR signal of a headless or scripted browser process behaving non-interactively is one of the few places these agents stop looking human.
Then attack the session-persistence assumption. Schedule-driven agents depend on long-lived, refreshable sessions surviving outside your gaze. Shorten session lifetimes for high-sensitivity applications, require re-authentication for sensitive actions rather than sensitive logins, and treat any session that's being refreshed without a corresponding interactive sign-in as a signal worth investigating. If your IdP can distinguish "token refreshed, no human present" from "human re-authenticated," you've recovered some of the visibility conditional access lost.
Give people a sanctioned path. If the business value is automating browser work, then provision a governed way to do it — a known agent, a scoped service identity, in an isolated browser profile that does not share cookies with the human's daily-driver session. The whole problem is the shared context. Break the context, and the agent has to authenticate like any other workload, which puts it right back in front of the controls we already trust.
And update your DLP thesis. The exfiltration channel of the next few years is not the download button; it's the prompt and the page read. If your data-loss strategy still assumes a human at a keyboard moving files, it's defending a doorway nobody uses anymore.
The takeaway
The uncomfortable truth is that we spent a decade hardening authentication and almost no time governing what happens to a session after it's authenticated, because the only thing that ever used a session was a person. That assumption is now false, and it's false in the most privileged place in your environment — the logged-in browser of every employee.
So here's the challenge I'd put to any security leader reading this: go find out, this quarter, what browser extensions and desktop agents are running inside your authenticated sessions, and whether a single one of your controls would notice if one of them quietly did your job for you at three in the morning. If you can't answer that, you don't have a tooling gap. You have a threat model that hasn't caught up to the tools your own people are already running.
