Notifications
Clear all
Topic starter
07/06/2026 9:21 pm
TL;DR: AI agents can query knowledge bases, act on sensitive APIs, and overstep intended boundaries if permissions are broad or poorly logged, according to WorkOS. The core issue is that existing IAM patterns still assume stable, human-paced access, while agentic workflows need scoped, revocable, and auditable delegation.
NHIMG editorial — based on content published by WorkOS: AI agent access control: How to manage permissions safely
Questions worth separating out
Q: How should security teams implement least privilege for AI agents?
A: Start by mapping each agent to a single business task, then define narrow roles and permissions that only cover the actions needed for that task.
Q: Why do AI agents complicate access governance for IAM teams?
A: AI agents complicate access governance because they act on behalf of users while also making runtime choices across tools and data sources.
Q: What do organisations get wrong about logging AI agent activity?
A: Many teams log that an agent ran, but not enough to explain what authority it used or which user initiated it.
Practitioner guidance
- Assign task-specific roles to every agent Create separate roles for support, analytics, finance, and operations agents, and remove any permission that is not required for the exact workflow.
- Replace static secrets with scoped OAuth flows Use short-lived, revocable tokens for agent sessions and define explicit OAuth scopes for each action the agent may perform.
- Log the full delegation chain for every action Capture the initiating user, the acting agent, the target resource, and the result in a single audit record so security and compliance teams can reconstruct what happened.
What's in the full article
WorkOS's full blog post covers the operational detail this post intentionally leaves for the source:
- Specific WorkOS configuration patterns for Connect, M2M, and AuthKit in agent workflows
- Code examples showing how to gate agent permissions with roles and permissions in application logic
- Audit log payload examples that capture actor, target, outcome, and context for compliance teams
- Implementation guidance for using OAuth 2.1 with MCP applications and existing auth stacks
👉 Read WorkOS's analysis of AI agent access control and permission management →
AI agent permissions and audit logs: are your controls keeping up?
Explore further
08/06/2026 9:15 am
AI agent access control is now an NHI governance problem, not just an application feature. When an agent can act on behalf of a user, it becomes a non-human identity that must be governed with the same discipline as service accounts and tokens. The article is right to focus on RBAC, OAuth, and logs, but the larger point is that uncontrolled agent permissions turn ordinary application design into identity risk. Practitioners should treat agent authority as part of the NHI control plane, not as a convenience layer.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows the issue is recurring rather than isolated.
A question worth separating out:
Q: Should organisations require human approval for high-risk agent actions?
A: Yes, but approval only works when the agent already has tightly scoped access. Human sign-off should be reserved for destructive or high-impact actions such as production changes, data exports, or permission updates. Otherwise, the approval step becomes a formality that masks excessive underlying privilege.
👉 Read our full editorial: AI agent access control and least privilege need stronger guardrails
