Notifications
Clear all
Topic starter
19/08/2026 4:01 pm
TL;DR: AI agents are being deployed faster than identity teams can govern them, and Ory says 79% of firms still lack security policies for these systems, underscoring a widening gap between agent adoption and legacy IAM controls. The practical issue is not AI novelty but identity and access governance that assumes a human, not a runtime decision-maker.
NHIMG editorial — based on content published by Ory: The Rise of the "AI Coworker & Assistant" and Why Your Security Isn't Ready
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Define AI agents as a separate identity class Create a policy category for agent identities that sits beside human and workload identities.
- Bind agent permissions to task scope Limit each agent to narrowly defined actions, tools, and data sources that map to a specific business task.
- Add lifecycle controls for agents Apply joiner-mover-leaver logic to agents so provisioning, reassignment, certification, and shutdown are all tracked.
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.
👉 Read Ory's analysis of AI coworker and assistant security →
AI coworker and assistant identities: is IAM ready for them?
Explore further
19/08/2026 4:37 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI coworker security gaps are outpacing legacy IAM controls
