Notifications
Clear all
Topic starter
06/06/2026 11:15 am
TL;DR: App identity and agent tooling are converging as WorkOS’s March 31 update adds agent-facing CLI workflows, multiple-application identity separation, AuthKit analytics, and Pipes MCP session-scoped access for third-party data connections, according to WorkOS; the practical shift is that token lifetime, session scope, and application boundaries now matter as much as traditional sign-in flows when agents touch enterprise systems.
NHIMG editorial — what this means for AI and NHI governance
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.
- Only 44% have implemented any policies to govern AI agents, despite 92% agreeing that governing them is critical to enterprise security.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams govern AI agent access to third-party tools?
A: Security teams should make tool access session-scoped, tightly bound to a specific approval, and observable in audit logs.
Q: Why do multiple application identities matter for IAM governance?
A: Multiple application identities let teams assign separate client IDs, redirect URIs, and session lifetimes to different trust contexts while keeping the same users and organizations.
Q: What breaks when AI agents generate their own workflow implementations?
A: What breaks is the assumption that implementation can be reviewed after the fact without first governing the identity logic inside the artefact.
Practitioner guidance
- Map each agent-facing tool to a session boundary Document which MCP-connected resources are available only within a single approved session, and verify that access changes require a new decision point rather than silent continuation.
- Split application policies by trust context Use separate client IDs, redirect URIs, and session lifetimes for each application so shared users do not inherit one flattened policy surface across every app.
- Review agent-generated workflow code before deployment Put generated SSO, user management, and domain verification code through the same governance review you would use for other identity-sensitive production changes.
What's in the full announcement
WorkOS's full update covers the operational detail this post intentionally leaves for the source:
- How the WorkOS CLI supports agents fetching resources directly without dashboard dependency.
- The implementation details behind Pipes MCP session-scoped access and user approval changes.
- How multiple application support separates client IDs, redirect URIs, session policies, and credentials in practice.
- What Widget Skills change about app-native workflow generation and code ownership.
👉 Read WorkOS's update on agent CLI, Pipes MCP, and multi-app identity controls →
AI agent access controls in WorkOS CLI and Pipes MCP?
Explore further
06/06/2026 11:57 am
Session-limited tool access is becoming the right baseline for agent governance, but only if the session really bounds the actor. Pipes MCP reflects the broader move away from standing OAuth exposure and toward time-bounded access for agents. That is directionally aligned with NHI governance, but the control only works if the session cannot be silently extended into durable privilege through chained tool use. The practitioner conclusion is that session scope must be treated as a hard authorization boundary, not a convenience layer.
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, inappropriately sharing sensitive data, and revealing access credentials, 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: How do teams know whether ephemeral access is actually reducing risk?
A: Teams know it is working when the session boundary is the only place privilege exists, when tool permissions cannot outlive approval, and when audit logs show exactly what the agent touched before the session ended. If access expires but activity remains opaque, the risk has moved, not disappeared.
👉 Read our full editorial: WorkOS CLI and Pipes MCP shift identity control for AI agents
