Notifications
Clear all
Topic starter
06/06/2026 11:17 am
TL;DR: AI agents now schedule meetings, move money, provision infrastructure, and execute multi-step workflows, which makes identity and privilege abuse a primary risk in agentic systems, according to WorkOS and the OWASP GenAI Security Project. Least agency is not a tuning parameter anymore; it is the assumption boundary that fails when agents inherit human credentials and act at machine speed.
NHIMG editorial — based on content published by WorkOS: The OWASP Top 10 for agentic applications: What developers building with AI agents need to know
By the numbers:
- Developed by more than 100 security researchers and practitioners, the list identifies the most critical risks facing autonomous AI systems in production today.
- The two principles work together, and every risk in the Top 10 maps back to a failure in one or both.
Questions worth separating out
Q: How should security teams govern AI agents that can use tools across production systems?
A: Treat the agent as a distinct identity with task-scoped access, not as an extension of the human who invoked it.
Q: Why do AI agents create more risk than traditional automation jobs?
A: Traditional automation follows predefined rules and timing, while an agent can choose actions, combine tools, and decide when to act.
Q: What breaks when agents inherit user credentials or shared service accounts?
A: You lose meaningful separation between user intent, machine action, and accountability.
Practitioner guidance
- Separate agent identities from human sessions Issue managed identities for agents instead of borrowing the user's session or reusing a broad shared service account.
- Add policy checks to every tool invocation Apply authorization and input validation at the moment the agent calls a tool, especially where a database, file writer, email sender, or MCP server is involved.
- Log agent identity, user intent, and tool sequence together Capture which agent acted, which human approved it, and the full ordered chain of tool calls.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The per-risk breakdown of all ten OWASP agentic application categories, including the exact failure patterns tied to each one.
- The tool-level control examples for MCP, prompt inputs, memory stores, and generated code that implementation teams can map into policy.
- The article's own examples of how WorkOS AuthKit and FGA are positioned for identity and authorization in agentic systems.
- The practical distinctions between RBAC, ABAC, ReBAC, and sender-constrained tokens in agent workflows.
👉 Read WorkOS's analysis of the OWASP Top 10 for agentic applications →
AI agent identity abuse: what IAM teams need to change now?
Explore further
06/06/2026 11:59 am
Least agency is the governance control plane for agentic AI. The article is right to treat least agency as the agentic extension of least privilege, because the core failure is not just access scope but the freedom to act on that access without review. In practice, that shifts identity governance from entitlement design to runtime decision containment. Teams that still think in static permissions are already behind the control problem. Practitioner conclusion: treat agent decision freedom as a governed asset, not an implementation detail.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How can teams reduce the blast radius of a compromised AI agent?
A: Revoke resource-scoped access, isolate the agent in a sandbox, and remove its ability to chain privileged tools or delegate further actions. The goal is to break the sequence of action, not just disable the model. If the agent has its own identity, its access should be removable without affecting the user or other workloads.
👉 Read our full editorial: AI agent identity abuse exposes the limits of least privilege
