Uncategorized

Haven’t you heard? White-collar jobs are going away, decimated by AI. Waves of layoffs in the tech sector (most recently at Coinbase and Meta and Cisco) are said to presage what will soon come for all of us knowledge workers. But before you quit your job as a software developer or financial analyst—or tech journalist—and look to join the plumbers’ union, it’s worth considering today’s economic research on whether artificial intelligence has actually begun to devour white-collar work. The short answer is: No. Despite the warning by some of an imminent jobs apocalypse that will destroy much of if not most such work, or the rumblings about a “permanent underclass,” there’s scant evidence that AI has yet had any large-scale impact on the US labor market.  Analysis of the data gathered for the US Bureau of Labor Statistics (BLS) shows that the unemployment rate for the jobs potentially most affected by AI is actually lower than that for occupations less exposed to the technology. And, critically in the mind of economists, there are no signs that large numbers of people are shifting from jobs threatened by AI to supposedly safer ones, such as those involving mostly manual labor. While the current labor statistics don’t preclude a sudden job upheaval in the coming years, they do throw doubt on the inevitability of the doomsday scenarios and the pace at which they’d unfold. Everyone in the AI community, it seems, is predicting that the technology will soon wipe out jobs, and everyone, it also seems, knows some young wannabe workers who can’t find one. Perhaps we haven’t seen any major disruption in the labor market statistics yet, people often say, but just wait.  But maybe we should pay attention to what the data is showing us. And right now, the numbers paint a picture of a relatively stable labor market in which AI disruptions remain largely speculative. “It could be disruptive, but the data is telling us right now that disruption is not yet here, and we have time to plan.” “All of the available evidence to date suggests that AI’s impact on current labor market conditions is likely small right now,” says Erika McEntarfer, a labor economist who headed the BLS until President Trump fired her last fall after a jobs report that displeased the administration. (Not surprisingly, BLS reports of sluggish job growth have continued since her dismissal.) McEntarfer, who is now a fellow at the Stanford Institute for Economic Policy Research, says the relatively small impact that AI is having so far on today’s labor market “surprises many people, but it shouldn’t. What we know from history is that it takes time for innovations to work their way through changes in industries and changes in occupations. AI is unlikely to transform labor markets until it first transforms businesses.” McEntarfer points to US Census data showing that only one in five companies are using AI in any business function. “The data are a great reality check on the fear that AI will be enormously disruptive,” she says. “It could be. It likely will be disruptive, but the data is telling us right now that disruption is not yet here, and that we have time to plan.” Things ain’t great—but the question is why The US job market, to be sure, sucks for many, especially younger would-be workers. Unemployment rates for recent college graduates stand at around 5.6%, well above the level for all workers. It’s a rate not seen since the pandemic and the years immediately after the 2008 recession. Even more troubling is that hiring rates have been particularly dismal during the post-covid economy, a trend that hits hard at young people trying to enter the workforce. If you’re a recent college graduate and looking for a tech job, no one, it can seem, is hiring. There are signs that AI is contributing to the pain for the 22-to-25-year-olds seeking jobs in software development and other occupations that are feeling a big impact from AI. But these professions represent just a sliver of the overall labor market. What’s more, it’s uncertain how much blame AI should get for the job woes. Similarly unknown is whether the loss of entry-level jobs in AI-exposed occupations is a harbinger of what’s coming for others or simply an isolated symptom of what economists refer to as a “low-fire, low-hire” labor market caused by a variety of macroeconomic forces. Insights into these uncertainties will tell us much about our working fates in the transition to an AI economy. There are no shortage of confident assertions and predictions about what is about to happen; while some people forecast the end of work, others say economic history teaches us that technology advances always lead to more and better jobs eventually.  The honest answer is that no one knows for sure what AI will bring and whether this time will be different. To help figure it out, we need better and far more comprehensive data. The statistics gleaned from the federal government’s monthly survey of 60,000 households for the BLS provide a broad overview of the changes to the labor market, while academics and even some AI companies have begun trying to gain a more granular view of specific jobs that are being affected. But the existing data-gathering tools don’t adequately explain how AI is affecting the huge and diverse US labor market. There’s a long list of questions that we don’t have the data to fully answer. How is AI being used in the workplace? Does the increased use of AI mean the technology will replace workers, or will it make them more productive and valuable? Which occupations and skills are most affected? Who is in most peril from the changes? As David Deming, a professor of economics at Harvard University, puts it: “We’re sort of flying blind.” To gather more insight into some of these questions, Deming and his colleagues have been surveying several thousand people every three months since 2024, asking them basic questions:

The Model Context Protocol has moved from Anthropic’s internal experiment to a de facto industry standard at a speed few integration protocols have matched. Since its launch in November 2024, MCP has grown explosively: OpenAI adopted it in March 2025, Microsoft announced support in Copilot Studio in March 2025, and by late 2025 combined Python and TypeScript SDK downloads had crossed 97 million monthly. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation. Gartner projects that up to 40% of enterprise applications will include integrated task-specific AI agents by the end of 2026, up from less than 5% today. That growth has made authentication the central unsolved problem of the agentic stack. When AI agents do nothing but answer questions, auth is a conversation-level concern. When they read emails, update CRMs, write to databases, and call external APIs autonomously, auth becomes infrastructure — and the blast radius of getting it wrong becomes enormous. The Spec Requirements That Matter Before ranking platforms, it helps to understand exactly what the MCP spec requires for protected HTTP-based deployments — because several well-known providers still fall short on at least one requirement. For a spec-compliant remote MCP server, OAuth 2.1 with PKCE is required when authorization is implemented, all endpoints must use HTTPS, authorization server metadata must be discoverable by clients, Protected Resource Metadata (RFC 9728) must be exposed, and Resource Indicators (RFC 8707) must be validated to prevent token audience confusion. Dynamic Client Registration (DCR) deserves a nuance: it is not a universal hard requirement. The current spec defines CIMD as the should-level preferred registration path, while DCR remains a may-level fallback and backward-compatible option. DCR is still operationally useful — it lets clients self-register with servers they have never encountered before, without a human completing a manual registration step — but providers that support CIMD rather than DCR are still spec-compliant. Best Authentication Platforms for AI Agents and MCP Servers 1. WorkOS — Strong Choice for Enterprise Identity + MCP-Compatible Auth Best for: Enterprise engineering teams that need SSO, SCIM, fine-grained authorization, and audit logging wired directly to MCP server access control. WorkOS is one of the strongest options for teams that want MCP-compatible OAuth combined with enterprise identity primitives. WorkOS AuthKit can act as an OAuth 2.1 authorization server for MCP servers and works with the official MCP SDKs. It also offers SSO, SCIM, Admin Portal, audit logs, and Fine-Grained Authorization (FGA) — covering the access control surface that most standalone auth providers do not address. As an independent company focused solely on enterprise authentication, its roadmap is not split across a broader platform. FGA enables tool-level permission scoping, which is the right abstraction for agentic access control: rather than granting an agent access to a service, you grant it access to specific tools within that service. WorkOS lets teams add MCP OAuth without replacing an existing user database or identity provider — relevant for organizations already running Okta, Entra ID, or an internal directory. Standout feature: The combination of MCP-compatible OAuth, FGA for tool-level scoping, SSO/SCIM, and audit logs under one independent vendor covers more of the enterprise auth surface than most alternatives in this category. Limitation: Pricing is tailored and the self-serve path is primarily developer-oriented. Teams without existing enterprise identity requirements may find the feature surface more than they need. 2. Stytch (a Twilio Company) — Best for Cloudflare Workers + Developer-First MCP Auth Best for: B2B SaaS teams adding MCP authentication on top of an existing auth stack without a full migration, particularly those deploying on Cloudflare Workers. Stytch’s Connected Apps platform is purpose-built for agentic use cases. It implements OAuth 2.1 with PKCE, Dynamic Client Registration, and consent UI, and can operate as a standalone layer on top of existing CIAM providers — meaning teams locked into legacy identity infrastructure can adopt Stytch’s MCP-specific flows without migrating their entire user database. Twilio completed its acquisition of Stytch in November 2025, so current positioning reflects that ownership. The Cloudflare integration is the clearest product differentiator. Cloudflare’s Agents SDK includes a McpAgent class that handles transport and authentication automatically, and its workers-oauth-provider library implements the full OAuth server flow for Workers deployments. Stytch’s Trusted Auth Tokens integrate with this environment cleanly, making it a natural choice for teams building remote MCP servers at the edge. Role-based access control covers B2B multi-tenant scenarios, and the drop-in consent screen handles user-facing agent authorization flows — the UX piece that most lower-level auth primitives leave to the developer. Standout feature: Trusted Auth Tokens that integrate with existing CIAM providers without requiring a full migration. For teams on a legacy identity stack who need MCP-compatible auth quickly, this is a practical fast path. Limitation: As with any post-acquisition product, roadmap direction under Twilio is worth tracking for teams making long-term infrastructure commitments. 3. Auth0 by Okta — Best for Teams with Existing Auth0 Deployments Best for: Organizations that have already standardized on Auth0 or Okta and want to extend that infrastructure to MCP servers rather than introducing a new vendor. Auth0’s “Auth for MCP” became generally available on May 6, 2026, having exited early access in November 2025. It includes CIMD registration and on-behalf-of token exchange. For teams already running Auth0, the operational overhead of adding MCP OAuth is lower than switching to a new provider, and the integration path is now more straightforward than it was during the early access period. Okta has also released its own MCP server — a secure protocol abstraction layer that enables AI agents and LLMs to interact with Okta’s scoped management APIs in natural language, with least-privilege access control enforced at each tool call. This positions Okta not just as an auth provider for MCP servers but as an MCP server in its own right. The tradeoff is pricing complexity. Since Okta acquired Auth0 in 2021, some product overlap has created complexity in the enterprise feature roadmap, and FGA capabilities carry additional cost. Teams should factor this into

For years, authentication on the web followed one design assumption: a human sits behind a browser. Click a button. Fill out a form. Verify an email. Copy an API key and paste it somewhere else. That model does not work when the user is delegating work to an agent. Agents are already writing code, opening pull requests, triaging tickets, querying systems, and updating records. But most products still have no real way for an agent to register. The workaround — giving an agent a raw API key or session token — produces credentials that are unscoped, hard to audit per session, and impossible to revoke selectively. WorkOS is proposing a structured alternative: auth.md, an open protocol for agent registration. What is auth.md? auth.md is a small Markdown file an application publishes at a well-known location — typically https://service.com/auth.md. The file tells agents how to register with that service: which flows are supported, which scopes exist, and how credentials are issued, audited, and revoked. Because it is plain-text Markdown, the same file works as documentation for human developers and as a runtime artifact agents can read programmatically. An agent fetches the file, reads the structured sections, picks the right flow, and registers — without a human filling out a form. Discovery works in two hops. The machine-readable source of truth lives at /.well-known/oauth-protected-resource (Protected Resource Metadata, or PRM). It promotes the resource and points at the Authorization Server. The Authorization Server metadata at /.well-known/oauth-authorization-server carries the agent_auth block — the structured object that tells agents which flows are supported, and what the register_uri, claim_uri, revocation_uri, and identity_types_supported values are. The auth.md file is the prose companion that points agents toward this discovery path. On any 401 from the API, the service should return a WWW-Authenticate: Bearer resource_metadata=”…” header so agents can bootstrap discovery without reading documentation first. The Two Registration Flows auth.md defines two primary flows. An application can support either or both. Agent verified flow: The agent’s identity provider — OpenAI, Anthropic, Cursor, or any trusted platform — attests to the user’s identity at registration time. The agent requests an audience-specific ID-JAG from its provider, then POSTs it to the app’s /agent/auth endpoint. The app decodes the ID-JAG header to get kid and alg, looks up the issuer in its trusted providers list, fetches the provider’s JWKS, verifies the signature, validates claims (aud, exp, iat, jti, client_id), and returns credentials synchronously. No OTP, no email round-trip, no human interaction required. The result is a delegation record per (iss, sub, aud) that the provider can revoke at any time by POSTing a logout token to the service’s revocation_uri. Apps that already JIT-provision users from OIDC or SAML will recognize this pattern — it is the same shape with a different issuer. One important constraint: access tokens issued from ID-JAG verification must not include a refresh token. The agent must present a fresh ID-JAG to extend access. User claimed flow: This is an OTP-based path that requires no agent provider participation. The agent registers with the app, and the user binds the registration by reading a one-time code from an email back to the agent. The two claim endpoints are /agent/auth/claim (to trigger the OTP email) and /agent/auth/claim/complete (to submit the code). This flow has two starting shapes. In the anonymous start variant, the agent self-registers without identity and receives a credential immediately, scoped to pre-claim permissions the app defines. At any point before the registration expires, the agent runs the OTP ceremony to bind the credential to a real user and upgrade scopes. The API key is not rotated on claim — scopes upgrade in place. In the email required variant, the agent supplies a user email at registration. The credential is withheld entirely until the OTP ceremony completes. Use this when any pre-claim usage is unacceptable. User Matching and Audit When credentials are issued, the service needs to match the registration to an existing user or provision a new one. The recommended resolution order is: match on a prior delegation record for the same (iss, sub) pair first; then match on a verified email; then JIT-provision a new user per the app’s policy — or reject if the product requires manual onboarding. For observability and incident response, the docs recommend recording a standard set of audit events: registration.created, claim.requested, otp.generated, claim.confirmed, registration.expired, and registration.revoked. For ID-JAG flows, include iss, sub, and agent_platform so operators can correlate with provider-side logs. Marktechpost’s Visual Explainer auth.md — Implementation Guide Open Protocol 01 / 07   Overview What Is auth.md? auth.md is a small Markdown file your app publishes at its domain. It tells AI agents how to register on behalf of a user: which flows are supported, which scopes exist, and how credentials are issued, audited, and revoked. Because it is plain-text Markdown, the same file works as documentation for human developers and as a runtime artifact agents can read programmatically. Open Protocol No WorkOS Account Required OAuth-Based https://workos.com/auth-md 02 / 07   Discovery How Agents Find Your Endpoints Discovery works in two hops. Your API returns a header on every 401 that points to the Protected Resource Metadata. The PRM points to the Authorization Server, which carries the agent_auth block with all endpoint URLs. 1 Agent hits your API, receives 401 Unauthorized with a WWW-Authenticate header pointing to PRM 2 Agent fetches /.well-known/oauth-protected-resource to get the Authorization Server URL 3 Agent fetches /.well-known/oauth-authorization-server and reads the agent_auth block: register_uri, claim_uri, revocation_uri, identity_types_supported WWW-Authenticate: Bearer resource_metadata=”https://api.service.com/.well-known/oauth-protected-resource” 03 / 07   Flow 1 Agent Verified Flow The agent’s identity provider (OpenAI, Anthropic, Cursor, etc.) attests to the user’s identity using an ID-JAG. No human interaction required. Credentials are returned synchronously. 1 Agent asks user for consent to assert identity to your service 2 Agent requests an audience-specific ID-JAG from its provider 3 Agent POSTs the ID-JAG to your /agent/auth endpoint 4 Your service verifies the signature against the provider’s JWKS, validates claims (aud, exp, iat, jti), matches the user, and returns credentials 5 Revocation: provider POSTs

arXiv:2605.23069v1 Announce Type: new Abstract: Large language models (LLMs) are increasingly used across diverse linguistic and cultural contexts, yet their cultural knowledge remains uneven across regions and languages. We present the DFKI-MLT system for SemEval-2026 Task 7 on cultural awareness, where we apply activation steering to multilingual LLMs using language vectors extracted from parallel FLORES data. Our method performs inference-time adaptation by adding language-specific steering vectors to the residual stream at a selected transformer layer, without any parameter updates. We participated in both the short-answer (SAQ) and multiple-choice (MCQ) tracks; however, only our MCQ submission received an official score. In the official MCQ track, we achieved 86.96% accuracy, ranking 7th out of 17 teams. To better understand system behavior, we conduct post-hoc analyses on the shared-task MCQ and SAQ settings. These analyses show that activation steering yields modest and heterogeneous improvements on cultural reasoning: gains are strongly layer-sensitive, vary substantially across language-region pairs, with some configurations even degrading performance, and interact with prompt formulation, comparing generic and culturally conditioned prompts. Our findings suggest that prompt design and activation steering should be jointly optimized for culturally aware multilingual inference.

arXiv:2605.20043v2 Announce Type: replace Abstract: We present an orthography-aware error analysis of Japanese past-tense morphological inflection, treating hiragana not merely as a transcriptional medium, but as a representational system encoding morphophonological distinctions that may influence model generalization. We evaluate two character-level sequence-to-sequence architectures on past-tense formation using datasets formatted according to the SIGMORPHON 2020 and 2023 shared task conventions. Despite high aggregate accuracy, models exhibit systematic, linguistically interpretable errors that cluster around specific orthographic properties of hiragana. We introduce a concise error taxonomy capturing seven primary failure modes and provide both quantitative and qualitative analyses. Gemination-related errors dominate residual failures, accounting for 75-80% of errors, particularly in verbs whose stems end in the vowel e and require gemination before the past-tense suffix. Error patterns remain highly consistent across architectures and random seeds, suggesting a robust interaction between orthographic representation, morphological structure, and data frequency effects in shaping model generalization. These results underscore the necessity of orthography-aware evaluation for understanding neural generalization in morphologically complex languages.