May 2026 Summaries

Developers are increasingly turning to AI assistants like Claude for guidance, reducing the reliance on traditional documentation, which often involves cumbersome context-switching between various tools. This shift highlights the importance of integrating developer tools into AI assistant marketplaces, where they can be easily accessed and utilized through natural language commands. WorkOS has capitalized on this trend by making its skills available in Claude's plugin marketplace, allowing developers to manage identity, authentication, and directory sync resources conversationally, without needing to code or navigate complex dashboards. This approach simplifies multi-step tasks, reducing cognitive overhead and enabling real-time error feedback, thus improving developer experience. The trend suggests a broader movement of developer tools toward AI integration as a primary distribution method, emphasizing the need for tools to be discoverable and operable within AI-driven interactions to maintain relevance and effectiveness in developer workflows.

The described process focuses on using oagen, a framework designed for generating SDKs from OpenAPI specifications, which aims to address issues of drift and inconsistency in codebases by treating the generation of SDKs as a compilation problem. Unlike traditional OpenAPI tools, oagen offers a framework for building custom generators, providing developers with full control over the generated output through user-defined emitter code. It uses a typed intermediate representation (IR) as a stable contract between the parser and emitters, ensuring consistency and reducing redundancy across different language outputs. The tutorial illustrates building a Python SDK generator, detailing each step from parsing the OpenAPI spec to creating emitter functions that handle models, enums, services, and client classes. The architecture allows for flexibility and extensibility, enabling emitters to adapt easily to changes in the API specification while maintaining a consistent SDK interface. The approach leverages TypeScript's type system to ensure comprehensive handling of all possible data types, preventing runtime errors. The framework also supports testing with fixture specs and offers a diff command to track API changes, which can facilitate the management of breaking changes without forcing immediate updates on SDK users.

Auth.md is an open protocol introduced to simplify how agents register for services on behalf of users, requiring only a single Markdown file at a specified endpoint on a service's domain, without the need for proprietary SDKs or registries. Within a week of its announcement, several companies, including NanoGPT, Webclaw, Headless Domains, and Nate Davis, implemented the protocol, showcasing its practical application and ease of adoption in real-world scenarios. The protocol leverages existing OAuth standards, enabling agents to automatically discover and authenticate services, thereby enhancing the agentic web infrastructure by allowing seamless integration without additional barriers. The initiative has been backed by key industry players like Firecrawl and Cloudflare, and its significance is recognized as a milestone for the evolving web ecosystem centered around agent interactions. The straightforward approach of publishing the necessary endpoints and metadata has been praised for its simplicity, and further adoption is encouraged by the protocol's open nature and minimal implementation requirements.

TanStack Start is a full-stack React framework that uniquely emphasizes server functions as the primary security boundary rather than routes, unlike other frameworks like React Router or Next.js. Its authentication system is built around server functions, beforeLoad guards, sessions, and middleware, forming a comprehensive security model. Server functions created with createServerFn act as RPC endpoints, making it crucial to enforce authentication within these functions. Middleware offers a streamlined way to apply authentication across multiple server functions. Sessions are managed using vinxi/http, storing encrypted data in cookies. The framework supports a double-guard pattern, with beforeLoad protecting the user experience and middleware securing server functions. Moreover, TanStack Start's type system enhances compile-time safety, reducing auth-related bugs. Developers can choose between self-managed authentication using server functions and session cookies, or opt for integrations with libraries like Better Auth or Auth.js, or even managed providers such as WorkOS for enterprise-level features. Security practices include enforcing authentication on server functions, input validation, and avoiding user enumeration vulnerabilities. Ultimately, TanStack Start offers a flexible yet robust authentication model tailored to meet varying application needs.

WorkOS has released an updated set of migration guides to assist organizations transitioning their authentication systems when scaling beyond 200,000 users, where traditional methods often fail. The refreshed guides focus on key areas such as the CLI-first import workflow, transparent proxy for large SSO fleets, webhook disable sequencing, and feature-flag-based rollout. The CLI, now the primary import tool, allows for resumable, batched imports, ensuring no data loss or duplication during migration, and adapts to various source providers like Auth0, Firebase, and Cognito. For SSO migrations, the strategy depends on the number of connections, with fewer than 15 using the Admin Portal and more than 15 adopting a transparent proxy approach to minimize IT coordination. Webhook disable sequencing is crucial to avoid overwhelming systems with queued events once migrations are completed. The use of feature flags enables a gradual rollout, allowing for testing and mitigation of any issues before fully transitioning to WorkOS. The entire process is designed to be replicable and scalable, providing a comprehensive solution for large-scale authentication migrations.

The acquisition of Stainless by Anthropic has prompted discussions among developer teams about the potential impact on SDK generation, emphasizing the importance of having control over their own tools. Anthropic plans to wind down hosted Stainless products, leading to concerns about vendor dependency for SDK generation, a complex process requiring precise handling of resources, retries, authentication, and error management across multiple programming languages. Alternatives to Stainless include OpenAPI Generator, Speakeasy, and Fern, each offering different levels of customization, output quality, and management. However, the open-source framework oagen is gaining attention for its ability to create custom SDK generators from OpenAPI specs, allowing teams to maintain ownership and ensure idiomatic output across languages. oagen requires more initial effort as it provides a framework rather than a turnkey solution, but it offers long-term stability and independence from vendor constraints, making it an attractive option for teams prioritizing control over their SDK generation pipeline.

In September 2025, security researcher Johann Rehberger exposed a vulnerability termed Cross-Agent Privilege Escalation, which affects development environments where multiple AI agents share a codebase, allowing a compromised agent to alter another's configuration file, leading to a self-reinforcing cycle of compromised agents. This vulnerability, along with another attack called Agent Session Smuggling, highlights the security challenges in multi-agent systems that differ from single-agent systems due to transitive trust issues. The traditional trust model, where each relationship is bilateral, does not extend well to multi-agent systems where trust is inherited through delegation chains, leading to potential privilege escalations and security breaches. To mitigate these risks, authentication and authorization processes must be strengthened, with every inter-agent message being authenticated and validated to prevent unauthorized actions and cascading errors. Implementing strict delegation policies, validating inter-agent communications, and maintaining a comprehensive audit trail are essential strategies in securing such multi-agent architectures to prevent errors from compounding and ensure reliable operations.

Bearer tokens, while convenient, have a vulnerability in that they can be used by anyone who intercepts them, leading to potential security risks such as token leakage and replay attacks. To address this, sender-constraining techniques like Mutual TLS (mTLS) and Demonstrating Proof of Possession (DPoP) have been developed, which bind tokens to specific clients, rendering them useless if intercepted without the corresponding key material. mTLS operates at the transport layer by extending the TLS handshake to include client certificates, making it suitable for environments with existing mutual TLS requirements, although it is not ideal for browser-based applications due to its complexity and certificate management demands. DPoP, on the other hand, functions at the application layer using HTTP headers, allowing for broader deployability across different system architectures, including browsers, as it does not require changes to TLS termination. Token Binding, another proposed solution, failed to gain traction due to its dependency on widespread ecosystem support and its inability to be incrementally deployed, highlighting that practical adoption of security protocols often hinges more on deployability than cryptographic robustness. Consequently, mTLS is recommended for controlled backend environments, while DPoP is preferred for client-side applications where flexibility and ease of integration are necessary.

Enterprise Single Sign-On (SSO) is essential for B2B SaaS companies to secure significant contracts and meet IT team requirements, making the choice of SSO platform crucial due to the potential long-term integration and migration implications. A comprehensive guide evaluates seven leading SSO providers for B2B SaaS teams in 2026, each suited to different needs. WorkOS is tailored for fast enterprise deals with pre-built integrations and a self-serve admin portal, while Auth0 offers a wide feature set for teams with complex identity needs, though it requires significant engineering effort for customization. Clerk, focusing on speed for React and Next.js teams, is expanding its enterprise features but may need future migration, whereas Okta provides extensive capabilities for large enterprises but can be overwhelming for smaller teams. Microsoft Entra ID integrates well with Azure but lacks specific B2B SaaS tooling, and Ping Identity caters to regulated industries needing deployment flexibility. Keycloak offers open-source control but demands significant engineering resources for maintenance. The guide emphasizes that choosing a platform designed for enterprise use from the start can prevent growth disruptions and save engineering resources in the long run.

WorkOS, Auth0, and Clerk are prominent authentication and identity platforms for B2B SaaS products, each catering to different needs. WorkOS excels in serving enterprise-level clients by offering built-in features like Enterprise SSO, SCIM directory sync, audit logs, and a customizable admin portal, making it an ideal choice for companies targeting enterprise markets. Auth0, acquired by Okta, is a versatile platform capable of handling various authentication scenarios, including consumer identity and machine-to-machine authentication, but requires significant configuration for B2B multi-tenancy and can become costly due to its MAU-based pricing. Clerk, the latest entrant, focuses on providing an excellent developer experience with its pre-built UI components and integrations, particularly with Next.js and React, making it suitable for developer teams seeking quick implementation; however, it faces challenges in provider coverage and enterprise readiness. All three platforms have their pricing models, with WorkOS offering predictable costs based on connections and directory syncs, while Auth0 and Clerk use MAU-based pricing, which can escalate with larger user bases. For B2B SaaS teams, WorkOS is recommended for enterprises, Auth0 for those with complex identity needs, and Clerk for teams emphasizing developer speed and simplicity.

At MCP Night 4, Adi Singh, co-founder of AgentMail, demonstrated a novel solution for AI agents to autonomously sign up for email addresses, positioning email as a crucial identity layer for agents. During the demo, Singh showcased an AI agent obtaining an inbox from a single prompt, addressing a significant industry challenge of enabling agents to register for services without human intervention. AgentMail offers an API that allows agents to self-provision email addresses, thus avoiding traditional signup processes and human involvement. The solution includes safeguards such as an allow list and email sending limits to prevent misuse, while maintaining functionality for legitimate purposes like confirmations and receipts. Singh emphasized that email, an existing and widely-used protocol, can serve as a functional channel for agents instead of developing new infrastructures. The demonstration highlighted the importance of making existing systems accessible to non-human users, with practical use cases including autonomous service signups and transaction management. AgentMail's approach contrasts with current trends focused on creating new protocols, instead leveraging the longstanding infrastructure of email to enhance agent capabilities.

MCP Night 4 featured a panel discussion led by Michael Grinich from WorkOS, with insights from industry leaders like Brendan Irvine-Broque of Cloudflare, Claire Vo of Chat PRD, and David Cramer of Sentry, who explored the tangible shifts in the use of agent products over the past six months. The conversation highlighted a growing trend where engineering teams are increasingly embracing agent technologies, transitioning from skepticism to active implementation, with a focus on localized, file-based systems rather than traditional chat interfaces. David and Brendan emphasized the movement towards building custom solutions due to advancements in infrastructure, while Claire noted a shift in mindset among business leaders towards faster adoption of these technologies. The discussion also touched on the evolving nature of user and customer bases, where agents are becoming more prevalent, yet the importance of human decision-makers and payment remains unchanged. The panel predicted a future where agents contribute more to development processes, although full automation remains a distant goal, and highlighted the potential for hybrid interfaces combining generative UI and traditional elements to shape the design landscape in the coming years.

MCP Night's fourth event, themed "Agent Mode," highlighted the rapid evolution of software engineering, focusing on the rise of agents that autonomously write and manage code. Over the past year, coding with large language models has transformed from advanced autocomplete to systems capable of running independently and making decisions about software stacks. With companies like Ramp, Stripe, and WorkOS developing autonomous systems, the concept of agents as new users has emerged, necessitating new primitives for agent registration, as traditional signup methods are inadequate for these non-human entities. In response, WorkOS introduced Auth.md, a specification allowing agents to register and interact with services as first-class users, bypassing traditional barriers like CAPTCHA and email verification through a process involving Identity Assertion JWT Authorization Grants (ID Jags). During a live demo, the potential of Auth.md was showcased with an agent autonomously deploying a website using Cloudflare, emphasizing the need for open and adaptable registration frameworks as agents increasingly become significant consumers of software products.

Rhys Sullivan, founder of Executor, addressed a significant gap in agent capabilities regarding user interfaces during a demo at MCP Night 4. While agents can handle documentation and API calls effectively, they struggle to render product UIs, a gap Sullivan aims to close. He illustrated this with PostHog, demonstrating how agents can answer queries but fail to deliver the visual experience that UI components provide. Sullivan introduced a solution by allowing agents to generate UI through a tool called posthog.render UI, which can interpret data and render it in a meaningful way using components from PostHog's interface. This approach involves a TypeScript SDK that lets agents write code in a structured environment, improving reliability over ad-hoc tool calls. The strategy is adaptable to any product with an OpenAPI and component library, allowing agents to integrate deeply with products and enhance user interaction by rendering product UIs directly or through deep links.

At MCP Night 4, Evan Bacon, head of AI at Expo, presented a novel approach to mobile app development by integrating the iOS simulator with browser-based environments, specifically using npx serve-sim to run the simulator inside a browser. This method capitalizes on the strengths of coding agents that are more adept at web development due to advanced browser tooling and verification loops, which are often lacking in mobile app development. The in-browser simulator allows for real-time interaction and inspection, bridging the gap between web and mobile development by providing features like console log integration, element inspection, and even camera functionality through generative video or webcam use. This approach not only simplifies the development process of mobile apps but also enhances the agent's ability to interact with the app in a manner similar to web platforms, suggesting a shift in focus from protocol mastery to leveraging existing web-based verification loops for mobile app creation.

AgentCard, showcased by its founder Karen Serfaty during MCP Night 4, offers a novel approach to secure agent payments by utilizing one-time use virtual cards that self-destruct after a single transaction. The product aims to mitigate the risks associated with giving agents access to financial credentials by allowing users to issue these cards through an interface that both humans and agents can manage, ensuring that a human approves the transaction before any card is issued. During the live demo, Karen demonstrated the process by creating a card with a $1 limit, highlighting the importance of human approval in the workflow. She further illustrated the product’s capabilities by successfully completing a live purchase of an OpenAI subscription using a one-time card generated specifically for the transaction amount, emphasizing the system's security and practicality. AgentCard’s approach of scoping cards for single transactions and requiring human approval addresses common security concerns in agent payment systems, making it a promising tool for developers looking to integrate secure payment capabilities into their agent-driven applications.

OAuth 2.0 is a key framework for modern authorization, primarily involving the issuance of access tokens, but it faces challenges such as the confused deputy problem, where tokens can be misused across different resource servers. To address this, RFC 8707 introduces resource indicators that allow clients to specify the intended resource server for a token, enhancing security by binding tokens to specific audiences and filtering scopes accordingly. This approach helps prevent the misuse of tokens and scope ambiguity, essential for ensuring the principle of least privilege. Resource indicators require consistent URI usage and audience validation to be effective, with the Model Context Protocol (MCP) particularly benefiting from this setup as it involves AI agents interacting with multiple servers. Implementations like WorkOS MCP Auth simplify the process by integrating these requirements, ensuring secure and compliant OAuth deployments without needing to build the infrastructure from scratch.

With the rise of AI agents as a new class of users, traditional software design faces challenges as these agents interact with products differently than humans, requiring explicit instructions and structured data to function effectively. This shift necessitates the development of agent experience (AX) as a crucial design layer, ensuring that platforms and APIs are conducive to machine interactions. Successful products must prioritize API parity with user interfaces, structured error handling, idempotency, and comprehensive documentation to accommodate agent workflows. Furthermore, agent-powered products should provide transparency, reversible actions, clear scope boundaries, and calibrated confidence to build user trust and facilitate effective human-agent collaboration. The evolving landscape demands that companies treat agents as first-class consumers to maintain a competitive edge in an increasingly agent-driven world.

Managing OAuth 2.0 redirect URIs with Google can be particularly challenging for multi-tenant applications due to its strict exact-match requirements, which differ from more flexible approaches by other providers like Microsoft Entra ID and Okta. Google's policy necessitates the precise registration of each redirect URI, contrasting with Microsoft's allowance for wildcard subdomain URIs and Okta's programmatic configuration capabilities. This strictness presents operational hurdles, particularly during domain migrations or when managing numerous customer-specific domains, as failure to update URIs promptly can lead to redirect_uri_mismatch errors. Solutions such as using a central proxy pattern or provisioning separate OAuth clients per customer can alleviate some of these issues, although they introduce additional complexities. The importance of carefully planning migrations and treating redirect URI management as a key infrastructure concern is emphasized, as Google's stringent security model aims to prevent potential attacks via wildcard redirects, placing the onus on developers to ensure seamless integration and customer experience.

Transitioning from a homegrown Single Sign-On (SSO) solution to WorkOS aims to simplify and streamline the process of managing SAML and OAuth/OIDC integrations, reducing maintenance burdens and enhancing reliability. This guide provides a step-by-step approach for organizations to migrate their existing SSO systems, whether they have fewer than 15 connections or a larger number, by either reconfiguring each connection individually or using a proxy method to facilitate incremental migration. It emphasizes the importance of auditing current setups, documenting configurations, and choosing the appropriate migration path based on the number of connections. For smaller setups, direct reconfiguration is suggested, while the proxy approach is recommended for larger systems to avoid customer-side IdP changes. The guide details the technical implementation steps, such as setting up callback and initiation endpoints, creating organizations in WorkOS, and using the Admin Portal for IT admin self-service. It addresses handling connections that require customer reconfiguration and outlines a decommissioning strategy for the old SSO implementation once all connections are successfully migrated. Ultimately, adopting WorkOS is presented as a means to enhance SSO reliability, reduce maintenance, and provide additional features like managed certificate renewal, error handling, and observability through the Events API.

Auth.md is an open protocol designed to streamline the process of agents registering for services on behalf of users without human intervention, addressing the limitations of traditional OAuth flows and bespoke endpoints. It involves a plain Markdown document hosted on a service's domain, providing a structured guide that agents can parse to navigate registration steps, from fetching resource metadata to handling credential usage and errors. Auth.md introduces a protocol with specific HTTP endpoints that agents use to register and authenticate, extending existing standards like RFC 9728 and OIDC, while avoiding the need for new cryptographic methods or key distribution. It supports two registration flows: Agent Verified, where a trusted platform signs an ID-JAG to assert user identity, and User Claimed, where users provide a one-time password to bind credentials. By utilizing auth.md, developers can enable agents to interface with their services efficiently, promoting scalability and interoperability without complex integrations or vendor lock-ins.

Bearer tokens have long been a staple in web authorization due to their simplicity, allowing access to anyone possessing them, but this simplicity comes with the risk of unauthorized use if the token is leaked. Sender-constraining tokens address this vulnerability by binding tokens to specific cryptographic keys, ensuring that possession alone isn't sufficient for access. Two main standards exemplify this approach: DPoP (Demonstrating Proof of Possession) and mTLS (Mutual TLS). DPoP, defined in RFC 9449, integrates key management into OAuth 2.0 workflows, requiring clients to prove ownership of a private key with each request, making token replay and theft ineffective. mTLS, on the other hand, leverages the TLS layer to bind tokens to client certificates, providing robust security but requiring more complex infrastructure. While bearer tokens are suitable for low-risk environments and scenarios prioritizing simplicity, sender-constraining tokens are crucial in contexts where tokens cross trust boundaries or are used in regulated industries. For most teams, implementing DPoP is a practical choice due to its compatibility with existing HTTPS protocols and support from major identity providers. As security requirements evolve, the choice between bearer and sender-constraining tokens hinges on the specific needs for security versus operational simplicity.

The guide addresses the implementation of self-serve API key management for SaaS applications, using a fictional project management tool called "Runway" as an example. It emphasizes the necessity for secure, reliable API authentication, allowing users to generate, scope, and revoke their own API keys, as well as providing admins with oversight of active keys. The guide discusses the choice between user-scoped and organization-scoped keys, detailing when each is appropriate depending on the use case, and introduces WorkOS as a solution for handling the backend complexities of API key management. It explains how to configure permissions, integrate an API keys widget into user settings pages, and use WorkOS to validate API keys on backend routes, ensuring that keys carry only the permissions explicitly assigned to them. The process includes setting up permissions through the WorkOS dashboard, embedding the API keys widget, protecting API routes, and audit logging key lifecycle events. By following the guide, users can implement a robust API key management system that supports both personal and shared integrations, maintaining security and ease of use.

The WorkOS Applied AI showcase highlighted the company's journey toward becoming an AI-native organization by embedding AI capabilities across various functions, rather than merely offering AI tools as a service. This transformation began with a small, skilled team tasked with identifying and quickly addressing high-impact problems, which led to successful projects like a Slack chatbot and a chat platform for sales call transcripts. The showcase featured innovative projects such as the "wow" internal CLI, facilitating app development for non-technical users, and "Horizon," a code factory using Claude Remote Routines for efficient code management. Additionally, "Case," a TypeScript state machine with specialized agents, was discussed, emphasizing the importance of creating systems that ensure reliability over trustworthiness. "Wallaby," a GTM intelligence tool, and "BlogBot," an internal system for content generation and feedback loops, were also demonstrated, illustrating how AI can streamline workflows and improve productivity. Overall, the showcase underscored the company's commitment to integrating AI deeply into its operations, encouraging employees to continually explore new possibilities and inviting potential hires to join their innovative efforts.

Keycloak introduced an experimental SCIM Realm API in version 26.4, providing a way for Identity Providers (IdPs) to push users and groups into a Keycloak realm, but it comes with limitations and is not yet ready for full production use. This API enables basic SCIM 2.0 operations such as CRUD on users and groups, filtering, and pagination, while lacking support for features like bulk operations, custom attributes, and a SCIM-specific authorization model. Although the release is validated against Microsoft Entra, it misses broader IdP compatibility, multi-tenancy, and organization support, which are essential for broader B2B use cases. The WorkOS Directory Sync service, in contrast, offers a more comprehensive SCIM solution that normalizes IdP variations and supports multi-tenancy, custom attributes, and a wider range of IdPs, making it suitable for production across diverse environments. Keycloak's API mainly serves teams using Keycloak as an identity store and is not suited for applications needing extensive IdP support or custom schema capabilities.

Multi-tenant session management in B2B applications involves complexities beyond single-tenant systems, primarily focusing on how user sessions interact when switching between different organizational contexts. Two main patterns are explored: the session-per-org model, where each organization switch ends one session and starts another, ensuring that session tokens are specific to each organization and thus secure, and the org switching within a single session model, which allows for a single long-lived session with dynamic organization switching, although this places the security burden on application code rather than credentials. Effective multi-tenant management necessitates careful token scoping, refresh token rotation with reuse detection, per-tenant timeout policies, and data layer enforcement of tenant isolation to prevent cross-tenant data leaks. The complexities extend to managing multi-device sessions and ensuring secure transport layers, with additional considerations for tenants with compliance requirements, such as using server-side session storage. Tools like WorkOS can simplify token management, though the application must still rigorously handle the query layer to maintain tenant isolation.

Just-in-Time (JIT) provisioning is an efficient method for automating user account creation within single sign-on (SSO) enabled applications, eliminating the need for manual intervention at the moment of first login. This approach leverages identity data from SAML assertions or OIDC tokens, allowing service providers to instantly create user accounts with attributes such as name, email, and role, provided by the identity provider (IdP). While JIT simplifies onboarding by ensuring new users have immediate access to necessary tools, it does not handle deprovisioning, requiring additional solutions like SCIM for complete lifecycle management. SCIM complements JIT by offering proactive account management, ensuring timely deactivation and attribute updates without waiting for a login event. When combined, JIT and SCIM provide a comprehensive identity management strategy, balancing the quick setup of JIT with SCIM's robust data synchronization and security compliance capabilities.

Exploring the intricacies of Single Sign-On (SSO) systems, the text presents a three-pronged perspective on how an identity provider like Okta functions. From the employee's viewpoint, using SSO simplifies access to tools like Zoom as it pre-fills profile information, highlighting the behind-the-scenes setup by IT admins who register applications and manage access centrally, reducing the complexity of individual app management. The IT admin's role involves selecting an identity provider and configuring applications, streamlining the process of granting or revoking access across multiple platforms with ease, while developers face the challenge of integrating SSO to accommodate enterprise clients, often navigating the varied standards and protocols of different identity providers. WorkOS is introduced as a solution to mitigate the complexity of supporting multiple providers, allowing developers to focus on product development rather than the idiosyncrasies of identity management. The text underscores the dynamic nature of understanding SSO systems, acknowledging that the initial model is a starting point for deeper exploration into the technicalities of identity management.

B2B SaaS products typically begin with basic roles like admin and member, but as customer demands grow for more granular access controls, the authorization model becomes increasingly complex and difficult to manage. This complexity often manifests in four stages: flat roles, permission flags, role explosion, and patched RBAC, making it challenging to update access logic and onboard enterprise customers. To address this, the guide suggests building a scalable authorization model from the start, using WorkOS RBAC for organization-level access and WorkOS FGA for resource-specific control. By employing resource hierarchy with FGA, roles can be assigned at specific nodes in a resource tree, allowing for precise access without creating numerous custom roles. This hierarchical approach ensures permissions flow down the hierarchy, providing comprehensive control while maintaining efficiency. The model integrates with identity providers for automated role assignments and offers a two-layer enforcement strategy: JWT for organization-wide access and API calls for resource-level permissions. This setup allows for incremental adoption, starting with RBAC and extending to FGA as needed, supporting scalability without the need for a complete rewrite.

Client-Initiated Backchannel Authentication (CIBA), as outlined in RFC 9126, addresses the challenge of obtaining human approval for sensitive actions initiated by autonomous AI agents, without requiring the human and agent to be in the same session. This OAuth 2.0 extension separates the service requester from the authenticator, allowing the authorization server to notify the user through out-of-band channels like push notifications or emails, and to await their response, thereby enhancing security and control over autonomous operations. CIBA's implementation involves sending a backchannel authentication request to the authorization server, which then notifies the user to approve or deny the requested action. The agent can receive the user's decision through polling, ping mode, or push mode, depending on the architecture. This system ensures that sensitive actions require explicit human sign-off, reducing risks associated with autonomous decisions and ensuring that even when a user is not directly engaged with the agent, the necessary approvals are sought and logged, creating a clear audit trail of authorizations.

Claude Day at WorkOS was an internal hackathon designed to empower non-technical team members by having them lead in tool development, assisted by technical counterparts with minimal setup time, thanks to pre-built scaffolding. The event paired 39 teams, each consisting of a developer, a non-technical teammate, and an AI engineer, to create AI-driven internal tools that addressed real work challenges, resulting in a diverse range of practical applications like Slack message filters and customer activity dashboards. The hackathon's success was attributed to the strategic decision to minimize initial technical barriers and emphasize non-engineers' problem-solving roles, which fostered a sense of ownership and learning, particularly in understanding technical stacks and utilizing AI tools like Claude effectively. Participants learned valuable lessons, such as the importance of persistence, rethinking coding as self-service tool building, and leveraging AI as a translator, ultimately leading to a company-wide realization of their capability to develop functional tools.

As AI agents increasingly interact with APIs and perform tasks that involve mutating records and chaining tool calls, the challenge of determining the appropriate credential for these agents becomes significant, especially in B2B workflows. Traditional authentication methods differentiate between human users, who receive sessions and user-scoped tokens, and machines, which use client credentials and short-lived JWTs. However, AI agents, which act on behalf of users but have different lifecycles and operational scopes, disrupt this binary system. The article explores three scenarios for agentic workflows: personal agents acting on behalf of individual users, shared agents serving organization-wide needs, and backend agents functioning as services. Each scenario requires different credential primitives: user-scoped API keys for personal agents, org-scoped API keys with permission scoping for shared agents, and M2M Applications issuing short-lived JWTs for backend agents. WorkOS provides a unified authorization framework that supports these scenarios, emphasizing the importance of careful credential storage and management to prevent security breaches.

In January 2026, Merlin Kafka and Lewis Blackwood founded Rex, a company aiming to automate tedious and manual operational finance tasks for enterprise finance teams by using AI agents to handle accounts receivable and payable operations. Quickly gaining traction, Rex won first place in the Vercel AI Accelerator, securing investment from Vercel Ventures and demonstrating readiness to sell to large enterprises like Boeing and Walmart. The company prioritized robust security and authentication measures from the start, utilizing WorkOS for enterprise-grade authentication services such as SSO, SCIM provisioning, and passwordless authentication, which facilitated swift implementation and avoided procurement delays. The accelerator program not only provided networking opportunities and access to expert sessions but also aligned perfectly with Rex's existing tech stack, further enhancing their enterprise-readiness. As Rex emerges from stealth mode, they continue to expand their enterprise pipeline, leveraging the foundations built during the accelerator to meet the stringent security expectations of large organizations and differentiate themselves through a focus on good design and user experience.

AI agents are becoming critical infrastructure in various systems, handling tasks like support triage, deployments, payments, and cross-system coordination, yet they often lack proper security measures. The existing security frameworks, such as OAuth and RBAC, were designed for deterministic software and human users, not for AI agents that generate their own intent and act at runtime. This guide addresses the security challenges posed by AI agents, providing backend, platform, and security engineers the tools to secure agentic systems. It explains how to establish agent identity, authenticate without user sessions, enforce precise authorization, manage delegation chains, and counter new threats like cross-agent privilege escalation and session smuggling. The guide emphasizes treating agents as first-class principals with unique identities and scoped credentials, while also underscoring the importance of fine-grained authorization that considers both agent and user permissions. It critiques common anti-patterns in agent security, like shared service accounts and static API keys, and proposes solutions like dynamic credential issuance and tool-level scoping. The guide concludes with a comprehensive checklist for securing agentic systems, covering identity management, authorization, multi-agent delegation, audit practices, and incident response, while advocating for platforms like WorkOS to streamline these processes.

Setting up SAML Single Sign-On (SSO) with Microsoft Entra ID often encounters challenges, with numerous potential points of failure between the Entra admin center, application configurations, and IT administration, leading to common errors that hinder successful authentication. The text outlines several frequent errors such as reply URL mismatches, user assignment issues, invalid SAML requests, wrong binding types, expired signing certificates, NameID format mismatches, and application identification problems, providing detailed explanations and solutions for each. Developers and IT admins can utilize tools like the My Apps Secure Sign-in Extension and SAML Tracer to capture and troubleshoot SAML requests and responses. The process of certificate rotation is highlighted as a critical area requiring careful coordination to avoid disruptions in SSO functionality. WorkOS is presented as a solution that simplifies managing these errors by assisting with configuration mismatches, monitoring certificate expirations, and handling SAML exchanges, thereby reducing the likelihood of setup errors and improving the reliability of SAML implementations.

WorkOS builds an identity and access management platform for startups and AI companies, emphasizing a unique product engineering culture that leverages AI to enhance the project lifecycle, from customer feedback synthesis to solution exploration and direct production work. A significant development is the Fine-Grained Authorization (FGA) feature, which uses a relationship graph to determine permissions, allowing for more dynamic and accurate design iterations through a WYSIWYG editor. The design process at WorkOS incorporates AI to create working prototypes in production, enabling earlier, more accurate feedback and decision validation against real data. This approach shifts the focus from static mockups to dynamic, production-ready designs that consider edge cases and performance, allowing designers to close numerous UI issues independently. As the platform evolves, WorkOS expands its design considerations beyond traditional interfaces to include APIs, CLIs, and agentic experiences, accommodating a broader user base that now includes agents capable of technical translation. The design team is empowered to innovate and apply their craft across various platform aspects, welcoming new designers to contribute to this evolving landscape.

PHP plays a crucial role in powering web applications, and its integration with JSON Web Tokens (JWT) is notably streamlined through the dominance of a single library, firebase/php-jwt. This library leverages PHP's native OpenSSL extension and aligns with PSR standards, making it suitable for various PHP frameworks like Laravel and Symfony. The guide provides comprehensive insights into handling JWTs in PHP, covering topics like HS256 and RS256 verification, integration with Laravel middleware, and addressing common challenges such as token inspection using tools like the WorkOS JWT Debugger. JWTs are a secure method for transmitting information, typically used to convey user identities and permissions, and are structured with a header, payload, and signature to ensure integrity. The firebase/php-jwt library supports JWT creation, verification, and key management through JWKS, with the CachedKeySet class facilitating key rotation and caching. The guide emphasizes best practices such as signature verification, algorithm enforcement, and the importance of using a JWKS endpoint for key validation. For production, leveraging WorkOS can enhance authentication flows by providing an API for enterprise-ready features like Single Sign-On and SCIM provisioning, allowing developers to focus on building robust applications without the overhead of managing a complex authentication stack.

A comprehensive tutorial outlines how to integrate Single Sign-On (SSO) into Command Line Interfaces (CLIs) using OAuth 2.0 flows—Device Code and Authorization Code with PKCE. These flows delegate authentication to a browser, circumventing the need for direct SAML or OIDC support within the CLI, thus enabling compatibility with various identity providers like Okta and Google Workspace. The tutorial demonstrates implementation in TypeScript against AuthKit, detailing the setup, configuration, and code necessary to achieve secure authorization while maintaining user-friendly experiences across different environments. The PKCE flow is recommended for phishing resistance and efficiency, while the Device Code flow is essential for headless environments. The integration ensures that the CLI can pass enterprise security reviews by handling authentication seamlessly, offering both flows to accommodate different usage scenarios, and suggesting best practices for token storage and management. It also highlights how AuthKit simplifies complex SSO processes, allowing the CLI to support multiple identity providers without additional code changes.

When designing command-line interfaces (CLIs), choosing between Authorization Code with PKCE and OAuth 2.0 Device Authorization Grant is crucial for handling authentication, as both delegate it to a browser and yield OAuth access and refresh tokens. PKCE, suited for native apps and CLIs running on the user's machine, involves setting up a loopback server and is favored for its security, particularly against phishing attacks, as it requires a local browser to complete the flow. On the other hand, the Device Code flow, ideal for environments without a local browser like SSH sessions and containers, involves polling and is more vulnerable to phishing, prompting some enterprises like Microsoft to block it. The recommendation for CLIs, especially those used in enterprise environments, is to support both methods: default to PKCE for its enhanced security while keeping the Device Code flow available as a fallback through an explicit flag. This dual-approach ensures compatibility and maintains security standards across various use cases and environments.

The text outlines a sophisticated approach to generating Software Development Kits (SDKs) for APIs using a custom generation pipeline based on a single OpenAPI specification. The process involves two open-source repositories: oagen, which generates a structured intermediate representation (IR) of the API, and oagen-emitters, which uses the IR to produce idiomatic code for multiple programming languages. This method addresses the challenges of maintaining consistency across multiple SDKs by automating the generation process and leveraging AI, specifically Claude, to assist in language-specific code translation and adherence to conventions. The use of a centralized OpenAPI spec ensures that all SDKs are aligned with the latest API updates, reducing manual work and allowing engineers to focus on more complex tasks. This approach not only standardizes SDK quality and consistency but also facilitates easier integration and maintenance, making it particularly beneficial for developers and AI coding agents who rely on these SDKs to interface with APIs. The text also highlights that both oagen and oagen-emitters are open-source, encouraging others facing similar challenges to explore this method.

JSON Web Tokens (JWTs) are widely used for representing claims between parties in distributed systems due to their compact and self-contained nature, but they come with potential pitfalls that can weaken authentication systems if misused. The guide emphasizes the importance of selecting the right algorithms, validating claims, handling expiration and revocation, and securely storing tokens on the client side. It advises against using the "none" algorithm, warns about algorithm confusion attacks, and stresses the necessity of distinguishing between signed and encrypted tokens. Key management is crucial, including the use of long, random keys stored in a secrets manager and regular key rotation. The guide also highlights the importance of short-lived access tokens, refresh token rotation, and avoiding storing sensitive data in JWT payloads. It warns against common mistakes like trusting the algorithm header, skipping audience validation, or treating JWT size casually. Ultimately, JWTs should be treated as verifiable claims with a short shelf life, with thorough validation and secure key management practices in place.

In June 2025, researchers at Aim Security revealed EchoLeak, a zero-click vulnerability in Microsoft 365 Copilot that allowed remote attackers to steal confidential data through hidden instructions in documents or emails, which Copilot processed to query internal files and exfiltrate results. This incident highlighted the broader risk of prompt injection in agentic systems, where attackers can manipulate AI agents into performing unauthorized actions beyond merely outputting text, such as querying databases or executing code. Unlike chatbots, agents have multiple output channels, increasing the attack surface. EchoLeak demonstrated the challenge of defending against indirect injection attacks, where attackers embed malicious instructions in content the agent is meant to process, posing a threat due to the trusted nature of such input channels. This vulnerability in agentic systems is further compounded by the ability of injected agents to propagate instructions across multi-agent systems, potentially leading to system-wide compromises. A meta-analysis found high success rates of adaptive attacks against best defenses, emphasizing the need for a layered defense strategy that contains rather than completely prevents prompt injection. Key defensive measures include scoped credentials, supply chain verification, invocation policy, and input-level defenses, all aimed at limiting the attack's blast radius and ensuring that any successful injection remains a contained incident.

The complex process of maintaining consistent SDKs across multiple programming languages has been streamlined by developing a generation pipeline that leverages a single OpenAPI specification, supported by AI for language-specific translations. This approach alleviates repetitive engineering work and prevents divergence among SDKs by using two open-source tools, oagen and oagen-emitters, which parse the OpenAPI spec into a stable intermediate representation (IR) and emit idiomatic code for various target languages. The AI, specifically configured for this context, assists in translating the IR to ensure adherence to language-specific conventions and consistency across SDKs without the need for manual intervention. This method not only enhances SDK quality and consistency but also allows developers to focus on more complex tasks, while the comprehensive documentation and structured data models facilitate both human and AI understanding and integration of the API into different applications.

Horizon is an in-house autonomous code factory developed to enhance software development by automating task orchestration, which traditionally involves human intervention. Inspired by background agent systems like Ramp's Inspect and Stripe's Minions, Horizon is designed to run continuous, event-driven AI coding sessions that manage complex projects end-to-end in a cloud sandbox. It aims to free up human engineers for strategic tasks like requirements gathering and user acceptance testing, while agents handle implementation details and verification processes. The system integrates tightly with existing WorkOS features for security and context management, and utilizes tools like GitHub and Cloudflare to maintain a secure, scalable environment. Horizon is built on a modular architecture, allowing it to evolve with technological advances, and it emphasizes a collaborative workflow where agents and humans work in a feedback loop to improve the platform's efficiency and reliability continuously. The initiative is part of a long-term investment to create a compounding system where each run not only delivers work but also feeds improvements back, aiming for a future where writing code becomes the simplest part of the development process.

B2B SaaS companies often face the challenge of meeting enterprise readiness requirements when large contracts with substantial security expectations arise. These requirements include implementing features such as single sign-on (SSO), multi-factor authentication (MFA), role-based access control (RBAC), and audit logs to satisfy large organizations' demands for data security and management. As the AI era accelerates the timeline from launch to enterprise deals, the need for these capabilities has increased, particularly with the advent of autonomous AI agents that necessitate advanced authentication and authorization protocols. WorkOS offers a solution to this challenge by providing APIs and components that simplify the integration of these enterprise features, allowing companies to focus on their core product while ensuring they meet the compliance standards required by enterprise clients. This integration has enabled companies like OpenAI and Vercel to quickly secure large contracts without dedicating extensive time and resources to developing these capabilities in-house.

The Model Context Protocol (MCP) has emerged as the standard interface for AI agents to connect with tools and data, gaining rapid adoption by major tech companies like OpenAI, Google, and Microsoft. MCP requires specific OAuth 2.1 features like Dynamic Client Registration and Protected Resource Metadata, which traditional OAuth providers often lack. Consequently, a new wave of authentication providers has developed products tailored to MCP's unique needs, offering dynamic client registration, discovery endpoints, and seamless integration with MCP frameworks such as FastMCP and Cloudflare Workers. Among these, WorkOS stands out for its comprehensive support of the MCP specification and dual integration paths that allow teams to either adopt a full platform or overlay MCP-compliant OAuth flows on existing systems. Other notable providers include Auth0 by Okta, Stytch by Twilio, Cloudflare's open-source workers-oauth-provider, and Keycloak, each offering distinct advantages and trade-offs. WorkOS is particularly highlighted for its enterprise identity features, tool-level permissions, and independence from larger corporate agendas, making it a versatile choice for deploying MCP servers in production environments.

React Router v7 has evolved into a full-stack framework incorporating server-side rendering, loaders, actions, middleware, and session management, significantly altering how authentication is handled in React applications. With the merger of Remix, React Router now supports three modes: framework, data, and declarative, each offering different approaches to authentication architecture. Framework mode provides server-side authentication and is the most secure, resembling Remix's offerings, while data mode combines client-side routing with data loading, and declarative mode focuses on client-side token checks, offering the weakest security model. Authentication in React Router v7 relies on server-side session management using encrypted cookies, contrasting with previous client-side token storage practices. The guide emphasizes the importance of server-side loaders and actions for secure authentication, warns against client-side token storage due to security vulnerabilities, and suggests using middleware for session management across routes. It also introduces the potential of using managed authentication providers like WorkOS, which offer integrations specifically designed for React Router, ensuring robust security practices. The document underscores that authentication should be treated as critical infrastructure, encouraging developers to choose the approach that aligns with their application's future needs.

This practical guide details the process of building an MCP server that wraps an existing REST API, using a fictional service called Pantry as an example. The guide focuses on exposing a curated subset of REST API endpoints to an LLM agent through tools, resources, and prompts, with an emphasis on design decisions, such as which endpoints to expose and how to structure them. It covers project setup using Python with FastMCP, error handling strategies, and implementing OAuth-based authentication using AuthKit to secure the server. The guide emphasizes writing tool descriptions that are clear for the model, structuring returns with useful summaries, and using the MCP Inspector for testing. It provides best practices for integrating with clients and troubleshooting common issues, aiming to create a scalable and maintainable server that effectively serves user intents.

The System for Cross-domain Identity Management (SCIM) is an open standard designed to automate user provisioning between identity providers like Okta, Azure AD, and SailPoint, and service providers. It operates through a REST API and a JSON schema that represent users and groups, defined in RFC 7643 for core schema and RFC 7644 for protocol operations. SCIM uses a layered discovery model with three endpoints to determine server capabilities: ServiceProviderConfig, ResourceTypes, and Schemas. These endpoints inform clients about supported operations, the types of resources managed, and the attributes of each resource type. While Okta and Entra have unique approaches to using these endpoints, SailPoint and other mature clients might already be familiar with standard schemas. SCIM implementations can vary significantly across different identity providers, often requiring custom integrations that can be resource-intensive to maintain. WorkOS addresses this challenge by hosting SCIM servers to offer a unified API that supports various identity provider directories, allowing developers to focus on building their core products rather than managing SCIM integrations.

The intricate challenge of linking user identities between SSO and SCIM systems, known as the identity join problem, arises due to the lack of a reliable shared key between these systems. This problem becomes evident as naive solutions, like matching based on email or IDP ID, often fail under real-world conditions. The IDP ID, though seemingly a viable option, lacks uniqueness and stability, particularly when different identity providers or migrations are involved. Email matching also falls short due to issues like email reuse, duplicates, and format inconsistencies. A robust solution requires configurable linking identifiers with sensible defaults for most users and flexibility for unique cases. This approach involves enforcing uniqueness on linking attributes and providing IT admins and developers with tools to specify custom linking strategies. By acknowledging the distributed nature of enterprise identity systems and avoiding reliance on a universal identifier, organizations can achieve reliable identity joining, enabling features like just-in-time deprovisioning and unified user lifecycle management.

Blog Bot, an AI-driven blog publishing tool, was initially hindered by low adoption due to its separate custom web UI that required users to switch contexts and learn a new interface. To address this, the system was integrated into Slack, significantly boosting usage by allowing users to interact with it within the familiar environment of their existing workflows. This Slack-based version retains all original features, such as multi-pass drafting, image generation, and quality checks, and introduces new capabilities like cross-channel triggers and an emoji-based API call to streamline the blog drafting process. Cloudflare Workers facilitate the underlying infrastructure, enabling durable workflows that manage complex AI operations and external API interactions seamlessly. The system also includes a proposal feature that suggests potential blog topics based on company activities, and it employs various AI models to manage tasks like input classification, drafting, and editing. The development cycle is streamlined through a conversational interface that allows for quick iterations and testing directly within Slack. Overall, the tool emphasizes minimizing context-switching and interface learning curves, allowing users to focus on content creation while automating the technical aspects of blog publishing.