Notifications
Clear all
Topic starter
06/06/2026 11:08 am
TL;DR: AI agents that borrow user sessions or share broad service accounts inherit excessive privilege, widening the blast radius of prompt injection, tool misuse, and rogue behavior, according to WorkOS and the OWASP Top 10 for Agentic Applications. The practical shift is to treat agents as first-class principals with scoped, revocable credentials and per-tool authorization.
NHIMG editorial — based on content published by WorkOS: Securing agentic apps with scoped agent credentials and tool-level authorization
Questions worth separating out
Q: How should security teams give AI agents their own credentials?
A: Start by treating the agent as a separate principal with its own registration, token, and revocation path.
Q: Why do borrowed sessions create risk for AI agents?
A: Borrowed sessions give the agent the user's full entitlement set, which is usually far broader than the task requires.
Q: What breaks when AI agents share service accounts or API keys?
A: Shared credentials erase agent-level accountability and make revocation blunt.
Practitioner guidance
- Register each agent as a separate principal Issue per-agent credentials instead of reusing the user's OAuth session or a shared service account.
- Enforce default-deny tool mappings Build a permission map for every tool your agents can call, and reject any tool that does not have an explicit authorization rule.
- Separate user authorization from agent authority Let the human approve the task, but do not transfer the human's entire session to the agent.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Implementation patterns for authorization code with PKCE in user-authorized agent flows
- Middleware examples for validating every tool invocation at the MCP server boundary
- Client Credentials setup for machine-to-machine agents, including revocation handling
- Step-by-step migration guidance for moving from borrowed sessions to scoped agent identities
👉 Read WorkOS's guide to scoped credentials for AI agents →
AI agent credentials and privilege abuse: what IAM teams need to know?
Explore further
06/06/2026 11:45 am
Agent identity and privilege abuse is the core control problem in agentic apps. When an AI agent borrows a human session or a shared service account, the system no longer knows whether a tool call reflects human intent or runtime agent behaviour. That breaks least privilege at the point where execution happens, not just at login. The implication is that agent identity must be governed as its own subject in IAM and NHI programmes, not folded into user access.
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.
- That matters because only 44% of organisations say they have implemented any policies to govern AI agents, leaving most deployments with scope control but no formal governance baseline.
A question worth separating out:
Q: Who is accountable when an AI agent takes an unauthorized action?
A: Accountability depends on the authorization chain, not just the final action. The human who approved the task, the agent identity that executed it, and the policy that allowed the tool call all matter. If your logs cannot reconstruct that chain, your governance model is incomplete and your incident response will be slow.
👉 Read our full editorial: Scoped credentials for AI agents cut identity and privilege abuse
