oauth

17 posts

cloudflare

From ranking to recommended: get your site ready to thrive in the age of AI agents (opens in new tab)

AI assistants are becoming a major channel through which customers discover, compare, and purchase from businesses. As agents replace traditional search journeys, discoverability increasingly depends on whether a site is easy for machines to access, understand, trust, and recommend. Cloudflare’s Agent Readiness and Answer Engine Optimization (AEO) tools measure both technical accessibility and visibility in AI-generated recommendations. ## The Rise of the Agentic Audience - Fewer than half of HTML page requests reportedly come from humans, with the remainder including crawlers, bots, and increasingly capable agents. - Customers may ask AI assistants for: - Solutions to specific problems - Recommendations tailored to their needs - Comparisons between products or services - Actions performed on their behalf - Traditional metrics such as clicks and page views do not show whether AI systems can use a site or recommend it. - Agent-focused discoverability requires being found, read, and confidently cited by answer engines, shopping assistants, and research tools. ## Diagnostics: Measuring Agent Readiness Cloudflare’s Diagnostics feature evaluates a site from an agent’s perspective rather than simply loading its homepage. - It checks whether agents: - Are permitted to access the site - Can discover its content - Can retrieve clean, machine-readable content - Can identify callable interfaces and authentication methods - Diagnostic checks examine: - `robots.txt` - XML sitemaps - Response headers - Markdown content - Published metadata - APIs and agent-facing tools - Results are grouped into readiness levels from “Not Ready” to fully agent-native. - Each check returns: - Pass, fail, or neutral status - An explanation of its significance - Evidence showing the exact request and response ### Diagnostic Improvement Areas - **Quick wins:** Crawler-readable `robots.txt`, XML sitemaps, AI-crawler rules, and clean Markdown. - **Technical groundwork:** Content Signals, API catalogs, link headers, and agent login instructions. - **Advanced integration:** OAuth discovery, MCP, A2A agent cards, skills indexes, Web Bot Auth, and WebMCP. - **Commerce:** Emerging standards such as x402, ACP, UCP, and AP2. These are currently informational and do not affect the readiness score. - Recommended fixes either link directly to Cloudflare settings or generate a coding prompt that can be given to an agent. ## AEO: Measuring AI Recommendations Agent Readiness shows whether agents can access a site; AEO measures whether assistants actually recommend it. - Cloudflare infers a site’s industry and category, then tests likely customer prompts against assistants such as Claude and GPT. - Prompts cover recommendations, product comparisons, and general category advice without naming the customer’s brand. - AEO reports several visibility metrics: - **Citation Rate:** How often the site is cited as a source. - **Prominence:** How early and substantially the site appears in an answer. - **Mention Rate:** How often the brand is named, even without a source citation. - **Share of Voice:** The site’s share of citations compared with competitors. - Comparing mention and citation rates distinguishes brand awareness from authoritative attribution. ## Category Benchmarks and Industry Fit Cloudflare builds a benchmark for each industry and category before scoring individual sites. - AI assistants are queried with representative prompts to identify: - Which sites are cited - Where citations appear - How prominently each brand is represented - The benchmark is reused across accounts in the same category rather than regenerated for every scan. - This approach provides: - Instant result loading - Lower AI-compute costs - An **Industry Fit** score showing whether the site appears alongside its real competitors ## Multimodel Evaluation Because AI responses vary, Cloudflare queries assistants multiple times across different models using AI Gateway. - The system analyzes the actual answer text and cited sources customers would see. - Workers AI evaluates citation and mention patterns on Cloudflare’s infrastructure. - Exact text analysis is used alongside model-based judgment, rather than asking a model to grade its own response. - The process converts many variable responses into consistent, actionable metrics without requiring site owners to build their own evaluation framework. ## Operator Activity Cloudflare also reports real crawl and referral activity from AI operators. - Activity is shown by operator, including OpenAI and Google. - Site owners can see: - Which operators read their content - Which operators send visitors back - Errors encountered during crawling, such as `403` blocks and `404` links The broader goal is to connect controlled AEO benchmarks with real-world agent traffic, helping businesses understand both how AI systems perceive them and whether those systems can successfully access and use their sites. Businesses should treat agents as a core audience: first make the site technically accessible and machine-readable, then measure whether AI assistants cite and recommend it. Acting early may provide an advantage because most websites are not yet optimized for agent discovery.

cloudflare

WriteGuard: Fine-grained controls for MCP Servers (opens in new tab)

Cloudflare built WriteGuard to safely expand AI agents’ write access to internal MCP servers. The system centralizes authorization, risk classification, agent attribution, and auditing, addressing failures that client-side prompts or individual user vigilance cannot reliably prevent. It preserves the human user’s permissions while making each agent session identifiable and its actions queryable. ## The Risk of Uncontrolled Agent Actions - A broadly instructed cleanup agent accidentally closed thousands of tickets. - Human and agent actions were recorded under the same employee identity, making the incident difficult to investigate and repair. - Network logs could not distinguish between multiple agent sessions. - More serious failures could involve: - Amending contracts - Sending mass customer replies - Deleting database tables - Triggering destructive production actions ## MCP Fundamentals - The Model Context Protocol connects AI applications to external tools and data. - An MCP server exposes tools with: - A name - A description - An input schema - A handler that performs the operation - When an agent selects a tool, the MCP client sends the call to the server, which interacts with the downstream application. ## Cloudflare’s MCP Expansion - Cloudflare uses MCP with local clients such as OpenCode and Cloudflare OS, as well as long-running agent services. - Its internal MCP portal grew from 13 servers to 27. - Servers initially provided read-only access to systems such as Jira, GitLab, internal documentation, and operational tools. - As agents became more capable, teams requested write actions across engineering, product, design, sales, and customer success. - Cloudflare decided centralized controls were necessary because client-side skills and elicitation prompts vary across agent harnesses and can be disabled. ## WriteGuard’s Policy and Attribution Layer - WriteGuard evaluates tool configuration together with request context. - It can: - Pass a call through unchanged - Add agent attribution to supported writes - Create a scrubbed audit event - Block a call before the tool handler executes - Policies are defined per tool and include: - Risk tier - Enabled or disabled status - Labeling configuration - Risk tiers include: - **Read Only:** Search issues or inspect merge requests - **Minimal Impact:** Add reactions or mark notifications read - **Contained Write:** Add comments, create merge requests, or update issue fields - **Critical:** Merge code, deploy to production, or bulk-delete records - Labeling allows agent context to be inserted into downstream applications in formats such as plain text or HTML without modifying the MCP server. ## Preserving Human Permissions While Identifying Agents - Agents operate through the employee’s Cloudflare Access and OAuth identity. - An agent cannot perform an action its user is not authorized to perform. - Cloudflare avoided standalone agent accounts because they would create additional permissions to manage and weaken accountability. - WriteGuard supplements the human identity with MCP client and session information. - Each write can therefore be tied to both the responsible person and the specific agent session. ## Centralized, Queryable Auditing - WriteGuard classifies every invocation as successful, failed, or blocked. - It asynchronously sends scrubbed events to an internal audit Worker. - Audit records include: - MCP server and tool - Risk tier - Outcome - User and client - Request duration - Secret and sensitive input values are omitted. - Asynchronous logging avoids adding latency to the agent’s response. - MCP portal logs show raw tool invocations, while WriteGuard adds semantic classifications, agent context, and backing-service outcomes. - Central auditing makes unusually fast or widespread agent activity easier to detect and investigate. ## Recommendation Organizations expanding MCP agents beyond read-only access should use centralized, server-side policy enforcement, preserve human authorization boundaries, attach per-session agent attribution, and maintain scrubbed audit logs. Relying solely on prompts, client configuration, or undifferentiated user identities makes destructive automation difficult to prevent and even harder to understand afterward.

gitlab

GitLab Patch Release: 19.1.2, 19.0.4, 18.11.7 | GitLab Docs (opens in new tab)

GitLab released patch versions 19.1.2, 19.0.4, and 18.11.7 on July 8, 2026, addressing multiple security vulnerabilities and bugs in CE and EE. GitLab strongly recommends that all affected self-managed installations upgrade immediately; GitLab.com is already patched, while GitLab Dedicated customers need no action. The release includes fixes ranging from cross-site scripting and HTML injection to authorization and credential-access issues. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - Patch releases address security vulnerabilities and important bugs. - Scheduled patch releases occur twice monthly, on the second and fourth Wednesdays. - Vulnerability details are generally made public 90 days after the fixing release. - All self-managed deployments—including Omnibus, source, and Helm installations—should upgrade to the latest supported patch version. ## High-Severity Browser Script Injection Fixes - **CVE-2026-6896 — CVSS 8.7** - Affected the vulnerability evidence table renderer in GitLab EE. - An authenticated developer could potentially execute scripts in another user’s browser through unsanitized input. - **CVE-2026-13320 — CVSS 7.3** - Affected wiki markup rendering in GitLab CE and EE. - Improper sanitization could allow an authenticated user to execute scripts in another user’s browser. ## Authorization and Information Disclosure Fixes - **CVE-2026-11827 — CVSS 4.9** - Affected repository mirroring in GitLab EE. - Maintainers could potentially access credentials stored for another user because of inadequate authorization checks. - **CVE-2026-8472 — CVSS 4.3** - Affected work items in GitLab EE. - Users with minimal access could read metadata from work items in private projects. - **CVE-2026-7492 — CVSS 4.3** - Affected commit discussion display in GitLab CE and EE. - Unauthenticated users could determine whether a private project existed through cross-project references. ## Repository and Configuration Security Fixes - **CVE-2025-12506 — CVSS 3.5** - Addressed ambiguous Git tag or branch references. - A repository could display content in the web interface that differed from the content available for download. - **CVE-2026-13151 — CVSS 2.7** - Fixed incorrect authorization in GitLab EE group-level settings. - Some authenticated users could modify settings beyond their intended permissions. - **CVE-2026-6352 — CVSS 2.7** - Fixed authorization flaws in compliance violation management. - Auditor-level users could modify compliance records through certain GraphQL operations. ## Bug Fixes in GitLab 19.1.2 - Set and backfilled `organization_id` for OAuth applications before constraint validation. - Upgraded Go to version 1.25.11. - Fixed multi-architecture tags on the legacy container registry path. - Improved external agent flows by using commit author and committer identities. - Fixed ClickHouse 23.x compatibility for `ci_finished_builds`. - Added cursor pagination and checkpoint limits to Duo workflow event retrieval. - Reverted a problematic merge request and removed an obsolete active-user cron schedule. - Fixed approval-rule regressions affecting Developer-authored merge requests. - Resolved a memory leak on the commits page caused by eager description loading. - Updated the builder image revision to `5.60.1`. ## Additional Fixes in GitLab 19.0.4 - Backported the OAuth `organization_id` fixes. - Added Skopeo registry authentication through `CI_JOB_TOKEN`. - The release also contains further backported fixes, though the provided release notes are truncated before listing them. Self-managed GitLab administrators should upgrade to 19.1.2, 19.0.4, or 18.11.7 according to their supported release line, prioritizing the update because of the two high-severity script-injection vulnerabilities.

cloudflare

Unlocking the Cloudflare app ecosystem with OAuth for all (opens in new tab)

Cloudflare opened self-managed OAuth to all customers so developers can build SaaS integrations, internal platforms, CI/CD workflows, and agentic tools without relying on difficult-to-manage API tokens. The expansion required improvements to permissions, consent, revocation, and phishing protections, as well as a major upgrade to the Hydra-based OAuth engine. Cloudflare used staged migrations, custom database changes, token-handling safeguards, and queued revocations to minimize disruption and preserve users’ security controls. ## Why Cloudflare Expanded OAuth Access - Previously, third-party OAuth integrations were limited to manually approved partners. - Other developers had to use API tokens, which are less convenient and poorly suited to delegated access. - Self-managed OAuth lets customers: - Request narrowly scoped permissions. - Give users clearer consent controls. - Revoke application access from the dashboard. - Build integrations and agentic tools using standard OAuth flows. - Cloudflare improved consent screens to identify the requesting application and its permissions, while making application ownership more visible to reduce phishing risks. ## Planning the Hydra Upgrade - Cloudflare used Hydra, an open-source OAuth engine, but its older deployment could not support the platform’s growing scale and new use cases. - The upgrade was split into two stages: - First, move to the latest 1.X release. - Then, perform the larger 2.X migration. - The 1.X database migrations created operational risks: - Standard index creation could take exclusive locks on critical tables. - Schema changes added columns and moved data between tables. - Hydra’s SDK used `SELECT *`, creating deserialization problems after schema changes. - Cloudflare rewrote migrations to use `CREATE INDEX CONCURRENTLY` and built a custom Hydra version that selected explicit columns. ## Designing a Blue-Green Migration - An in-place 2.X upgrade was rejected because of the volume of schema changes. - A blue-green deployment was chosen, but the migration would take several hours. - Disabling writes would prevent new authorizations and revocations, leaving users unable to manage application access during the upgrade. - Instead, Cloudflare kept writes enabled while reducing the amount of data that could be lost during the cutover: - Token expiry times were temporarily extended to multiple hours, reducing refresh-token writes. - Revocation events were written to Cloudflare Queues. - After switching to the green database, queued revocations could be replayed. - Preserving revocations was essential to prevent applications that users had disabled from regaining access. ## Lessons from the 1.X Upgrade - The custom migrations completed faster than expected without user impact. - A hard cutover was necessary because the old Hydra version could not read tokens created by the new version. - The new version introduced stricter refresh-token invalidation: - Reusing a refresh token invalidated the entire access and refresh-token chain. - This caused problems for high-volume clients such as Wrangler and MCP clients. - Cloudflare added refresh-token coalescing in the Worker routing layer: - Briefly caching requests allowed retries to be served without triggering invalidation. - Hydra 2.X provides a configurable refresh-token grace period, offering a more direct solution for safe retries. ## Executing the 2.X Upgrade - Cloudflare prepared a blue-green migration to avoid several hours of customer-facing downtime. - The strategy depended on reducing token writes, recording all revocations externally, switching databases, and replaying queued events afterward. - The provided article ends while beginning the detailed discussion of the 2.X execution. Cloudflare’s approach demonstrates that opening a security-sensitive platform to broad OAuth usage requires more than exposing an authorization endpoint. Safe adoption depends on explicit permissions, transparent consent, reliable revocation, backward-compatible token behavior, and migration plans that protect users even during infrastructure cutovers.

cloudflare

Temporary Cloudflare Accounts for AI agents (opens in new tab)

Cloudflare introduced Temporary Cloudflare Accounts for AI agents, allowing them to deploy Workers without human-driven signup or authentication. With `wrangler deploy --temporary`, an agent receives a temporary account, API token, and deployment URL, then has 60 minutes to claim the account. If unclaimed, the account and its resources are automatically deleted. ## Why Frictionless Deployment Matters - Background agents often operate without a human available to complete OAuth, copy tokens, or approve MFA. - Temporary deployments support the agent’s rapid write → deploy → verify iteration cycle. - Throwaway environments let agents test code cheaply and independently. - Agent platforms increasingly need deployment workflows that work without requiring users to create accounts on unfamiliar services. ## How Temporary Accounts Work - The feature is integrated into Wrangler, Cloudflare’s CLI for creating, configuring, and deploying projects. - When an unauthenticated deployment encounters the normal signup barrier, Wrangler informs the agent about the `--temporary` option. - Running `wrangler deploy --temporary` provisions: - A temporary Cloudflare account - An API token for Wrangler - A claim URL that can be returned to the user - The temporary account can be reused for multiple deployments during the 60-minute window. ## Agent Deployment and Iteration - An agent can create a TypeScript “Hello World” Worker, deploy it, and use the returned preview URL to verify the result. - It can then modify the source and redeploy without repeating account setup. - Agents can use this loop to test and refine applications autonomously. ## Claiming or Expiring the Account - Users can open the claim link, sign up for or sign in to Cloudflare, and permanently take ownership of the temporary account. - Claiming includes associated Workers, databases, and other bindings. - Unclaimed accounts are automatically deleted after 60 minutes. ## Broader Agent Provisioning Efforts - Cloudflare is also working with Stripe on protocols for agents to create accounts, start subscriptions, register domains, and obtain deployment credentials without manual token or payment entry. - Its collaboration with WorkOS on `auth.md` aims to support agent-driven account creation through established OAuth standards. - Temporary accounts are positioned as one step toward making Cloudflare and other services easier for AI agents to use. Developers should update Wrangler and try `wrangler deploy --temporary` for autonomous, short-lived deployments, while consulting Cloudflare’s documentation for current limitations.

cloudflare

Your AI bill is out of control. Cloudflare can fix it now. (opens in new tab)

Cloudflare argues that uncontrolled AI spending stems from shared API keys, poor attribution, and defaulting to the most expensive models. Its AI Gateway now adds dollar-based spend limits, while a closed beta combines Cloudflare Access with identity-based budgets and routing. The goal is to make AI costs visible, attributable, and controllable without disrupting workflows. ### The AI Spending Problem - Companies encouraged aggressive AI adoption before establishing budgets or monitoring. - Shared API keys make it difficult to identify whether costs came from employees, teams, training pipelines, or runaway CI jobs. - Without routing rules or spending limits, users often choose frontier models for tasks that could use cheaper alternatives. - Visibility and controls are necessary to measure AI ROI and prevent waste. ### What AI Gateway Provides AI Gateway sits between applications and providers such as OpenAI, Anthropic, and Google. - Unified billing across providers and models. - Centralized logging of requests, token counts, and costs. - Response caching and rate limiting. - Content guardrails that can block PII and secrets before they reach models. - Previously, however, it lacked detailed attribution and budget controls. ### Dollar-Based Spend Limits - Budgets are measured in dollars rather than tokens and track cumulative request costs in real time. - Limits can be scoped by: - Model - Provider - Custom attributes such as user, team, or application - Budgets support daily, weekly, or monthly windows, including fixed and rolling periods. - When a limit is reached, requests can be blocked by default. - Dynamic Routes can instead redirect requests to a cheaper fallback model. - Spend limits are available in open beta across all AI Gateway plans through the dashboard or API. ### Identity-Driven Attribution and Policies Cloudflare Access can attach verified identity information to AI Gateway requests. - Authenticated user identities are extracted from Access JWTs and added as request metadata. - Organizations can track usage by employee, team, identity-provider group, or service. - Per-user budgets can give different spending limits to individual contributors and senior engineers. - Team policies can control which models different groups may use. - Access service tokens provide named identities for CI/CD pipelines and autonomous agents. - Logs include details such as email address, IdP group, or service-token name for export to analytics systems. - Configuration uses Cloudflare Access applications and existing identity-provider groups, without requiring custom Workers or manual JWT parsing. ### Cloudflare’s Internal Use - Cloudflare routes millions of requests and billions of tokens through AI Gateway each month. - It uses identity metadata to attribute costs, understand team usage, and manage budgets. - The company is making this internal approach available through the closed beta for identity-driven budgets and policies. Organizations should route AI traffic through a gateway, assign verified identities, set dollar-based budgets, and use model fallback rules to balance cost control with developer productivity.

aws

Improve your application resilience with Amazon Cognito multi-Region replication | Amazon Web Services (opens in new tab)

Amazon Cognito multi-Region replication improves authentication resilience by maintaining synchronized user data, credentials, configurations, and machine secrets in a secondary AWS Region. During a regional outage, applications can redirect traffic while users continue using existing credentials and sessions, though registration and profile updates are unavailable during failover. The feature also adds customer managed AWS KMS keys for consistent, customer-controlled encryption across Regions. ## Challenges with Regional Failover - Custom replication solutions previously required significant engineering effort. - Manual user-data transfers introduced security and consistency risks. - Users could be forced to reset passwords or authenticate again after a regional switch. - Machine-to-machine systems required new app clients, application reconfiguration, and updated OAuth resource trust settings. ## How Multi-Region Replication Works - Replication is one-way, from a primary Region to a secondary Region. - The replica includes: - User profiles and credentials - User pool configuration - Machine-to-machine secrets - The secondary pool is read-only and remains available for authentication. - Existing sessions continue uninterrupted. - Users can authenticate with existing credentials, and either Region recognizes access tokens issued by the other. - Supported authentication methods include: - Social identity providers - SAML and OIDC federation - API authorization flows - Machine-to-machine authentication - New registrations and profile changes are unavailable while operating from the replica. ## Customer Managed KMS Keys - A multi-Region customer managed key is required before replication can be configured. - The key must be replicated into both the primary and secondary Regions. - Its policy must grant Amazon Cognito permission to use the key. - Customer managed keys provide consistent encryption across Regions and greater control over encryption policies. ## Configuration Process - The console guides administrators through three main steps: - Select and configure the customer managed KMS key. - Configure multi-Region OIDC issuer endpoints. - Select and create the replica Region. - Client applications must be updated with the new OIDC endpoints. - Server-side applications require redeployment, while mobile applications require updated store submissions. - After the replica is prepared, an administrator must manually activate it. ## Additional Regional Resources - Lambda functions used for custom authentication, SMS, or email must be deployed and configured in the secondary Region. - Logging and AWS WAF settings must also be recreated there. - Teams should verify that all supporting authentication infrastructure is available before failover. ## Health Checks and Failover - Both regional endpoints remain active and ready to serve traffic. - Applications should define health checks based on error rates, latency, or service alerts. - DNS can redirect traffic to the secondary Region when failover criteria are met. - Teams should test failover during low-traffic periods, potentially routing only a small percentage of traffic initially. - Managed login and federation with custom domains can use Amazon Route 53 health checks for built-in traffic routing. ## Pricing and Availability - Replication is available as an add-on for Cognito Essentials and Plus tiers. - User authentication costs: - $0.0045 per monthly active user per replica Region for Essentials - $0.006 per monthly active user per replica Region for Plus - M2M replication adds 30% to standard successful-token pricing. - The feature is available across selected Regions in North America, Europe, Asia Pacific, Canada, Africa, and South America. Organizations needing resilient authentication should pair Cognito replication with multi-Region KMS keys, replicated supporting services, tested health checks, and an automated or well-practiced DNS failover process.

gitlab

GitLab Patch Release: 18.11.3, 18.10.6, 18.9.7 | GitLab Docs (opens in new tab)

On May 13, 2026, GitLab released patch versions 18.11.3, 18.10.6, and 18.9.7 for CE and EE. The releases address multiple high-severity security vulnerabilities, including cross-site scripting, denial of service, authorization, and access-control issues. GitLab strongly recommends that all affected self-managed installations upgrade immediately. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - GitLab.com is already patched; GitLab Dedicated customers do not need to act. - Patch releases may be scheduled or issued urgently for critical vulnerabilities. - Security vulnerability details are published publicly 30 days after the fixing release. - Unless otherwise specified, all deployment types—including Omnibus, source installations, and Helm charts—are affected. ## Cross-Site Scripting Vulnerabilities Several authenticated-user XSS vulnerabilities could allow arbitrary JavaScript to execute in other users’ browsers: - **CVE-2026-7481**: Affects EE Analytics dashboard chart rendering; exploitable by users with Developer permissions. - **CVE-2026-5297**: Affects global search in CE and EE. - **CVE-2026-6073**: Affects EE Duo Agent output rendering. - **CVE-2026-7377**: Affects customizable EE Analytics dashboards. - Each issue received a **CVSS score of 8.7** and resulted from improper input sanitization. ## Denial-of-Service Vulnerabilities The release fixes multiple unauthenticated denial-of-service issues involving malformed requests or files: - **CVE-2026-1659**: Specially crafted requests to the CI/CD job update API could disrupt service. - **CVE-2025-14870**: Malformed JSON payloads targeting the Duo Workflows API could cause a denial of service. - **CVE-2025-14869**: Certain internal API endpoints were vulnerable to specially crafted payloads. - **CVE-2026-1184**: A specially crafted file uploaded through Insights Configuration could cause service disruption. - The API-related issues were rated **CVSS 7.5**; the Insights issue was rated **6.5**. ## Authorization and Access-Control Issues - **CVE-2026-1322**: An authenticated user with a `read_api`-scoped OAuth application could create issues and comment on private projects through GraphQL, due to improper token-scope enforcement. It received a **CVSS score of 6.8**. - **CVE-2026-4524**: Authenticated users could access confidential issue content in public projects through the Issues API without proper authorization checks. It received a **CVSS score of 6.5**. ## Recommended Action Self-managed GitLab administrators should upgrade to the latest supported patch release—18.11.3, 18.10.6, or 18.9.7—as soon as possible, particularly because several vulnerabilities are remotely exploitable and require little or no authentication.

cloudflare

Agents can now create Cloudflare accounts, buy domains, and deploy (opens in new tab)

Agents can now take an application from development to production by creating Cloudflare accounts, obtaining API tokens, purchasing domains, and deploying code. Cloudflare’s integration with Stripe Projects removes most manual setup while keeping humans involved for permissions, terms acceptance, and payment approvals. The underlying protocol combines service discovery, authorization, and tokenized payments so agents can provision infrastructure on a user’s behalf. ## Zero-to-production deployment - Users install the Stripe CLI, authenticate, and run: ```bash stripe projects init ``` - An agent can then build an application and deploy it to a new domain. - If no Cloudflare account exists, one is provisioned automatically. - If an account already exists, the user authorizes access through OAuth. - The agent can: - Create a Cloudflare account - Obtain an API token - Register a domain - Deploy the application to production - Humans are prompted only when approval, terms acceptance, or payment setup is required. ## The protocol: discovery, authorization, and payment - **Discovery:** Agents query a catalog of available provider services and select the resources needed for the user’s request. - **Authorization:** The orchestrating platform verifies the user’s identity and enables providers to create accounts, connect existing accounts, and issue credentials securely. - **Payment:** Tokenized payment credentials let providers charge the user without exposing raw card details to the agent. - The approach builds on OAuth, OIDC, and payment-tokenization standards. ## Service discovery through a catalog - Agents can inspect available services with: ```bash stripe projects catalog ``` - They can select Cloudflare Registrar with: ```bash stripe projects add cloudflare/registrar:domain ``` - Providers expose service catalogs through REST APIs returning JSON. - This gives agents the context to choose appropriate products without requiring users to know which provider offers them. ## Automatic account creation and authorization - Stripe acts as the identity provider and attests to the user’s identity. - Cloudflare creates a new account automatically when the user has none. - Credentials are securely stored by the Stripe Projects CLI but made available to the agent for authenticated Cloudflare API requests. - Existing Cloudflare users authorize the integration through a conventional OAuth flow. ## Controlled agent spending - Agents never receive the user’s raw credit card information. - Stripe supplies Cloudflare with a payment token for subscriptions and purchases. - Spending is initially capped at $100 per month per provider. - Users can raise the limit and configure Cloudflare Budget Alerts as needed. ## Broader platform integration - The protocol is not limited to Stripe Projects. - Any platform with signed-in users can act as the orchestrator and integrate with Cloudflare. - This enables coding-agent platforms to let users deploy directly to production without requiring separate dashboard logins, token copying, or manual account setup. - Cloudflare is also enhancing the experience through its Code Mode MCP server and Agent Skills. Cloudflare and Stripe’s integration makes infrastructure provisioning an agent-driven workflow while retaining safeguards around identity, consent, and spending. For platforms building coding agents, adopting the protocol could provide a frictionless path from generated code to a live, paid production deployment.

line

ID-JAG, a next-generation standard candidate for solving authentication challenges in the AI era (opens in new tab)

ID-JAG extends enterprise SSO trust to API access between AI agents, applications, and services. It uses an enterprise IdP to centrally evaluate permissions and issue a signed JWT that can be exchanged for a resource-specific access token. This can reduce consent prompts, improve auditing, and limit token sprawl, but organizations should adopt it cautiously while the specification remains an Internet-Draft. ## The Authentication Challenge in the AI Era - AI agents increasingly perform real work, including: - Searching systems - Querying databases - Sending messages - Creating tickets - As the number of connected services grows, authentication and authorization become more complex. - Poorly coordinated integrations can turn AI from a productivity tool into an operational bottleneck. - ID-JAG is being discussed by the IETF OAuth Working Group as a potential solution. ## What ID-JAG Is - ID-JAG, or Identity Assertion JWT Authorization Grant, extends the enterprise IdP’s SSO trust relationship to API access. - The IdP centrally determines: - Which application or agent may access an API - Which user or identity it acts for - Which scopes or permissions are allowed - It combines: - OAuth 2.0 Token Exchange (RFC 8693) - JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523) - The IdP issues a cryptographically verifiable JWT as an “introduction” or authorization assertion. - The target authorization server validates that assertion and issues the final access token. ## The ID-JAG Participants and Flow The model involves four main parties: - **Requesting Agent:** An AI agent or application calling another service’s API - **Enterprise IdP:** Provides SSO and enforces centralized organizational policies - **Authorization Server:** Issues tokens for the target application - **Resource Server:** Hosts the API being accessed The basic five-step flow is: 1. The user signs in to the requesting agent, which obtains an ID token from the IdP. 2. The agent presents the ID token to the IdP and requests an ID-JAG through token exchange. 3. The IdP evaluates organizational policy and issues the ID-JAG if access is allowed. 4. The agent presents the ID-JAG to the target authorization server and receives an access token. 5. The agent uses the access token to call the resource server. The key architectural shift is that authorization decisions move from isolated agent-to-service relationships toward a centrally governed relationship between the enterprise IdP and target authorization servers. ## Benefits for User Experience and Auditing - Centralized IdP policies can reduce repeated consent screens. - This is especially useful when AI agents connect to many tools and services. - ID-JAG claims can record important context, such as: - The user whose authority is being delegated (`sub`) - The requesting agent (`client_id`) - The target authorization server (`aud`) - Approved scopes (`scp`) - Issuer, issue time, expiration, and unique token ID - Centralized issuance logs provide a clearer view of service-to-service relationships. - Security teams can more easily determine which agent accessed which service, on whose behalf, and with what permissions. - The same records can support incident investigation, compliance audits, and accountability. ## Centralized Control and Reduced Token Sprawl - The IdP can help detect and control unauthorized “shadow AI” integrations. - It can evaluate every token exchange using consistent organizational policies. - Requested scopes can be narrowed or overridden according to enterprise security requirements. - Blocking future access can be handled centrally instead of by changing policies across every endpoint. - ID-JAG may reduce token sprawl by avoiding additional long-lived refresh tokens. - The draft recommends that resource authorization servers generally not issue refresh tokens when an ID-JAG is exchanged. - Agents can instead submit a new ID-JAG to obtain another access token, replacing scattered API keys, service credentials, and refresh tokens with dynamic, policy-based trust. ## Adoption Requirements and Risks - ID-JAG is still an IETF Internet-Draft, not a finalized RFC. - Its behavior may change, so systems should avoid tightly coupling their core architecture to the current draft. - Before implementation, organizations need to verify that: - The requesting agent is registered as an OAuth client with both the enterprise IdP and the target authorization server. - Explicit trust relationships exist between the IdP and agent, and between the IdP and authorization server. - The IdP has pre-authorized the agent to act on users’ behalf for the relevant services and scopes. - Deployment also requires coordinated support from agents, enterprise IdPs, authorization servers, and resource servers. Organizations should treat ID-JAG as a promising architectural direction for governing AI-agent access, while isolating its implementation behind adaptable interfaces until the standard stabilizes. Pilot deployments should focus on centralized policy enforcement, detailed audit logging, strict scope control, and minimizing long-lived credentials.

stripe

Giving agents the ability to pay (opens in new tab)

Agents are increasingly capable, but making purchases still requires access to today’s payment systems. Stripe is addressing this with Link’s wallet for agents, which lets users authorize purchases without exposing raw payment credentials. The system uses one-time cards or Shared Payment Tokens (SPTs), with users reviewing each request before approval. ## Link’s Wallet for Agents - Consumers connect an agent to their Link wallet through OAuth. - Agents can request: - One-time-use virtual cards - Shared Payment Tokens backed by cards or bank accounts in Link - Credentials can be restricted by amount, currency, and merchant. - Users approve requests on the web or through Link’s iOS and Android apps. - Users can track spending and manage connected agents in Link. - Stablecoins, agentic tokens, and additional payment methods are planned. ## Approval and Spending Controls - Each spend request currently requires explicit user review. - Link provides transaction context so users can understand what they are approving. - Future controls will support spending limits and allow agents to act without approval in predefined situations. - Agents never receive users’ underlying payment credentials. ## Stripe Issuing for Agents - Link’s wallet is built on Stripe Issuing infrastructure. - Businesses can use Issuing APIs to create customized agent wallets and card experiences. - Developers can control: - Onboarding and fund flows - Card-level permissions - Transaction authorization and fraud checks - Real-time and historical spending visibility - The infrastructure includes virtual cards, fund storage, spending controls, transaction monitoring, and fraud prevention tools. ## Potential Use Cases - Developers can automate business purchases and recurring spend. - Fintech companies can issue cards for real-time expense management and reconciliation. - Vertical SaaS platforms can let SMB agents make purchases under the platform’s brand. - Marketplaces can enable supplier payments, logistics, and fulfillment purchases through agent-issued cards. Stripe’s offering gives agents a practical way to transact through existing payment networks while preserving user oversight and credential security. Developers can use Link for a ready-made wallet or Stripe Issuing to build customized agentic payment workflows.

line

ODW #3: Boosting Development Efficiency by Safely Utilizing MCP Servers (opens in new tab)

LY Corporation is expanding AI use across its engineering organization through MCP servers, which connect AI assistants with internal and external tools through a common protocol. The company combines this flexibility with allowlists, automated security checks, and internal standards to reduce risk. Its Orchestration Development Workshop demonstrates practical applications such as Jira ticket automation and multi-agent code reviews, while emphasizing shared learning and experimentation as AI practices evolve. ## MCP Servers and Their Benefits - MCP servers act as translators between AI assistants and external systems. - Before MCP, each assistant required a separate integration for every tool. - With MCP, a tool can implement one standardized interface and work with multiple compatible assistants. - This improves interoperability, scalability, and the ability to combine different AI tools. ## Security Risks and LY Corporation’s Controls - A 2025 Astrix Security report found that: - More than 5,200 public MCP servers were analyzed. - 53% relied on long-lived static API keys or personal access tokens. - Only 8.5% used newer authentication methods such as OAuth. - LY Corporation manages externally developed MCP servers through: - An allowlist permitting only approved servers. - Automated security verification based on internal standards. - Internal MCP servers for groupware and business systems are built to meet the company’s security requirements. - Centralized infrastructure lets teams focus on applying AI rather than independently rebuilding integrations and controls. ## Workshop Applications The Orchestration Development Workshop taught participants how to understand, configure, and safely apply MCP servers with AI assistants. - Topics included MCP fundamentals, security risks, internal policies, development rules, and configuration in Claude and Cline. - The internal plugin marketplace was introduced as a way to distribute MCP configurations. - Participants practiced using Claude Code with the internal groupware MCP server to: - Generate a Jira ticket title and summary. - Create the ticket automatically. - The exercise showed how AI can remove repetitive administrative work and free time for higher-value tasks. ## Multi-Agent Code Review Demonstration - A demonstration combined Claude Code, Codex CLI, Context7 MCP, and Codex MCP. - A Sonnet-based agent first analyzed a pull request, including: - Technical stack and relevant documentation. - Code changes and repository context. - Security, performance, and code-quality concerns. - GPT-5 then validated the initial review, identifying missed issues and checking the prioritization of findings. - Using different models provided more varied and potentially objective perspectives on the same code. ## Results and Organizational Learning - Around 1,600 people attended the workshop in real time. - 31.5% had already applied related techniques before the event. - Another 55.7% planned to try them soon. - LY also created “Help LY MCP,” a GPTs-based tool that explains internal MCP rules and helps teams assess whether proposed uses are suitable, including for global subsidiaries. - The workshop’s broader purpose was to create a shared understanding of: - What AI and MCP can currently do. - What risks and pitfalls exist. - How to use the technology meaningfully. ## Continuing to Experiment The article concludes that rapidly changing AI technology makes shared experimentation more valuable than simply announcing new tools. MCP may eventually be surpassed by other approaches, such as skills, so teams should continually reassess the best solution. LY recommends creating a culture where employees can safely try small ideas, learn together, and adapt as new practices emerge.

cloudflare

Building the agentic cloud: everything we launched during Agents Week 2026 (opens in new tab)

Cloudflare’s Agents Week 2026 introduced a broad set of infrastructure primitives for building and operating AI agents at scale. The company argues that agents require a new cloud model—“Cloud 2.0”—with elastic compute, built-in security, persistent state, specialized tools, and support for agent-driven web traffic. Its announcements span compute environments, identity and networking, developer tooling, inference, voice, email, and memory. ## Compute for Autonomous Agents - **Artifacts** provides Git-compatible, versioned storage for code and data. It supports tens of millions of repositories, remote forking, and access through standard Git clients. - **Cloudflare Sandboxes**, now generally available, give agents persistent isolated computers with shells, filesystems, and background processes. Environments can start on demand and resume where they left off. - **Outbound Workers for Sandboxes** act as programmable, zero-trust egress proxies. They let developers inject credentials and apply dynamic outbound security policies without exposing secrets to agent-generated code. - **Durable Object Facets** allow dynamically generated Workers to create isolated Durable Objects with their own SQLite databases, enabling stateful applications built on the fly. - **Workflows** was rearchitected to support up to 50,000 concurrent executions and a creation rate of 300, making it more suitable for durable, long-running background agents. ## Security, Identity, and Private Networking - **Cloudflare Mesh** provides private network access for users, infrastructure, Workers, and autonomous agents. Combined with Workers VPC, it enables scoped access to private databases and APIs without manually configured tunnels. - **Managed OAuth for Cloudflare Access** lets agents authenticate to internal applications on behalf of users using RFC 9728 rather than insecure shared service accounts. - New identity controls include scannable API tokens, improved OAuth visibility, and resource-scoped permissions to support least-privilege access and automated credential protection. - Cloudflare outlined an enterprise architecture for governing **MCP** deployments using Access, AI Gateway, and MCP server portals. - **Code Mode** reduces MCP token costs, while new Cloudflare Gateway rules help detect unauthorized or “Shadow MCP” usage. ## The Agent Toolbox - A new preview of the **Agents SDK**, called Project Think, aims to provide a more complete platform for agents that can reason, act, and persist. - An experimental **voice pipeline** supports real-time speech-to-text and text-to-speech over WebSockets, requiring roughly 30 lines of server-side code. - **Cloudflare Email Service** entered public beta, allowing agents to send, receive, and process email as a native communication channel. - Cloudflare’s AI platform is becoming a unified inference layer supporting models from more than 14 providers, including third-party model bindings for Workers and an expanded multimodal catalog. - Cloudflare also described a custom infrastructure stack for serving large language models efficiently on its global network. - **Unweight**, a lossless inference-time compression system, reduces model footprints by up to 22%, improving GPU memory efficiency and potentially lowering inference cost and latency. - **Agent Memory** was introduced as a managed service for giving agents persistent memory, though the provided article excerpt ends before detailing its full capabilities. Cloudflare’s announcements collectively position Workers and related services as a platform for the agentic cloud: one capable of running agents, securing their access, preserving their state, and supplying the models and communication tools they need to operate continuously at Internet scale.

cloudflare

Introducing the Agent Readiness score. Check to see if your site is agent-ready (opens in new tab)

Cloudflare argues that websites must evolve beyond browser and search-engine compatibility to become usable by AI agents. Its new Agent Readiness score evaluates whether sites support standards for discovery, content access, bot control, and agent capabilities. Early data shows adoption is extremely low, creating both a challenge and an opportunity for sites that adopt these standards early. ## Agent readiness across the web - Cloudflare analyzed the 200,000 most visited domains, excluding categories unlikely to need agent interaction. - The resulting Cloudflare Radar dataset tracks adoption of AI-agent standards and will be updated weekly. - robots.txt exists on 78% of sites, but most files target traditional search crawlers rather than AI agents. - Only 4% of sites declare AI usage preferences through Content Signals. - Just 3.9% support Markdown content negotiation via `Accept: text/markdown`. - MCP Server Cards and API Catalogs based on RFC 9727 appear on fewer than 15 sites, showing how early these standards remain. ## The Agent Readiness score Site owners can test their websites at **isitagentready.com**. Cloudflare scans the site and scores it across four dimensions: - **Discoverability:** robots.txt, sitemap.xml, and Link Headers under RFC 8288. - **Content:** Markdown for Agents. - **Bot Access Control:** Content Signals, AI-specific robots.txt rules, and Web Bot Auth. - **Capabilities:** Agent Skills, API Catalogs, OAuth discovery standards, MCP Server Cards, and WebMCP. - The tool also checks commerce standards such as x402, Universal Commerce Protocol, and Agentic Commerce Protocol, though these do not yet affect the score. - Each failed check includes a prompt that can be handed to a coding agent for implementation. The service itself supports agents through a stateless MCP server with a `scan_site` tool and publishes Agent Skills documents explaining how to implement each supported standard. ## Discoverability for AI agents - robots.txt helps agents understand crawl permissions and locate sitemaps. - Sitemaps provide a structured list of site paths, reducing the need to discover content by following every HTML link. - HTTP Link headers, defined by RFC 8288, expose important resources directly in responses without requiring agents to parse page markup. - Sites can use headers such as `rel="api-catalog"` to point agents toward machine-readable capabilities. ## Making content easier to read - `llms.txt` provides an LLM-oriented reading list at the site root, describing the site and linking to important content in a format designed for model context windows. - Markdown content negotiation lets agents request a clean Markdown version of a page with `Accept: text/markdown`. - Cloudflare measured token reductions of up to 80% compared with HTML, improving speed, cost, and the likelihood that agents can consume an entire document within their context limits. Cloudflare’s recommendation is to evaluate sites with the Agent Readiness tool and adopt the relevant standards incrementally. With current adoption so low, early support can make a site significantly easier for AI agents to discover, understand, authenticate with, and use.

gitlab

A guide to the breaking changes in GitLab 19.0 (opens in new tab)

GitLab 19.0 is expected to introduce 15 breaking changes, primarily by removing deprecated components and outdated platform support. The most significant effects involve Helm chart networking and bundled services, OAuth authentication, PostgreSQL, Redis, and supported operating systems. Administrators should audit their deployments and complete migrations before upgrading. ## Release and Deployment Windows - **GitLab.com:** Primary breaking-change window is May 4–6, 2026, with a fallback window on May 11–13. - **GitLab Self-Managed:** GitLab 19.0 becomes available May 21, 2026. - **GitLab Dedicated:** Upgrades occur during assigned maintenance windows, with GitLab 19.0 scheduled for the week of June 22, 2026. - Additional changes may roll out outside these windows in exceptional circumstances. ## High-Impact Changes ### NGINX Ingress Replaced by Gateway API - The GitLab Helm chart will use **Gateway API with Envoy Gateway** as its default networking configuration. - Bundled NGINX Ingress reached end-of-life in March 2026. - Existing deployments can explicitly continue using bundled NGINX Ingress until its planned removal in GitLab 20.0. - The change does not affect: - NGINX used by the Linux package. - Deployments using externally managed Ingress or Gateway API controllers. - Administrators should plan migration to Envoy Gateway or another externally managed controller. ### Bundled PostgreSQL, Redis, and MinIO Removed - The GitLab Helm chart and GitLab Operator will no longer bundle Bitnami PostgreSQL, Bitnami Redis, or the forked MinIO chart. - These components were intended for proof-of-concept and test environments, not production. - Deployments using them must migrate to external services before upgrading. - PostgreSQL and Redis bundled with the Linux package are unaffected. ### OAuth ROPC Grant Removed - The Resource Owner Password Credentials OAuth flow will be removed across GitLab.com, Self-Managed, and Dedicated. - ROPC is being eliminated because of security limitations and its removal from OAuth 2.1. - Applications using ROPC must migrate to a supported flow, such as Authorization Code. - After upgrading, ROPC will not work even when client credentials are provided. ### PostgreSQL 17 Becomes Required - PostgreSQL 16 will no longer be supported; PostgreSQL 17 becomes the minimum version. - Single PostgreSQL instances installed through the Linux package may be upgraded automatically during GitLab 18.11. - Cluster deployments and installations that opt out of automatic upgrades require a manual migration. - Administrators should verify sufficient disk space and complete the upgrade before GitLab 19.0. ## Medium-Impact Changes ### Ubuntu 20.04 Packages Discontinued - GitLab will stop publishing Linux packages for Ubuntu 20.04. - GitLab 18.11 is the final release supporting that distribution. - Affected installations must upgrade to Ubuntu 22.04 or another supported operating system first. ### Redis 6 Support Removed - External Redis 6 deployments must migrate to Redis 7.2 or Valkey 7.2. - The Linux package’s bundled Redis is unaffected because it has used Redis 7 since GitLab 16.2. - Migration options vary by provider: - AWS ElastiCache and GCP Memorystore: Redis 7.2 or Valkey 7.2. - Azure: self-host Redis or Valkey on VMs or AKS until managed support is available. - Self-hosted installations: upgrade directly to Redis 7.2 or Valkey 7.2. ### Auto DevOps Builder Image Updated - The CNB builder image used by Auto DevOps changes from `heroku/builder:22` to `heroku/builder:24`. - Pipelines relying on the older image may need testing or configuration updates. GitLab administrators should review the deprecations and upgrade documentation, identify whether their deployment uses any affected components, and complete required migrations before GitLab 19.0.