The credential that never gets handed back
Itamar Apelblat, co-founder and CEO at Token Security, compressed the whole problem into two sentences in his writeup on Bleeping Computer (opens in new tab): an AI agent borrows your credentials, and an AI coworker never gives them back. That is the whole argument, and it is why AI coworker security cannot be handled by stretching the access model that served us for agents. The rest of the piece is elaboration.
I run a small VPS hosting business, and I have cleaned up more orphaned service accounts than I can count. The pattern never changes. A customer wires a monitoring tool into a droplet, hands it an API key with read access to the entire box, and eighteen months later the tool has been replaced, the vendor has been acquired, and the key is still in a config file, still valid. Nobody opens a ticket. The thing holding the key never had an HR record, so it never shows up on an offboarding checklist.
What makes this moment different from the last two years is not that the models got smarter. It is that a persistent AI coworker stops being a short lease attached to a human identity and starts being an identity of its own, with standing access that outlives the project that created it.
That distinction matters because the first two waves fit inside access models we already had. A session-scoped chat is a person typing into a text box, and the risk lives in what the model says back. A task-scoped agent is a person triggering a job, and the risk lives in what the model does before it stops. In both cases the credential underneath belongs to a human, expires with the session or the task, and gets reviewed the way any short-lived grant gets reviewed. Those you can audit.
The third wave has no natural expiry. An agent that books your meetings, reads your repositories, and answers in your team’s chat needs permissions that persist between conversations, because a coworker who forgets how to open the door every morning is not a coworker. Once access is standing rather than granted per task, the interesting question stops being what the model is allowed to say or do. It becomes what the model keeps.
Persistence breaks the model. Capability only makes the break more expensive.
Background: three waves, and why the third one is structurally different
The framing in the Token Security write-up (opens in new tab) splits the last three years into three waves, and the split holds up better than most vendor segmentation I read because each wave moves the risk somewhere different. Session-scoped chats put the risk in what the model says. Task-scoped agents put it in what the model does. Persistent coworkers put it in what the model keeps. Same stack underneath, three separate threat surfaces on top.
The strongest evidence that the industry intends the third one is the vocabulary. Microsoft markets agents as “digital colleagues.” Sam Altman sketched out virtual coworkers back in February 2025, which reads almost modest now. Nobody names a product category after employees unless the plan is for that product to sit inside the org chart, share the project folders, and hold the credentials.
What stayed constant through both earlier waves was that every identity on the wire traced back to a person. A chat session inherits the typing user’s permissions. A triggered agent runs under a service principal that someone set up under their own name, with the reasonable expectation that it dies when the task does. That is precisely why the first two waves were auditable at all. When something went wrong, you opened the log, saw a human name, and asked that human what happened.
The third wave removes the lease. It removes the human whose name was on the principal. It assumes access does not expire with the work. What remains is an entity holding credentials continuously, with no manager to review it, no badge to deactivate, and no resignation letter that kicks off the offboarding workflow.
You can watch the gap form in how these things get created right now. Someone runs a command, gets a JSON key file back, and pastes the path into a config. That file does not care whether the person who generated it still works at the company. It just keeps authenticating.
I have never once seen a small hosting shop audit what happens to the API tokens sitting inside its client accounts after a contractor stops replying to email. The tooling is still there. The token still validates. Nothing has broken yet only because nobody built a workflow on top of it.
Agents are that same situation, except people are already building on top of it.
What’s happening now: where AI coworker security stands today
The state of AI coworker security right now comes down to how agent credentials actually get issued, and every pattern in circulation treats the agent as a passenger rather than an entity. The first is an OAuth grant, where a human clicks through a consent screen and the agent operates inside whatever scopes came back. The second is an in-session handoff, where the agent inherits the reach of whoever is currently logged in. The third is a service account, usually one that existed before the agent did and got repurposed because that was the path of least resistance.
The platforms themselves are explicit about the limits. As the Token Security analysis (opens in new tab) puts it, neither Anthropic nor OpenAI run the OAuth client credentials grant in their hosted chat products, and ChatGPT connectors reject service accounts and JWT assertions outright. That matters because those two are the most widely deployed agent surfaces inside most companies. The place where agents live is the place that offers no way to give an agent its own identity.
There is a workaround, in the narrow sense that you can always call the API with a static bearer token. I have done exactly this on my own boxes for scripts that talk to cloud APIs. The token sits in a file with 600 permissions, a systemd unit picks it up, and everything works until it does not. That is a credential, not an identity. It has no owner field that means anything, no expiry anyone enforces, and no record of why it exists. Long-lived tokens pasted into config files are how we got here, not the fix.
Think about a site owner running WordPress with a transactional email plugin. The provider hands you an API key, you paste it into a settings page, and it sits in the database for years. Nobody rotates it because rotating it means finding every place it is used, and nobody ever wrote down where those places are. Agent tokens are the same shape of problem with a larger blast radius, because the agent will use every permission the token carries, not just the one you had in mind.
Then there is the trail. When an agent acts under a user’s grant, the audit log records the human as the actor. If your backup service account suddenly starts enumerating IAM policies at 3am, you want a real name attached to that action. In an agent world, the name you get is often someone who was asleep at home, or someone who left the company in March.
What it means in practice: standing privilege, access creep, and the deprovisioning gap
Standing privilege means the agent holds its access permanently instead of earning it per task. That is the same shape as a human account nobody has reviewed since onboarding, with one important difference. The human account at least shows up in an access review spreadsheet. Your agent does not, because it never had an employee record to hang off in the first place.
Then access creep happens at a speed no human process was designed for. A person accumulates extra permissions over years of tickets, role changes, and one-off exceptions. An agent accumulates them over weeks, and it accumulates them partly because it uses everything it holds. That second part is what vendors tend to leave out. A human with a permission they do not need will often never touch it. An agent given a grant will exercise it while solving whatever it was asked, because using the tools it was handed is the whole job.
The compounding is where it gets uncomfortable. Give an agent read access in one cloud project, deploy rights in a second, and the ability to post into a shared chat channel in a third, and every one of those grants was signed off by someone with authority over that single decision. Nobody approved the combined reach. The agent did not have to be clever about it. It only had to hold all three at once and use them in sequence, which is exactly the behaviour you want from a useful coworker and exactly the behaviour that makes the blast radius larger than any reviewer expected.
Per-action approval prompts stop working once the agent is persistent. There is only so much human attention in a day, and the person clicking approve at the fourth prompt is not reading the fourth prompt. Itamar Apelblat makes this point in the Token Security piece: confirming sensitive actions every few minutes is both annoying and a security problem, because the practice degrades the attention it depends on.
Deprovisioning is the step that gets skipped, and it gets skipped for a mundane reason. There is no offboarding ticket for something that never had an HR record, no manager to sign it, no last day. The contractor who wired up the integration moved on. The project it was built for got cancelled. The agent keeps waking up, keeps calling the API, keeps showing up in the invoice. I have service accounts on my own infrastructure that were created for a migration in 2021 and are still active, still holding keys, with nobody left who knows what they were for. Every one of them exists because removing it was someone else’s problem on a day that never came.
Q&A: What does AI coworker security actually require?
What is an AI coworker, in security terms?
A persistent non-human identity that holds standing access across more than one system, acts without a human reviewing each action, and has a lifecycle with an onboarding step and (at least on paper) an offboarding one. Strip the marketing language away and that is a service account with a personality. The novelty is not the access itself. It is the expectation that this identity keeps existing after the task that justified it is finished.
How is that different from an AI agent?
Session scope and task scope are the two things that kept the earlier waves manageable. A chat forgets what it read when you close the tab. A task-scoped agent gets a grant, does the job, and the grant can be revoked once the job ends, because everyone agrees the job ended. Persistence removes that natural endpoint, so the risk moves from what the model says or does to what it retains. Retention is the part with no expiry date attached.
Why doesn’t OAuth for AI agents work as-is?
OAuth was designed around a person reading a consent screen and agreeing to a fixed list of scopes. Agents discover tools at runtime. They read a tool list, decide they need something that was not in the original grant, and ask for more, often mid-task. Each of those extra requests turns into a human decision, and Apelblat’s point is that a confirmation flow firing every few minutes stops being a control and starts being a queue people click through. Revocation is cruder than it looks too. Killing the refresh token ends the grant but not the data the agent already read, which for someone running a couple of servers is the failure that actually keeps me up. Scope limits do not travel backward in time.
Who is accountable when the agent acts?
Whoever’s grant the call was made under, according to the log, whether that person did anything or not. The infrastructure records the human as the actor. Incident response then turns into guesswork, because you cannot distinguish a person clicking delete from a coworker doing it on their behalf at 3am while that person was asleep. Rebuilding actor attribution for agent traffic is unglamorous work, and it is a prerequisite for every question you will have to answer after something goes wrong.
What to expect next
Two changes look close to inevitable to me. The first is that access gets granted up front rather than request by request. Case-by-case approval only functions while somebody is sitting there to approve, and a coworker that keeps working overnight or across a weekend does not have that luxury. So the provisioning conversation moves earlier: what does this thing get on day one, against which systems, signed off by whom. That is a less satisfying answer than “we review every action,” but reviewing every action is the part that does not scale.
The second is that agents start requesting more access themselves as a normal part of the job. Apelblat frames it as a coworker being able to ask for additional access when a task needs it, with human review reserved for the sensitive slice rather than every tool call. I think that split is correct, though drawing the line between the two halves will be messy for a while. Every team will put that line somewhere different, and most will put it in the wrong place once or twice before it settles.
On vendor support, I expect agent-specific identities to keep arriving, mostly because the current workaround of pasting a static bearer token into a config file is embarrassing for everyone involved. How quickly Anthropic or OpenAI ship the OAuth client credentials grant, or accept service accounts in their connectors, I genuinely do not know. Google demoed the right shape of this at I/O in 2024 with a Workspace agent that had its own account and permissions, and it never shipped, which is a reminder that a demo is not a roadmap.
Tara Seshan, who leads product for ChatGPT Work and Codex at OpenAI, made a point on Lenny’s Podcast in August 2026 that reframes the whole discussion. The useful half of an agent is not model intelligence. It is access to data, cloud infrastructure, and reliability, the “meat and potatoes tactical” plumbing a human employee needs before they can accomplish anything. She described hiring a colleague and locking them in a room with no Slack, no docs, and no database, then wondering why they underperform. Her agents spawn sub-agents and hand work to colleagues’ agents, and both of those directions assume an identity model that does not exist yet.
What strikes me about her framing is that she is describing the exact surface security teams already own. Whether that reads as reassuring or alarming depends on how well you think that surface is governed today, and on my own boxes the honest answer is: unevenly.
Closing: start with the token inventory this week
The useful first move does not involve buying a product.
Spend an afternoon listing every long-lived credential that any model, agent, or script has touched in your stack. On GCP that means gcloud iam service-accounts keys list run across each project, since user-managed keys are the ones that quietly outlive whoever created them. On AWS, aws iam list-access-keys, plus a sweep of every ~/.aws/credentials file sitting on laptops, build boxes, and CI runners. Then work outwards into the unglamorous places: environment variables in your hosting panel’s cron jobs, API tokens held inside n8n, Zapier, Make, and every automation that glues your billing, DNS, and monitoring together.
Once the list exists, put a human name beside each row. Not a team name, not “platform”, a person. On my own boxes, more than half of the service accounts traced back to someone who had moved on, and several were created for a migration that finished years ago and were never touched again. A token with no named owner has no reviewer, and it will not show up in anyone’s ticket queue.
Second, grep your audit logs for actions attributed to human users that were actually performed by an agent holding their grant. You will find more than you expect, because that is exactly how the current model behaves. Measuring the size of that blind spot is worth doing even before you have a fix for it, since it changes how much weight you give to your own logs during an incident.
Third, write down the offboarding procedure for a non-human identity while things are calm. Who revokes the token. Who rotates the key. What breaks when it disappears and who notices first. What tells you a credential is gone rather than merely idle. Retrofitting that definition in the middle of a live incident, with an alert firing and no obvious owner, is how small problems become multi-hour ones.
None of this is exciting work, and none of it requires an agent governance platform to start. The inventory is the part that makes every later decision cheaper. Do that one this week, before the next coworker arrives with a credential you did not issue and cannot easily find.