When a contractor rolled off my team at Kyndryl or IBM, a clock started.
Badge deactivated. VPN certificate revoked. Repository access pulled. Shared mailbox permissions removed. Someone signed a form confirming every one of those things had happened, and if that form didn’t come back inside the window, it escalated to me.
That was the boring, unglamorous discipline of running technology at scale. Nobody got a plaque for it. But across 200+ engineers and dozens of client environments, the offboarding checklist was one of maybe five controls standing between us and a very bad quarter.
Here’s the question I’ve been asking business owners for the last two months, and almost nobody has an answer: when you give an AI agent access to your systems, what’s your process for taking it back?
Not “can you.” Not “in theory.” What is the process, who owns it, and when did you last run it?
The silence on that question is the most under-discussed risk in AI right now.
The unit of risk changed and nobody updated the model
For two years, using AI meant a request and a response. You typed something, you got something back, the exchange ended. Whatever risk existed lived inside that exchange.
Then it became session-scoped. The tool remembered your conversation, held some context, and closed when you closed the tab.
That’s over. On August 3, Alibaba shipped Qwen3.8-Max, and the headline claim wasn’t a benchmark score. It was that in internal testing, the model completed a full software engineering project spanning 16 days without human intervention.
Read that again with your operations hat on. Sixteen days. Running. Unsupervised.
I want to be careful here, because this is a vendor-run demonstration rather than an independent evaluation, and the difference matters. But you don’t need to accept the number at face value for the implication to land. The industry is now optimizing directly for autonomous execution measured in days and weeks. Whether the honest figure today is sixteen days or six, the direction is fixed and it isn’t reversing.
An agent that runs for two weeks outlives the context in which someone approved it. The person who granted access was thinking about a task. What they actually provisioned was a process.
What the browser agents actually inherit
The second half of this is worse, because it’s already on your employees’ desktops.
Google’s Auto Browse gives Gemini control of Chrome to complete multi-step tasks on your behalf. Its personal intelligence feature connects to Gmail, Search, YouTube and Photos, and can draft and send an email without switching applications. That is a genuinely useful product. It is also, from a security architecture standpoint, an agent operating inside your authenticated session with your identity.
An agent in the browser doesn’t get its own permissions. It inherits yours. Everything you’re logged into, it’s logged into.
The foundations underneath are not settled. In a University of Washington study published July 3, researchers tested seven agentic browsers: Chrome with Gemini and ChatGPT Atlas among them and found four of them let attackers bypass the same-origin policy. That’s the boundary from 1995 that stops one website from reading another’s data. It is not an advanced control. It is the floor. The researchers’ own conclusion was that browser agents aren’t ready for the public.
I’m not telling you to rip Chrome out of your business. I’m telling you that the access model you’re relying on was designed for a human clicking links, and the thing clicking links now is not a human.
Why I keep coming back to visibility
The most valuable work I ever did on a client account looked like nothing from the outside.
At Kyndryl, on an engagement, the ask was a 25% improvement in incident detection. We delivered 38%, and more than $2 million in documented savings followed behind it. We didn’t get meaningfully better at fixing things. We got better at knowing things were broken.
That distinction is the whole game here too. You cannot revoke access you can’t see. You cannot offboard an agent you never inventoried. Most of the businesses I talk to could not produce a list of every AI agent currently holding a credential in their environment, and several of them are in regulated industries.
Your identity and access management practice already knows how to do this. It has known for twenty years. The problem isn’t that the discipline is missing it’s that nobody has thought to point it at agents, because agents don’t feel like users. They feel like features.
Five things to put in place before your next agent goes live
None of this is exotic. All of it is the boring stuff, which is why it works.
Give the agent its own identity. If an agent operates under a human’s credentials, your audit log is now fiction. Every action it takes is attributed to a person who didn’t take it. Service accounts, scoped per agent, with an owner’s name attached. This is the single highest-value change on the list and most organizations can do it in an afternoon.
Scope access to the task, not the person. The instinct is to grant the agent what the approving employee has. That’s backwards. Start from what the specific task requires and grant only that. An agent summarizing support tickets does not need send-mail permission.
Put an expiry date on every grant. Access with no expiration is access forever, because nobody comes back to clean it up. Ninety days is a reasonable default. When it lapses, someone has to consciously renew it which forces a review that would otherwise never happen.
Log agent actions separately from user actions. When something goes wrong at 2 a.m., you need to answer “did a person do this or did a process do this” in seconds, not hours. If those two streams are mixed, you’re reconstructing intent from timestamps.
Run a revocation drill. Pick an agent. Kill its access. Time it. Confirm it actually stopped. I have watched more than one organization discover that revoking a credential in the console didn’t terminate a running process holding a live token. Better to learn that on a Tuesday afternoon than during an incident.
The uncomfortable part
Every business I’ve worked with has an offboarding process for people. Almost none have one for agents.
That gap exists because agents arrived through the product door, not the IT door. Somebody enabled a feature. Somebody clicked “allow.” There was no requisition, no access review, no ticket. The governance apparatus that would have caught a new contractor never fired, because nothing looked like hiring.
But something was hired. It has credentials, it acts on your behalf, it operates unsupervised for extended periods, and unlike a contractor it will never tell you when it’s done.
The companies that get this right won’t be the ones with the most sophisticated AI. They’ll be the ones who treated the first agent like a new employee: named, scoped, logged, reviewed, and revocable.
So here’s the honest either/or. You can build the offboarding process now, while you have three agents and the exercise takes a week. Or you can build it in eighteen months, when you have forty, nobody remembers who approved half of them, and you’re doing it under an auditor’s deadline.
One of those is a Tuesday. The other is a very bad quarter.
Ready to find out what’s actually holding credentials in your environment? Our AI Infrastructure Assessment includes a security posture evaluation and an integration gap analysis — the inventory most organizations discover they never had. Start the conversation.
Not sure where an agent governance practice fits in your roadmap? See how our AI Strategy and Implementation services sequence governance before deployment, not after.
Want more on the infrastructure side of AI? More on guardrails, vendor security, and what AI readiness actually costs on the Summit AI blog.
Russell Love is the Founder & CEO of Summit AI Business Solutions, based in Browns Summit, NC. With 20+ years of enterprise transformation experience at IBM and Kyndryl, Russell helps businesses build the foundations that make AI actually work.