AI's Third Wave: Coworkers Break the Security Model That Worked for Agents

Persistent AI "Coworkers" Break the Identity Model Built for Chatbots and Task Agents

Token Security, an identity-security vendor, has published an analysis arguing that the security models organizations built for earlier phases of AI adoption do not hold up against a new category of AI system: the persistent "AI coworker." In a piece published by BleepingComputer on September 30, 2026, Token Security lays out what it calls "AI's third wave" — a progression from session-scoped chat tools, to task-scoped agents, to AI systems that operate continuously with standing access, much like a human employee who never clocks out. The firm's core argument is that identity and access management programs were built around the assumption that non-human accounts are temporary and task-bound. Persistent coworkers violate that assumption by design, and most organizations have no process for discovering them, assigning them an owner, or ever turning them off.

How the Three Waves Escalate Risk

Token Security frames AI adoption as three overlapping waves, each with a different attack surface. In the first wave, AI was a session-scoped chat interface — a user opened a conversation, asked a question, and closed it. The security concern in that model was largely about output: what the model might say, leak, or hallucinate within a bounded session. In the second wave, organizations moved to task-scoped agents — AI systems given a specific job, a specific set of tools, and access that (in theory) ended when the task did. The risk shifted from words to actions: what the agent could actually do with the permissions it was granted, for the duration it held them.

The third wave is where Token Security says current controls fail. Persistent AI coworkers are not bound to a single session or a single task. They run continuously, hold standing privileges the way a full-time employee does, and are expected to keep working across many projects over an indefinite period. Unlike a contractor whose access naturally ends when a contract does, a persistent agent has no built-in expiration point — it just keeps running, and keeps accumulating access, until someone deliberately notices and intervenes.

Why Persistent Coworkers Break Existing Controls

Token Security identifies four specific ways this new category of AI system defeats identity programs that worked reasonably well for waves one and two:

• Standing privileges. Persistent coworkers retain continuous access rather than access scoped to a session or task, creating an ongoing exposure window that never naturally closes.
• Access creep. Because a single persistent agent can be attached to multiple projects over time, it can accumulate permissions faster than a human employee would — and those separately granted permissions can combine into an authority level nobody explicitly approved.
• Orphaned credentials. Most agents today authenticate by inheriting a human user's credentials rather than using an identity of their own. When that happens, audit logs show the human's name, not the agent's — making it effectively impossible to attribute an action to the automation that actually performed it.
• Deprovisioning gaps. Human and project-based access reviews have a natural trigger: an employee leaves, a project ends, access is revoked. Persistent agents have no equivalent lifecycle event, so credentials tend to sit unused and unreviewed — what Token Security describes as zombie access — long after the agent's original purpose is gone.

Token Security's Five Identity Controls

To close the gap, Token Security proposes treating persistent AI coworkers the way a mature organization treats a new human hire, not the way it treats a service account or a short-lived script. The firm outlines five controls:

1. Discovery. Find unregistered "shadow" agents already operating in the environment by detecting them through their authentication traffic, rather than relying on a voluntary inventory.
2. Dedicated identities. Give every persistent agent its own credential, separate from any human user it was originally launched by, so its actions are attributable in audit logs.
3. Human sponsorship. Record a named human owner accountable for each agent — the equivalent of a manager of record — rather than letting agents exist without anyone responsible for them.
4. Scoped permissions. Limit each agent's access to what its specific tasks require, rather than inheriting the broader permission set of the employee who set it up.
5. Expiration planning. Define in advance the conditions that should trigger deactivation — team dissolution, the sponsoring owner leaving the organization, or extended idle periods — instead of leaving the agent to run indefinitely by default.

Token Security summarizes the philosophy in a single line: give an agent "a badge before you give it a job."

Impact Assessment

Recommendations

For IT and Security Admins

• Inventory every AI agent with standing or recurring access to production systems, distinguishing session-scoped tools, task-scoped agents, and persistent coworkers.
• Run a discovery pass focused on authentication logs to surface agents that were never formally registered — Token Security's stated approach for finding shadow agents.
• Flag any agent still authenticating with a human employee's credentials as a priority remediation item, not a low-severity finding.

For Identity and Access Management Teams

• Treat persistent AI coworkers as a distinct identity class in your IAM program, with their own provisioning workflow, not a subclass of service accounts or human users.
• Require a named human sponsor for every persistent agent at creation time, and reassign or revoke that agent's access automatically when the sponsor leaves or changes roles.
• Build scoped, least-privilege permission templates specific to agent task categories, rather than granting agents the same broad roles as the humans who deployed them.

For Engineering Leaders and Agent Owners

• Define an explicit expiration or review trigger for every persistent agent you deploy — idle-time thresholds, project end dates, or sponsor changes — before the agent goes live.
• Push back on default configurations that grant agents inherited or standing access; request scoped credentials issued specifically to the agent instead.
• Periodically re-certify that each agent's accumulated permissions still map to its current task set, since access creep compounds silently over time.

Key Takeaways

1. Token Security frames AI adoption as three waves: session-scoped chat tools, task-scoped agents, and now persistent "AI coworkers" with standing, continuous access.
2. The core problem with the third wave is that persistent agents accumulate credentials permanently rather than temporarily, unlike the session- or task-bound access of earlier waves.
3. Four specific failure modes were identified: standing privileges, cross-project access creep, orphaned credentials from inherited human logins, and deprovisioning gaps with no natural lifecycle endpoint.
4. Token Security recommends five controls: discovery of shadow agents, dedicated non-human identities, human sponsorship, scoped permissions, and predefined expiration conditions.
5. Agents that authenticate using inherited human credentials break audit attribution, making it impossible to distinguish human actions from automated ones in logs.
6. The guiding principle Token Security proposes is straightforward: every persistent agent should get its own identity — "a badge" — before it is given a job to do.

Sources

• BleepingComputer: AI's Third Wave: Coworkers Break the Security Model That Worked for Agents