Notifications
Clear all
Topic starter
07/06/2026 8:57 pm
TL;DR: AI agents can carry human identity context into workflows, but without SCIM, audit logs, and admin controls, enterprise authentication remains incomplete, according to WorkOS. The issue is not whether agents can act, but whether their actions are attributable, revocable, and governable at scale.
NHIMG editorial — based on content published by WorkOS: Clerk vs WorkOS, Agent Identity Meets Enterprise Authentication
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern AI agents that act on behalf of human users?
A: Treat the agent as part of the enterprise identity chain, not as a separate convenience feature.
Q: Why do agent identity features fail without SCIM and audit logs?
A: Because identity context alone does not manage the full lifecycle of access.
Q: What do security teams get wrong about AI agent authentication?
A: They often confuse prompt-level identity propagation with enterprise authentication.
Practitioner guidance
- Require lifecycle-linked agent revocation Tie every agent-enabled workflow to a directory-backed joiner, mover, and leaver process so access disappears when the human identity changes.
- Validate tamper-resistant audit coverage Confirm that every agent action produces logs that can be traced from human authorisation to the specific system action, with no reliance on application-only logging.
- Separate developer convenience from enterprise control Approve agent identity tooling only after it demonstrates SSO, admin self-service, fine-grained authorisation, and customer-managed directory connections.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Exact breakdown of the Agent Toolkit's identity claims and how they are injected into agent prompts and tool context
- Product-level discussion of SCIM, audit logs, admin portal, and fine-grained authorization features as the enterprise baseline
- Implementation context for teams deciding whether a developer-first auth platform can support production agent deployments
- The article's own comparison of Clerk's current roadmap against enterprise identity expectations
👉 Read WorkOS's analysis of Clerk vs enterprise authentication for AI agents →
Agent identity and enterprise auth: what teams are missing?
Explore further
08/06/2026 8:42 am
Agent identity is only a traceability layer unless it is anchored to enterprise authentication. Passing user claims into an AI workflow tells you who authorised the session, but it does not prove the platform can provision, constrain, or revoke access safely at scale. The governance problem is not the label on the agent, it is whether identity state can survive enterprise audit and lifecycle demands. Practitioners should evaluate agent features only in the context of the full authentication stack.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, 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 takes an unauthorised action?
A: Accountability should remain with the organisation that authorised the workflow and the identity team that defined the access boundaries. The technical answer must include a human-to-agent-to-action audit trail, because without that chain the organisation cannot show who approved the session, what scope existed, or when access was removed.
👉 Read our full editorial: Agent identity still depends on enterprise authentication foundations
