AI coworker security gaps are outpacing legacy IAM controls

At a glance

What this is: This is an Ory blog post arguing that AI coworkers and assistants need dedicated identity controls because legacy IAM assumptions do not fit agentic behaviour.

Why it matters: It matters because IAM, NHI, and agent governance teams need a control model for software actors that can authenticate, access tools, and operate without a human session boundary.

By the numbers:

• AI agents are surging, yet 79% of firms lack security policies for them.

👉 Read Ory's analysis of AI coworker and assistant security

Context

AI coworker and assistant identities are software actors that can authenticate, request tools, and act inside business systems. The governance problem is that most identity programmes still assume access is assigned to a person or to a static workload, not to a runtime actor that can change tasks, context, and tool use within a session. That mismatch is now visible in AI agent security.

Ory frames the issue as a readiness gap: AI agents are moving into production faster than policy, lifecycle, and control design can catch up. For IAM and NHI teams, the question is no longer whether the technology exists, but whether identity governance can distinguish human identity, workload identity, and agent identity cleanly enough to enforce privilege boundaries.

The article’s starting point is typical of the current market: rapid adoption, thin policy coverage, and identity controls that were not designed for software actors making operational decisions at runtime.

Key questions

Q: How should security teams govern AI pilot identities before production?

A: Security teams should treat AI pilot identities as production candidates from the start. Every credential, token, and delegated permission must be tied to a named workflow, reviewed for scope, and made revocable. If the pilot cannot produce evidence-grade audit records and task-scoped access, it is not ready for production approval.

Q: Why do AI agents create more IAM risk than ordinary developer tools?

A: AI agents can make independent tool calls, chain actions, and authenticate with non-human identities while executing a task. Ordinary developer tools generally do not decide what to do next. That autonomy increases the chance of unintended access, makes attribution harder, and raises the value of session-level controls that show both intent and outcome.

Q: What do organisations get wrong about AI agent authorisation?

A: They often treat agent access as a tooling problem instead of an identity problem. If an agent can obtain credentials, call tools, and keep working without clear token scope and revocation, the environment inherits machine identity risk. Agent authorisation should be explicit, short-lived, and auditable, especially when MCP is involved.

Q: Who should own AI agent access decisions and lifecycle controls?

A: AI agent access decisions should be owned by the team that deploys and operates the agent, with identity governance and security functions enforcing policy and review. Ownership must be explicit because autonomous behaviour creates accountability gaps if nobody is responsible for the agent's permissions, monitoring, and offboarding.

Technical breakdown

Why legacy IAM models fail for AI coworker identities

Legacy IAM was built around human authentication flows or fixed machine-to-machine service accounts. AI coworkers complicate that model because they can initiate requests, select tools, and continue operating across multiple systems without a stable human operator behind every action. That makes identity, authorisation, and audit boundaries harder to define using conventional session logic. The core problem is not simply that the actor is automated. It is that the actor can behave contextually, making access decisions that depend on prompts, tool state, and live data rather than a predeclared workflow.

Practical implication: teams need to map which agent actions are still policy-bound workload access and which have crossed into runtime decision-making that needs distinct governance.

Agent IAM as a control layer between authentication and action

Agent IAM sits between initial authentication and downstream tool use, translating identity proof into bounded permissions for agent tasks. In practical terms, that means the system has to govern what an agent may access, when it may access it, and whether a delegated action remains within an intended task boundary. This is especially relevant where agents use external tools, APIs, or MCP-based integrations. Without that layer, the organisation is left with a valid login and no meaningful control over action scope once the agent starts chaining requests.

Practical implication: enforce task-scoped permissions and record every tool invocation that occurs after authentication.

Why identity lifecycle matters for AI agents

AI agents are not only authentication events. They have a lifecycle that includes provisioning, approval, revocation, offboarding, and recertification. If the organisation treats agent identity as a one-time setup problem, privileges accumulate and governance visibility decays. That is the same lifecycle failure pattern seen in NHI sprawl, but with a higher operational tempo because agents may be spun up, retrained, repurposed, or retired quickly. Identity teams need lifecycle ownership that matches the pace of the systems being deployed.

Practical implication: build joiner-mover-leaver controls for agents, not just for employees and contractors.

Threat narrative

Attacker objective: The objective is to abuse trusted agent identity and its delegated permissions to reach actions or data that the operator never intended to expose.

1. Entry occurs when an AI coworker or assistant is granted legitimate identity access to enterprise systems through normal onboarding or integration flows.
2. Escalation occurs when the agent is allowed to chain tool use across systems, extending its effective scope beyond the original task boundary.
3. Impact occurs when overbroad agent permissions enable data exposure, unauthorised actions, or business process manipulation at machine speed.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI coworker security is really an identity governance problem, not an AI novelty problem. The article’s significance is that it describes software actors entering the identity plane without a governance model that cleanly separates human, workload, and agent access. That creates policy drift before it creates technical compromise. Practitioners should treat agent identity as a first-class identity class, not as an extension of app authentication.

Legacy IAM assumptions break when the subject can act at runtime. Human-centric controls assume a user session, a bounded request, and a visible operator. AI coworkers can collapse those assumptions by chaining actions across tools and systems without a human approval gate between decisions. The implication is that access governance must be designed around action boundaries, not just login boundaries.

Agent IAM will become a control layer only if it is paired with lifecycle governance. Authentication without provisioning discipline simply creates a new identity sprawl layer. Ory’s framing points to a broader market shift where agent identity, NHI controls, and lifecycle review converge into one governance problem. Practitioners should expect platform teams to be asked for agent inventory, approval, and revocation controls, not just sign-in support.

Named concept: agentic identity drift. This is the gap between the permissions granted at agent onboarding and the privileges the agent effectively accumulates through chained tool use and reused integrations. The drift is structural because runtime behaviour changes faster than static policy reviews. Practitioners should interpret this as a lifecycle and authorisation problem that traditional recertification alone will not see.

Ory’s 79% figure signals a category-wide control vacuum. If most firms still lack policies for AI agents, then the market is in the same early phase NHI once occupied: adoption first, governance later. That means identity leaders should assume the control baseline is immature and move faster on classification, inventory, and policy ownership.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to the same report.
• For a governance baseline, see OWASP NHI Top 10 for the agentic risk patterns that overlap with AI coworker identity abuse.

What this signals

Agentic identity drift: AI coworkers will keep exposing a gap between onboarding controls and runtime behaviour until identity teams classify them separately from service accounts. That classification needs to drive ownership, review cadence, and revocation triggers, not just naming conventions.

With 79% of firms still lacking AI agent security policies, the immediate programme risk is not theoretical abuse but unmanaged access growth. Teams that already struggle with NHI sprawl should expect the same pattern to repeat faster once agent identities enter production.

Identity leaders should align agent governance with the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework because the control problem spans identity, authorisation, and operational accountability. The sooner the organisation defines what an agent is allowed to do, the less likely it is to inherit hidden delegated access paths.

For practitioners

• Define AI agents as a separate identity class Create a policy category for agent identities that sits beside human and workload identities. Use it to drive approvals, ownership, access review, and revocation decisions rather than folding agents into generic service account processes.
• Bind agent permissions to task scope Limit each agent to narrowly defined actions, tools, and data sources that map to a specific business task. Revoke or reissue access when the task changes, because persistent broad access turns agent autonomy into uncontrolled reach.
• Add lifecycle controls for agents Apply joiner-mover-leaver logic to agents so provisioning, reassignment, certification, and shutdown are all tracked. Require a named human owner for each agent identity and make offboarding a mandatory control step.
• Inventory tool chains and delegated access Document every external system an agent can reach, including APIs, MCP-connected tools, and downstream data sources. Review chained access paths for privilege escalation opportunities and remove any integration that is not essential to the task.

Key takeaways

• AI coworker security is an identity governance issue, not just an application design issue.
• A 79% policy gap shows that most organisations are still trying to govern agent behaviour without a dedicated control model.
• The practical response is separate identity classification, task-scoped access, and lifecycle control for agents.

Key terms

• Access-Centric IAM: Access-centric IAM treats access as a lifecycle process rather than a static entitlement. It links issuance, renewal, usage, and removal so security teams can govern human and non-human identities with the same operating logic across hybrid environments.
• AI Coworker: An AI coworker is a software actor that participates in operational work by using tools, data, and workflows alongside people. In identity terms, it is not a human user and not just automation. It needs explicit governance because its runtime behaviour can shift with context.
• Agentic Identity Drift: Agentic identity drift is the gap between the access an AI agent was granted at onboarding and the access it effectively accumulates through chained actions, reused integrations, or expanded task scope. The drift is a governance failure because static review cycles often miss it.
• Task-scoped permission assignment: A JIT pattern where specific permissions are attached directly for a defined task and then removed when the task ends. It is the closest of the common JIT models to true privilege minimisation because it removes the need for a permanent privileged role.

What's in the full article

Ory's full blog post covers the operational detail this post intentionally leaves for the source:

• How Ory frames agent identity inside its broader Agent IAM architecture and related product components.
• The article’s examples of where legacy IAM assumptions fail when software actors make runtime decisions.
• The source post’s explanation of how authentication, permissions, and session boundaries need to change for AI coworkers.
• The vendor’s own guidance on where teams should begin if they are defining an internal agent security model.

👉 Ory's full post covers the agent IAM framing, adoption context, and the security gaps behind the headline.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.