Uncategorized

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.

Tencent has released TencentDB Agent Memory, an open-source memory system for AI agents. The project ships under the MIT license. It targets a problem familiar to anyone shipping long-horizon agents: context bloat and recall failure. It is symbolic short-term memory along with layered long-term memory. It integrates with OpenClaw as a plugin and with the Hermes Agent through a Gateway adapter. The default backend is local SQLite with the sqlite-vec extension, so no external API is required. Why agent memory is hard Most current memory stacks shred data into fragments and dump them into a flat vector store. Recall then becomes a blind similarity search across disconnected fragments, with no macro-level guidance. The architecture rests on two pillars: memory layering and symbolic memory. A 4-tier semantic pyramid For long-term personalization, TencentDB Agent Memory builds a four-level pyramid instead of a flat log. The layers are L0 Conversation, L1 Atom, L2 Scenario, and L3 Persona. These correspond to raw dialogue, atomic facts, scene blocks, and a user profile. The Persona layer carries day-to-day user preferences and is queried first. The system drills down to Atoms or raw Conversations only when finer detail is needed. Lower layers preserve evidence; upper layers preserve structure. Storage is heterogeneous. Facts, logs, and traces are persisted in databases for full-text retrieval. Personas, scenes, and canvases are stored as human-readable Markdown files. Layered memory artifacts live under ~/.openclaw/memory-tdai/. Symbolic short-term memory via Mermaid Long-running agent tasks consume tokens through verbose tool logs, search results, code, and error traces. TencentDB Agent Memory addresses this through context offloading combined with symbolic memory. Full tool logs are offloaded to external files under refs/*.md. State transitions are encoded in Mermaid syntax inside a lightweight task canvas. The agent reasons over the symbol graph in its context window. When it needs the raw text, it greps for a node_id and retrieves the corresponding file. The Tencent dev team describes this as a deterministic drill-down from top-layer symbol to mid-layer index to bottom-layer raw text. Benchmark numbers Results are measured over continuous long-horizon sessions, not isolated turns. SWE-bench, for example, runs 50 consecutive tasks per session to simulate context-accumulation pressure. On WideSearch, integrating the plugin with OpenClaw raises pass rate from 33% to 50%, a 51.52% relative improvement. Token usage drops from 221.31M to 85.64M, a 61.38% reduction. On SWE-bench, success climbs from 58.4% to 64.2% while tokens fall from 3474.1M to 2375.4M, a 33.09% reduction. On AA-LCR, the success rate moves from 44.0% to 47.5%. Tokens drop from 112.0M to 77.3M, a 30.98% reduction. For long-term memory, PersonaMem accuracy rises from 48% to 76%. Note: these numbers come from Tencent’s own evaluations. Recall and retrieval Retrieval defaults to a hybrid strategy. The system combines BM25 keyword search with vector embeddings, fused using Reciprocal Rank Fusion (RRF). Developers can switch to pure keyword or embedding mode through a config field. The BM25 tokenizer supports both Chinese (jieba) and English. Default settings trigger an L1 memory extraction every five turns. A user persona is generated every 50 new memories. Recall returns five items by default with a 5-second timeout. On timeout, the system skips injection rather than blocking the conversation. Installation and developer surface The OpenClaw integration ships as a single npm package: @tencentdb-agent-memory/memory-tencentdb. The project requires Node.js 22.16 or higher. Enabling it takes one config flag. The plugin then handles conversation capture, memory extraction, scene aggregation, persona generation, and recall. For Hermes, a Docker image bundles the agent, the plugin, and the TDAI Memory Gateway. The default model is Tencent Cloud’s DeepSeek-V3.2. Any OpenAI-compatible endpoint works through the MODEL_PROVIDER=custom flag. Two tools are exposed to agents during a session: tdai_memory_search and tdai_conversation_search. Both return references with node_id and result_ref fields for traceback. A Tencent Cloud Vector Database (TCVDB) backend is also available as an alternative to local SQLite. Marktechpost’s Visual Explainer TencentDB Agent Memory — Preview Open Source  /  Tencent TencentDB Agent Memory A quick-start guide to fully local, 4-tier long-term memory for AI agents. 01  /  OVERVIEW What is TencentDB Agent Memory? An MIT-licensed memory system for AI agents that combines symbolic short-term memory with a 4-tier long-term memory pipeline. Runs fully local with zero external API dependencies. Short-term memory Offloads verbose tool logs to files and keeps a compact Mermaid task canvas in context. Long-term memory Distills conversations into a 4-tier semantic pyramid: L0 → L1 → L2 → L3. Local backend Defaults to SQLite + sqlite-vec. Tencent Cloud Vector Database (TCVDB) is optional. Integrations Ships as an OpenClaw plugin and a Hermes Agent Docker image. 02  /  ARCHITECTURE The 4-Tier Semantic Pyramid Long-term memory is layered, not flat. Upper layers carry structure; lower layers preserve evidence. L3 · PersonaUser profile (persona.md) L2 · ScenarioScene blocks (Markdown) L1 · AtomAtomic facts (JSONL) L0 · ConversationRaw dialogue Drill-down path: Persona → Scenario → Atom → Conversation. References use node_id and result_ref for deterministic traceback. 03  /  SYMBOLIC SHORT-TERM Mermaid task canvas + context offloading Verbose intermediate logs are the largest token consumers in long tasks. The plugin offloads them to disk and keeps a high-density symbol graph in context. How it works Full tool logs are offloaded to refs/*.md under the data directory. State transitions are encoded in Mermaid syntax inside a lightweight task canvas. The agent reasons over the symbol graph, then greps a node_id to pull raw text. Storage path on disk: ~/.openclaw/memory-tdai/. All artifacts are human-readable for white-box debugging. 04  /  INSTALL Install the OpenClaw plugin Requires Node.js 22.16 or higher and an OpenClaw installation. # Install the npm package as an OpenClaw plugin openclaw plugins install @tencentdb-agent-memory/memory-tencentdb openclaw gateway restart Zero-config enable Add the following to ~/.openclaw/openclaw.json to turn it on with default SQLite + sqlite-vec. { “memory-tencentdb”: { “enabled”: true } } 05  /  CONFIGURATION Daily-tuning parameters Every field has a sensible default. The most common knobs are listed below. Field Default Description storeBackend sqlite Storage backend recall.strategy hybrid keyword / embedding / hybrid (RRF) recall.maxResults 5 Items returned per recall recall.timeoutMs 5000 Skip injection on