Notifications
Clear all
Topic starter
06/06/2026 2:18 am
TL;DR: AI agents introduce an access control problem that conventional IAM was not built to handle because they choose tools, chain actions, and operate autonomously, according to WorkOS. The real governance shift is that identity assumptions built around fixed sessions, static scopes, and human-paced approvals collapse when an agent decides and acts at runtime.
NHIMG editorial — based on content published by WorkOS: Best practices for AI agent access control
Questions worth separating out
Q: How should security teams govern AI agents that act on behalf of users?
A: Treat the agent as a separate principal and preserve the user as a second principal in the authorization decision.
Q: Why do AI agents complicate least privilege in enterprise environments?
A: Because agents can choose tool sequences at runtime, a scope that looks narrow on paper may still permit dangerous chained actions.
Q: What breaks when AI agents rely on long-lived API keys?
A: Long-lived keys turn a single leaked secret into persistent authority, and agents create more places for that secret to leak through prompts, logs, cache layers, and tool outputs.
Practitioner guidance
- Issue separate agent principals Register each agent or deployment as its own service identity, then use delegation flows when it acts for a user so the audit trail preserves both principals.
- Narrow scopes to task-level capabilities Replace broad roles with verbs tied to specific resources, and put a policy-enforcing proxy in front of APIs that cannot express that granularity natively.
- Move approval out of the agent context Route destructive or irreversible actions through a channel the agent cannot forge, such as a separate authenticated UI or signed approval workflow.
What's in the full article
WorkOS' full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step pattern for issuing distinct agent identities and binding them to user delegation flows.
- Examples of capability-based scoping across real API patterns, including when a policy-enforcing proxy is needed.
- Implementation detail for policy-as-code, including runtime evaluation and testing in CI.
- Execution guidance for sandboxing browsing, code, and file editing with separate identities and egress controls.
👉 Read WorkOS' guidance on AI agent access control best practices →
AI agent access control: what IAM teams need to govern now?
Explore further
06/06/2026 3:54 am
AI agent access control is now a delegated-identity problem, not a traditional app-permission problem. The article correctly frames agents as principals that select tools and chain actions, which means authorization has to follow the decision loop rather than the screen flow. That is a different control model from human IAM, because the meaningful unit of governance is the runtime path, not the login event. Practitioners should treat delegation as the core design question, not an edge case.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slowly remediation can catch up to exposure.
A question worth separating out:
Q: How do security teams decide when an AI agent needs human approval?
A: Use approval for actions that are hard to reverse or have high blast radius, such as deleting records, sending external messages, or granting access. The approval must happen outside the agent's own context so injected instructions cannot fake it. That makes the human the final authorizer, not the model or tool chain.
👉 Read our full editorial: Best practices for AI agent access control in enterprise IAM
