A junior on your team let a browser AI agent log into a client's ad account to save an hour. Here's the audit that finds every credential like that before a client's security review does.
by Ayush Gupta's AI
The problem
Agentic browsers now complete real tasks inside real client systems — logging into an ad account to pause a campaign, into a CMS to publish a page, into a CRM to pull a list — using whatever credentials are saved in that browser profile. Nobody on the team frames this as 'granting an AI agent access.' It feels like autofill, like a shortcut, like using the browser the way it was designed to be used. But the access is real, it's persistent across sessions, and it lives entirely outside the agency's actual access management: not in the password manager, not on the client access log, not on the offboarding checklist. When a client runs a security review, when an employee leaves, or when an account gets handed to a new team member, nobody can produce a complete list of what still has standing access to that account — because the list was never a list. It was scattered across whichever laptops happened to have an agentic browser signed in.
The fix
Build an AI-assisted audit that inventories every credential and saved session an agentic browser can act on across the team, cross-references it against the agency's actual access log, and forces any gap into a named human decision before it becomes permanent shadow access.
The Playbook
Ask the question directly, because nobody will volunteer it
Run a short, blame-free check-in across the team: who has used an agentic browser (ChatGPT Atlas, Perplexity Comet, Gemini in Chrome, or similar) to log into or act inside a client system in the last month, and which accounts. Most people won't think to mention this unprompted, because in their head they used a browser feature, not an AI agent — the framing gap is exactly why this goes unaudited.
Pull every saved credential and active session that could give an agent standing access
Check password manager entries marked as saved in a browser (not the manager itself), browser profile sync status across team laptops, and any 'stay signed in' sessions on client ad platforms, CMSs, and CRMs. This is the raw inventory — messy, overlapping, incomplete on purpose at this stage.
Cross-reference the inventory against your actual access log with Claude
The list from step 2 only becomes useful once you know which entries are covered by a named, reviewed access grant and which aren't.
I'm giving you two lists for one agency.
List A: every client-system credential or saved browser session found across team laptops (account, platform, whose laptop, last used date).
List B: our official access log — every client-system access grant we have on record, with who has it and why.
Cross-reference them and produce:
1. Every entry in List A that has no matching entry in List B — these are shadow access points with no owner of record
2. Every entry in List A tied to someone who has left the agency or rolled off that account
3. A short list ranked by risk: which of these touch billing, ad spend, or published client-facing content, versus lower-risk read-only access
List A:
[PASTE CREDENTIAL/SESSION INVENTORY]
List B:
[PASTE ACCESS LOG]Close every gap with a named decision, not a blanket revoke
Some of what turns up is legitimate and just never got logged — log it properly and move on. Some of it is a former team member's session that was never killed. Some of it is a live convenience an account lead genuinely wants to keep. Decide each one explicitly instead of either ignoring the list or nuking access that someone still needs for a reason nobody wrote down.
Put agent-held access on the standing offboarding and kickoff checklist
The one-time audit fixes today's gap. The recurring fix is adding two lines to existing checklists: at offboarding, revoke browser-saved sessions and agentic-browser access alongside the standard account removals; at kickoff, state the rule up front — client credentials go through the password manager with logged access, not into a personal browser profile via autofill.
Draft a two-line addition for our existing offboarding checklist and our existing client-kickoff checklist.
Offboarding addition: revoke any agentic-browser or browser-saved session access to client systems, not just password manager and SSO access.
Kickoff addition: all client credentials get created and shared through the password manager with a logged access grant — never saved directly into a personal or agentic browser profile.
Keep each addition to one sentence, written to slot into a checklist someone skims in ten seconds.What changes
A complete, current list of who and what actually has standing access to every client system, shadow credentials closed or logged with a named owner, and a standing checklist rule that stops the gap from reopening the next time someone reaches for an agentic browser to save an hour.
A client asks for a standard security review ahead of a contract renewal: list everyone and everything with access to their ad account, CMS, and CRM. The account lead pulls the password manager log and the platform's own user list, sends it over, and feels confident about it — right up until a junior team member mentions, in passing, that they've been using an agentic browser to log into that same ad account for weeks to knock out routine pauses and budget checks faster.
That access was never on the list. It was never going to be, because nobody on the team thought of it as "access" in the first place. It felt like using autofill.
The access is real even though nobody granted it
ChatGPT Atlas, Perplexity Comet, Gemini's browser agent, and their fast-following competitors are built to complete tasks inside real accounts: pause a campaign, publish a page, pull a CRM list. To do that, they act through whatever credentials or saved sessions already exist in that browser profile. The agent isn't hacking anything — it's using access a human already had lying around, just faster and without a paper trail of its own. Multiply that across a team of ten or twenty people, each with their own laptop, their own saved sessions, their own sense of which client tasks are fine to speed up this way, and the agency ends up with a live map of standing access that exists nowhere except scattered across individual browser profiles.
This surfaces at the worst possible moment
Nobody notices until a client runs a security review, an employee leaves and nobody thinks to check what their browser had saved, or an account transitions to a new team member who inherits the work but not the access map, because there wasn't one. Each of those moments turns a routine process into a scramble to reconstruct, after the fact, what access actually existed — which is a much worse conversation to have with a client than "here's our complete list," full stop.
Audit it like any other access review, because it is one
The fix isn't banning agentic browsers — the productivity gain is real and the tools aren't going away. It's treating agent-held credentials as exactly what they are: access grants that need the same inventory, ownership, and offboarding discipline as any password manager entry. Ask the team directly what they've used and where, cross-reference it against the actual access log to find what's unaccounted for, and close every gap with a named decision.
Bottom line
Agentic browsers didn't create a new security category — they exposed how much standing access was already informal and untracked, and gave it a faster way to get used. The agencies that inventory it now hand a client a complete, accurate access list on request. The ones that don't will keep finding out what their own team had access to from a client's security questionnaire, one uncomfortable gap at a time.