Notifications
Clear all
Topic starter
12/06/2026 9:25 pm
TL;DR: As enterprises deploy more AI agents, the central choice is shifting from runtime threat detection to the identity and authorization controls that keep agents inside intended bounds, according to WorkOS. For IAM teams, the real question is whether security is being bolted on after action or enforced before access is granted.
NHIMG editorial — based on content published by WorkOS: Aim Security vs WorkOS: Choosing the Right Agentic Security Platform
Questions worth separating out
Q: How should security teams govern AI agents that act on behalf of users?
A: Security teams should bind each AI agent to explicit identity, role, and resource scope so the agent cannot inherit broad application privileges.
Q: Why do AI agents complicate traditional access control models?
A: AI agents complicate access control because the same workflow may operate across multiple users, tenants, and data domains in a single session.
Q: What breaks when runtime detection is the main control for AI agent security?
A: What breaks is the assumption that access should be acceptable until suspicious behaviour appears.
Practitioner guidance
- Map agent identities to explicit task scopes Document which workflows are acting as users, which are acting as service identities, and which resources each one may reach.
- Separate prevention from detection in your control design Use runtime monitoring for alerting and containment, but require pre-approval of identity, token scope, and object-level permissions before an agent can touch sensitive systems.
- Test whether your authorisation model survives user-on-behalf-of workflows Run access tests where the same AI agent acts for different users, tenants, or business units, and verify that permissions do not drift upward across sessions.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Authentication and authorization implementation details for production AI applications
- WorkOS Fine-Grained Authorization examples for role, resource, and business-logic based permissions
- Developer integration notes for SAML SSO, OAuth 2.0, and enterprise identity provider connections
- Pricing and deployment context for teams evaluating the platform for production use
👉 Read WorkOS's analysis of agentic security platform trade-offs and AI agent authorization →
Agentic security platforms: are your controls catching the real failure mode?
Explore further
12/06/2026 11:29 pm
Agentic security is really an identity architecture problem, not a monitoring problem. Behavioural guardrails matter, but they sit too far downstream to define safe access. If an AI agent can authenticate too broadly or inherit permissions that exceed task scope, runtime detection is already behind the failure.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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: Who is accountable when an AI agent exceeds its intended access scope?
A: Accountability should sit with the team that defined the agent's identity, authorization model, and operational boundaries, not with the runtime alerting layer alone. Governance frameworks such as NIST AI Risk Management Framework and zero trust thinking both point to pre-activity control ownership. The key is to establish clear ownership before deployment.
👉 Read our full editorial: Agentic security platforms split between runtime detection and access control
