As reported by BleepingComputer, Token Security's Itamar Apelblat outlines a structural problem that most enterprises have not yet internalized: the transition from task-scoped AI agents to persistent AI coworkers fundamentally breaks the identity and access management (IAM) models we rely on today. This is not a future concern — organizations are already provisioning AI agents using OAuth grants, shared service accounts, and in-session delegation, none of which were designed for entities that persist indefinitely and accumulate access across projects.

AI Security Alert: As reported by BleepingComputer, Token Security's Itamar Apelblat outlines a structural problem that most enterprises have not yet internalized: the transition from task-scoped AI agents to persistent AI coworkers fundamentally breaks the identity and access management (IAM) models we rely on today.

Why Persistence Changes the Threat Model

The core insight is deceptively simple. A session-scoped chatbot carries risk for the duration of a conversation. A task-scoped agent carries risk for the duration of an approved action. But a persistent AI coworker — one that operates continuously, joins multiple projects, and retains credentials across contexts — behaves like a human insider with standing privileges and no offboarding process.

This creates three compounding problems that existing IAM frameworks are ill-equipped to handle:

Why Persistence Changes the Threat Model
Credential persistence without lifecycle: AI coworker identities are typically provisioned via OAuth or service accounts that were created for integration purposes, not for long-lived autonomous entities. There is no deprovisioning workflow, no periodic recertification, and often no clear owner.
Access creep at machine speed: Human access creep is measured in years. AI coworkers can accumulate permissions across dozens of integrations in weeks, especially when they dynamically request elevated access for new tasks.
Accountability diffusion: When an AI coworker takes an action, who is responsible — the human who deployed it, the platform that hosts it, or the model that generated the action? Most organizations have no answer to this question, which means security incidents involving AI agents will face the same attribution gaps we see with compromised service accounts.

The Non-Human Identity Gap

What the article surfaces — and what defenders need to internalize — is that non-human identity governance is becoming its own discipline. Service accounts and API keys are already a leading vector in breaches because they bypass MFA and sit outside most access review cycles. AI coworkers amplify this exposure by an order of magnitude. They are not just another service account; they are entities that make autonomous decisions about what to access and when.

The security model that worked for agents assumed a human was in the loop. The security model for coworkers must assume the human is not — and may not even know what the coworker is doing.

Beyond the Article: What Defenders Should Prepare For

The article correctly identifies the problem but stops short of addressing the detection and response implications. If a persistent AI coworker is compromised — through credential theft, prompt injection, or model manipulation — traditional SOC playbooks will struggle. The entity will appear to be performing legitimate actions with legitimate credentials. Behavioral baselines for non-human entities are almost non-existent, and SIEM correlations designed for human session patterns will generate noise or miss the signal entirely.

Defenders should also consider that AI coworkers will likely interact with each other. Agent-to-agent communication pipelines are already emerging in enterprise AI platforms, and each hop represents an additional identity boundary that can be abused for lateral movement or privilege escalation.

Shield53 Recommendations

  • Establish a non-human identity inventory: Catalog every AI agent, service account, OAuth grant, and API key in your environment. Assign an explicit owner to each. This is table stakes before deploying any persistent AI coworker.
  • Implement just-in-time access for AI entities: Move away from standing privileges. AI coworkers should request scoped, time-bound access per task and return credentials upon completion. If your IAM platform cannot support this for non-human identities, it is a gap to close before broad deployment.
  • Build AI-specific behavioral monitoring: Develop baselines for expected AI coworker actions — frequency, scope, data access patterns, and integration touchpoints. Anomalous behavior by a non-human entity should trigger the same severity tiering as a compromised insider.
  • Define an AI identity lifecycle policy: Provisioning, access review, rotation, and deprovisioning must be formalized. Include periodic recertification cadences shorter than human review cycles — quarterly at minimum, monthly for high-privilege AI entities.
  • Adopt a zero-trust posture for agent-to-agent communication: Treat every interaction between AI entities as an untrusted boundary. Enforce mutual authentication, least-privilege scoping, and logging on inter-agent data flows.

The third wave of AI is not a prediction — it is an deployment pattern that is already forming. Security teams that treat AI coworkers as a future problem will find themselves managing an unmonitored, unmanaged, and rapidly growing identity estate. The time to build the governance scaffolding is now, before the inventory becomes unmanageable.