🔥 Top Story
BenchMIRT: What are LLM benchmarks actually measuring?
BenchMIRT applies multidimensional Item Response Theory (MIRT) from psychometrics to LLM benchmark scoring, breaking a single aggregate score down into per-question capability signals. The team analyzed 100 LLMs across 16 benchmarks and over 34,000 questions, spanning reasoning suites like MMLU-Pro, GPQA, MATH, and BBH alongside safety suites like HarmBench, StrongReject, WildJailbreak, BBQ, WMDP, and XSTest. The analysis surfaced two dominant, largely independent dimensions across all of them: general reasoning and safety, and found that BBQ, designed for bias testing, actually tracked closer to reasoning than safety. HarmBench produced a mixed signal too, with copyright-related items aligning with reasoning while harmful-request items aligned with safety. Using just 10% of a benchmark's questions preserved most of the capability measurement, and 50% closely matched full-benchmark results. BenchMIRT's held-out question performance predictions were correct 79% of the time, versus 70% for baseline scoring approaches.
💡 Why it matters: For teams running model evaluation or routing pipelines, the finding that benchmarks actually measure separable axes like reasoning and safety argues for choosing models on the right axis rather than an aggregate score, and for cutting evaluation cost by sampling only 10-50% of benchmark questions.
🔗 Read more · Hugging Face
Kubernetes & Cloud Native
Automate proxy injection for Amazon EKS on AWS Fargate using Kyverno
AWS Containers
Amazon EKS pods running on AWS Fargate have no access to the node layer, so there is no way to apply proxy environment variables the traditional way. Even on regular EC2 nodes, node-level proxy configuration only covers processes like the kubelet, and containers don't inherit node environment variables, so pod-level proxy injection needs an admission-time solution regardless of compute type. AWS shows how to use a mutating admission policy from Kyverno, a CNCF graduated policy engine, to automatically inject HTTPS_PROXY, HTTP_PROXY, and NO_PROXY environment variables into every container and init container when a pod is created in a labeled namespace. This means application teams never touch their deployment manifests, and a cluster operations team manages a single policy that applies proxy settings automatically across every opted-in namespace. Because the mutation happens before the object is persisted, it also eliminates the race condition where a container could make a network call before its proxy configuration is applied.
💡 Working around the Fargate node-layer restriction with an admission policy lets clusters that must route all egress through a corporate proxy for compliance keep using serverless compute instead of giving it up for egress control.
Fast model loading for AI inference on Amazon EKS
AWS Containers
AWS reported that two configuration-only changes to Run:ai Model Streamer, no code changes, cut model startup time for AI inference on Amazon EKS by 80-93% on subsequent launches. The team originally expected small chunks (256 MiB) with high concurrency (256 threads) to maximize S3 throughput, but testing showed 256 MiB through 4 GiB all performed within 5% of each other, 256 parallel connections gave no benefit over 17, and going up to 8 GiB chunks caused a 56% regression. The cause was that Run:ai Model Streamer assigns one worker thread per shard file, and within a worker, requests are issued serially with no pipelining. Since most SafeTensors shards are 3-5 GiB, setting chunk size to 4 GiB collapses each shard to a single request per worker and lets concurrency be set to its lowest value. The team also found that about 10% of S3 GET requests take 2-3x longer than the median, and because a model can't be ready until every chunk finishes, a single slow connection can hold up the entire load.
💡 Cutting cold-start time by over 80% through configuration alone, with no code changes, shows teams running GPU inference clusters a low-cost lever to reduce scale-out latency and cost right away.
Platform engineering maturity: From toolchain to self-service
CNCF
The CNCF blog examines a platform engineering maturity model, observing that teams without any platform yet and teams that already have a golden path, developer portal, CLI, and even an AI agent face the same underlying problem: neither knows what the next stage of platform interface should look like. Teams that already shipped a platform often still handle requests outside the golden path by hand, so they believe they've achieved self-service even though their workload hasn't actually dropped. The CNCF Platform Engineering Maturity Model scores five aspects independently: Investment, Adoption, Interfaces, Operations, and Measurement. Each aspect has four levels, Provisional, Operational, Scalable, and Optimizing, and an organization advances through each aspect on its own timeline rather than as a whole. The post argues that most teams plateau unknowingly at Stage 2 (Operational) on the Interfaces aspect, and walks through why that happens and what moving past it looks like.
💡 If a platform team believes it has self-service but still handles off-golden-path requests by hand, that bottleneck is the signal of plateauing at Interfaces maturity Stage 2, so the next investment should go into interface design rather than more capabilities.
Security briefing: August 2026
Sysdig
Sysdig published its August 2026 security briefing. It opens with the framing that AI didn't invent new attacks, it just sped up old ones. The specific cases named in the briefing include attack techniques called ChainDrop and Ghostjacking, plus a case of Claude Code being used in a ransomware operation. The page-level description doesn't detail how each technique works, the scale of impact, or recommended mitigations. The full article body could not be fetched, so this summary relies only on the title and the page's own description.
💡 The mere fact that a coding agent has been used in a ransomware operation is reason enough to re-audit the credentials and execution permissions granted to agents in CI/CD against a ransomware threat model.
Kubernetes v1.37: Storage Version Migration Enabled by Default
Kubernetes
Storage Version Migration (SVM) has graduated to General Availability in Kubernetes v1.37. A built-in StorageVersionMigrator controller in the control plane watches for StorageVersionMigration objects and automatically migrates existing stored resources to that API's default storage version. For example, after updating a CustomResourceDefinition like crontabs.example.com to use v1 as its storage version, applying a StorageVersionMigration manifest with kubectl apply migrates all existing stored instances off older versions. Progress can be checked with kubectl get storageversionmigration, and a successful migration reports a Succeeded condition set to True in status.conditions. Because it's a standard declarative Kubernetes API, CRD authors can bundle the migration directly into the same manifest as their CRD upgrade.
💡 With storage version migration now a GA declarative API, platform teams running CRDs can retire an old storage version safely by folding migration straight into their upgrade manifest instead of writing a separate migration script.
Secure by default is your only way forward
Docker
Docker argues agents need a control surface that legacy security tools were never built for, and introduced a new layer where every agent session runs in its own disposable, MicroVM-based Docker Sandbox. The sandbox walls the agent off from the host at the OS level, proxies in only the credentials a task needs without storing them inside the box, and lets the user decide exactly what gets piped in and out. Docker says its own security team has blocked coding agents on the host entirely and now runs several at once inside sandboxes with full autonomy, since an infostealer landing in one sandbox finds nothing to grab. The MCP (Model Context Protocol) servers agents use to call external tools are built and signed the same way as Docker's hardened images, shipped through the same MCP Catalog and Toolkit, and every tool call is authenticated, authorized, and logged through an MCP Gateway before it reaches an external system. Docker Scout enforces this policy at build time, so the secure path stays the default without anyone having to police it by hand.
💡 Caging agent sessions in MicroVM sandboxes and forcing every MCP call through an authorizing, logging gateway lets teams grant agents full autonomy while keeping the blast radius of an infostealer or an over-privileged MCP server off the host.
OpenTelemetry has graduated… now what?
CNCF
OpenTelemetry (OTel) officially achieved CNCF graduated status in May 2026. According to the CNCF, OTel has logged more than 12,000 contributions from over 2,800 companies and hundreds of maintainers, making it the second-highest-velocity CNCF project behind only Kubernetes. OTel was formed in May 2019 by merging two separate standardization efforts, Google's OpenCensus and the CNCF's OpenTracing, at a time when every telemetry vendor maintained its own instrumentation libraries and switching vendors meant ripping the old ones out of your code. OpenTracing was archived in January 2022 and OpenCensus in July 2023. Since then, traces, logs, and metrics have all reached general availability, profiling was added as a new signal, and the ecosystem has kept expanding with components like OpAMP, the OTel Operator, OTel Weaver, and OTel Arrow, which the post calls an impressive achievement for a project that's only seven years old.
💡 A standard that ended the era of vendor-locked instrumentation libraries now growing faster than anything in the CNCF except Kubernetes means the ecosystem risk of migrating an observability stack still tied to vendor-specific SDKs onto OTel has dropped sharply.
Observability in Kubernetes: From metrics to meaning
CNCF
A CNCF blog post argues traditional monitoring only answers predefined questions, like whether CPU crossed a threshold or memory is rising or error rates are climbing, but Kubernetes incidents increasingly emerge from interactions between components rather than one obviously broken host. A rollout can look healthy at the deployment level while still causing latency through a downstream dependency, a noisy retry loop, or an overloaded control-plane path. The CNCF defines observability as covering the instrumentation, collection, processing, storage, querying, curation, and correlation of telemetry, metrics, logs, traces, and profiling, for cloud-native workloads, framing it as a design property of the system and an operating model for the team rather than one tool or dashboard. It argues a system is observable when it exposes enough high-quality signals that engineers can infer internal behavior from external outputs, turning incident response into a guided investigation instead of a guessing exercise. Metrics get adopted first because they're cheap and numerical, and in Kubernetes they answer the first operational questions, such as node pressure, pod restarts, or API server latency, giving teams the first sketch of a problem.
💡 Drawing a clear line between monitoring and observability pushes Kubernetes teams to invest in correlating logs, traces, and profiling rather than just adding more metric dashboards, which is what actually shortens incident investigation time.
Defending the battlefield: Stateful detections for an agentic threat landscape
Sysdig
Sysdig cites a case where, it says, the first agentic ransomware operation autonomously ran a destructive database extortion playbook, and argues runtime security is becoming an increasingly important safety net that enables fast automated response. Traditional detection engines evaluate events in a vacuum, so flagging that a terminal shell opened in a container can't tell whether a developer is debugging or an attacker has broken in, leaving a security engineer to manually cross-reference other alerts. Stateful detections instead track a chain of events, such as opening a shell, downloading a binary to /tmp, and then executing it, where each step alone might be routine but the sequence together is almost certainly an attack. Sysdig's Falco agent implements this through an extension called observations, linking related events by fields like process session ID (obs_link_fields) and using obs.occurs and obs.link conditions to detect when, say, a package-manager install follows a shell spawn within the same session. According to Sysdig's 2026 cloud-native security and usage report, 70% of organizations now use stateful detections, and those that have adopted them apply them across 91% of their cloud environments.
💡 Moving from single-event rules to stateful detections that track event chains lets runtime security teams cut the manual triage time spent telling a developer's normal debugging shell apart from an actual attack chain, lowering alert fatigue.
AI & ML
The latest AI news we announced in August 2026
Google AI
This is Google's roundup of everything it shipped in AI during August 2026, headlined by Gemini 3.7 Flash, a new lightweight coding-and-agents model launched at introductory pricing half the cost of the prior 3.6 Flash. The same period brought Gemini 3.5 Transcribe for speech-to-text and Gemini Omni 1.1 Flash, a studio-quality video generation tool with 4K upscaling. The cyclone-prediction model WeatherNext 2 was open-sourced to the research community, and the Pixel 11 lineup, including the Pixel 11, 11 Pro, 11 Pro XL, and 11 Pro Fold, launched with Google's Tensor G6 chip. Google also introduced a free one-year Google AI plan for eligible college students, while the Gemini app passed 1 billion monthly users, generates more than 150 million images a day, and the Gemma model family surpassed 1 billion downloads. The recap also covers Operation Blue Skies, a partnership aimed at reducing aviation contrails.
💡 The half-price launch of Gemini 3.7 Flash and the open-sourcing of WeatherNext 2 mean teams running coding/agent workloads or forecasting pipelines now have an immediate lever to cut inference cost by switching models.
Mapping global methane emissions from space with deep learning
Google Research
Google Research and NASA's Jet Propulsion Laboratory built a deep learning model, based on a Swin-S vision transformer, to detect methane plumes in hyperspectral imagery from NASA's EMIT instrument aboard the International Space Station. EMIT observes Earth's surface at 60-meter spatial resolution and 7.4 nanometer spectral sampling, and the model processes the full spectrum alongside spatial context instead of analyzing pixels individually, which helps filter out false positives. To work around the lack of a real-world labeled dataset, the team trained on 3.6 million synthetic methane plumes generated with Lagrangian puff models and injected into real EMIT scenes. The result was 84% recall on expert-annotated plumes, roughly 50% more plausible plumes identified across about 1,100 EMIT granules, and detections at 24 of the world's 25 top-emitting landfills. The model simultaneously performs enhancement quantification, plume delineation, and source localization, which lets it separate overlapping plumes in dense industrial regions.
💡 The success of training on synthetic data to overcome a lack of real-world labels is a useful precedent for infrastructure teams who need to train observability or anomaly-detection models in domains where real labeled data is scarce.
How AI-native companies turn workflows into operating capability
OpenAI
The piece covers three companies: Basis, Clay, and Exa Labs. They use AI agents to improve onboarding, account management, and developer integrations. The headline frames this as AI-native companies turning workflows into operating capability. The title and excerpt don't specify which agents each company deployed, how, or by how much any metric improved. The article body could not be fetched (HTTP 403), so this summary relies only on the title and excerpt.
💡 Even at this level of detail, the fact that onboarding, account management, and developer integration were the workflows chosen for agents suggests these repetitive operational workflows are a validated starting point for agent adoption.
Try Google Pics: Easy image creation and editing in Google Workspace
Google AI
Google introduced Google Pics, an image creation and editing tool built on its latest Nano Banana image model. It generates images from text prompts with multiple output options, can isolate and transform a specific object in an image without affecting the rest, and can modify or translate text inside an image without disrupting the design. A collaboration feature lets teammates work on shared image edits together. It's rolling out over the coming weeks to all Google AI Pro and Ultra subscribers and most Workspace business customers, launching with immediate integration into Docs and Slides while Drive integration arrives later. It's available both standalone at pics.new and inside Workspace apps.
💡 Being able to translate or edit text inside an image without breaking the design means teams maintaining multilingual marketing assets or documents can finish localization work directly inside Workspace without a round trip through a separate design tool.
Path to Astra: critical capabilities and frontier safeguards
OpenAI
OpenAI released a model called Astra. It says Astra is the first model to cross the Critical cybersecurity capability threshold defined in its Preparedness Framework. Because of that, the release ships with strengthened safeguards, according to the announcement. The title and excerpt don't specify which capability tests were crossed or exactly what the new safeguards are. The article body could not be fetched (HTTP 403), so this summary relies only on the title and excerpt.
💡 A model crossing a self-declared critical cybersecurity capability threshold means teams granting it API access should apply stricter access controls and usage monitoring than they would for a prior-generation model.
Healthcare organizations can now connect EHR and additional industry data to ChatGPT
OpenAI
OpenAI announced a new capability. ChatGPT can now connect to trusted healthcare data sources. The company frames this as helping clinicians securely access patient context and medical research. The headline references connecting electronic health record (EHR) and other industry data sources, but the title and excerpt don't name the specific EHR systems, partners, or security and compliance measures involved. The article body could not be fetched (HTTP 403), so this summary relies only on the title and excerpt.
💡 If ChatGPT is connecting to EHR data in clinical settings, platform teams at adopting healthcare organizations need deployment policies covering PHI access boundaries and audit logging before rollout.
Introducing @huggingface/kernels: 200+ WebGPU Kernels for Local AI
Hugging Face
Hugging Face released @huggingface/kernels, a library and an initial collection of 207 optimized WebGPU kernels for running AI in the browser. Each kernel is published as its own Apache-2.0 licensed repository under the webgpu-kernels organization, bundling its interface, shader templates, correctness tests, benchmark cases, and usage instructions together. The library itself is a JavaScript loader that downloads, prepares, and runs these kernels directly from the Hugging Face Hub. Alongside it, Hugging Face launched Fleet, an in-browser GPU benchmarking and testing tool that, with user consent, crowdsources correctness and performance evidence across real-world hardware the team could never cover in its own test lab. Hugging Face frames this as the first layer of a broader, multi-layer effort to make browser-based AI inference faster and easier to use.
💡 Bundling correctness tests and benchmark cases with every kernel gives teams serving models in the browser a reproducible performance baseline without having to verify GPU-specific regressions themselves.
TimesFM-3: A zero-shot foundation model for multivariate forecasting
Google Research
Google Research released TimesFM-3, a multivariate time-series forecasting foundation model. It takes past-future covariates, like a planned promotion schedule, as known future signals, and its alternating attention layers fill in all masked horizon patches at once with no iterative loop. In a sample ice cream sales scenario, feeding in the promotion schedule as a past-future covariate let the multivariate mode anticipate roughly a 20% sales bump on each promotion day, producing a more accurate full-month forecast than a standard univariate model that ignores the schedule. Each forecast produces 9 quantiles spanning the 10th to 90th percentile, giving a full probabilistic view of forecast uncertainty. Across three public benchmarks, Gift-Eval, FEV-Bench, and Time, TimesFM-3 ranked first among all pre-trained foundation models on both point and probabilistic forecasting metrics, including against Chronos-2, the Toto 2.0 family, and its own predecessor TimesFM-2.5, and its univariate mode alone already matched or beat competing models.
💡 Being able to feed already-known future signals like a promotion schedule into the forecast as a covariate shows infrastructure teams building capacity-planning or autoscaling policies a direct way to incorporate scheduled events into their traffic forecasts.
Cloud Updates
What Google Cloud announced in AI this month
Google Cloud
This is Google Cloud's monthly recap of AI announcements for August 2026. CodeMender, a tool that automatically finds and fixes security vulnerabilities in code, moved into preview, while AlphaEvolve, a Gemini-based code optimization and discovery agent, became generally available to all Google Cloud customers. The Gemini Enterprise Agent Platform opened up previously popular capabilities, including Agent Runtime and Agent Identity, to general availability, and this month's recap adds 13 hands-on demos and 20 diagnostic questions to help teams settle on an architecture. New customers get $300 in free credit to validate a prototype, plus free monthly usage of more than 20 products including AI APIs. The recap also introduces Agent Valley, a free five-week live learning series for building agent systems from scratch.
💡 The general availability of AlphaEvolve and the CodeMender preview mean teams can now start experimenting with delegating code optimization and vulnerability patching to AI agents on Google Cloud without upfront cost.
How Blackline simplifies perimeter policy intelligence with VPC Service Controls
Google Cloud
Google Cloud added two new policy intelligence tools to VPC Service Controls (VPC-SC): a Violation dashboard and a Violation analyzer. The dashboard aggregates and visualizes service perimeter violations across an entire organization in one pane of glass, with filters by specific perimeter, project, or identity to spot trends and spikes. The analyzer takes a troubleshooting token or denial ID from the dashboard and maps out the identity, source, target, and triggered VPC-SC rule without requiring a manual Cloud Logging SQL query. Customer BlackLine reported that the tools noticeably cut mean time to resolution (MTTR) for service perimeter issues. Both tools cover the full VPC-SC lifecycle, from testing new perimeters in a dry run to real-time monitoring, incident triage, and policy rule refinement.
💡 By mapping violation causes without a manual Cloud Logging query, the analyzer can cut incident response time and on-call burden for security teams operating data-exfiltration perimeters.
Introducing TabFM in BigQuery: Predictive analytics reimagined
Google Cloud
Google Cloud added TabFM, a tabular foundation model, to BigQuery, letting teams run predictive analytics on structured data with a single SQL statement. Instead of fitting parameters through traditional training, TabFM uses in-context learning similar to how LLMs learn from few-shot prompts, reading the training table as context and generating predictions for the target table in a single forward pass. The AI.EVALUATE function returns standard metrics in one step, such as r2_score and mean absolute error for regression or precision, recall, and F1 for classification. To handle the computational load, BigQuery runs distributed, parallelized inference with intelligent training-data sampling, so it can process millions of rows of predictions quickly. Google recommends TabFM for small-to-medium or frequently changing datasets, frequent retraining needs, and conversational or agentic workflows, and recommends traditional models like XGBoost for very large datasets or when feature-importance explainability is required.
💡 Being able to run a prediction model with one SQL statement means teams can prototype predictive analytics directly inside BigQuery without standing up separate ML infrastructure or retraining pipelines, cutting data-platform operating overhead.
Hybrid cloud orchestration: Modernizing on-premises infrastructure management with AWS
AWS Architecture
AWS published Part 1 of a hybrid cloud orchestration architecture for managing on-premises infrastructure across hundreds of distributed sites. Hardware is managed through vendor-agnostic Redfish APIs, with EKS Anywhere Kubernetes clusters, both management and workload clusters, providing the compute, storage, and networking foundation for containerized workloads on top. At the center is an Inventory Management System built on DynamoDB tables that acts as the single source of truth for sites, hardware (including BIOS and firmware versions and encrypted credentials), network details, clusters, and trackable infrastructure lifecycle operations called Orders. When an operator requests an action, such as rebooting every server at a site, an Order with a unique ID is created, and the resulting event is routed by Amazon EventBridge to the matching AWS Step Functions workflow, which updates progress as state changes occur. The API layer exposes CRUD operations through Amazon API Gateway, with Lambda functions validating requests and integrating with the order management system. This gives operators a self-service portal to perform lifecycle operations without needing CLI access or direct API knowledge.
💡 A single DynamoDB-backed inventory with event-driven orchestration lets teams scale repetitive operations like server reboots across hundreds of sites as an auditable self-service flow instead of someone SSHing into boxes one at a time.
MCP went stateless: Is your AWS MCP server deployment well-architected?
AWS Architecture
On July 28, 2026, the Model Context Protocol (MCP) specification made its protocol core stateless, removing the initialize handshake and session header. AWS maps this 2026-07-28 spec to the AWS Well-Architected Agentic AI Lens pillar by pillar, arguing that the stateless design eliminates both the cost of always-on session infrastructure and the over-provisioning needed for bursty agent traffic. Long-lived streams didn't disappear entirely though: the subscriptions/listen method consolidates change notifications into a single opt-in POST-response stream, so teams still need to check idle timeouts across their load balancer, proxy, and compute tier. The spec deprecated Roots, Sampling, Logging, and the HTTP+SSE transport with a twelve-month floor before removal, meaning the earliest any of them can be removed is July 2027, while it removed ping, logging/setLevel, and notifications/roots/list_changed outright. Setting cacheScope to public on a response carries a multi-tenant disclosure risk, letting a shared cache serve one tenant's data to another, so AWS recommends defaulting to private and widening only for responses that are genuinely identical across callers.
💡 The shift to stateless MCP removes a whole category of always-on session-infrastructure cost for bursty agent traffic, but carelessly setting cacheScope to public opens a new multi-tenant data-leak path that needs review before deployment.
How we could save petabytes of cache storage with Zstandard and Pingora
Cloudflare
Cloudflare described a prototype called Cache Transcoding that compresses objects inside its cache layer to see whether the same hardware could hold more cached content. The prototype only transcodes 200 OK responses with no Content-Encoding set, compressible text content, and a known Content-Length of at least 4 KiB, leaving slice subrequests, already-compressed responses, and binary content untouched. The 4 KiB threshold was chosen because it excludes only about 1% of otherwise eligible bytes while removing per-object overhead on tiny requests. In a performance test that sent over a million requests across 10 cache servers, two test assets of about 195 KiB and 272 KiB each compressed by roughly 2.8x using zstd. Cloudflare notes the test corpus was deliberately compression-friendly, so that ratio shouldn't be treated as a fleet-wide constant for every text object on the internet.
💡 Achieving a roughly 2.8x compression ratio on the same cache hardware via zstd transcoding shows teams running CDN or edge caches a way to improve hit rate and storage cost without adding cache capacity.
5 ways to augment security risk management in the AI era
Red Hat
Red Hat notes that IT operations and security teams receive thousands of alerts a day from sources like vulnerability scanners, observability tools, and Red Hat Lightspeed, and offers five ways to strengthen security risk management in the AI era. Citing IBM's X-Force Threat Intelligence Index 2026, it points out that scanning for vulnerable software is the second most common attack vector, behind only exploiting misconfigured access controls. Event-Driven Ansible can respond to SIEM alerts the moment they arrive, running either an automated remediation step or a human-in-the-loop review that covers fact-gathering, containment, patch application and validation, and ITSM ticket generation. On RHEL, Red Hat Lightspeed pinpoints which systems need patches and supplies matching Ansible Playbooks, while on other platforms teams can use Ansible Automation Platform's coding assistant together with MCP server integration to generate automation and patch at scale. The post lays out closing the gap between mitigation, patching, validation, and verification as a short-, medium-, and long-term three-phase path.
💡 Wiring SIEM alerts directly into Event-Driven Ansible for automated containment and patching is a concrete way to shorten patch cycles even as exploitation now outpaces manual response.
Why the virtualization decision keeps getting deferred
Red Hat
Red Hat identifies the most common reason virtualization migrations stall as the first-year cost overlap of paying for both the old and new platforms during the transition. Many infrastructure teams have spent nearly two years evaluating alternatives, and the decision keeps getting deferred because it now competes with AI initiatives for the same budget and people in the same cycle. As a fix, Red Hat waives the first year of Red Hat OpenShift Virtualization subscription cost on a qualifying 3-year agreement, which removes only that cost overlap, not hardware, migration work, or training costs. To evaluate this, teams can run the free, self-serve Red Hat OpenShift migration advisor against their environment, and if warranted, follow up with a paid, two-week Virtualization Migration Assessment delivered by Red Hat Consulting or a partner, whose cost is credited back against subscriptions if the team proceeds. Because OpenShift Virtualization runs VMs on the same platform and operating model as container workloads, it leaves room to expand into containers, hybrid cloud, AI, or edge later, unlike simply swapping one hypervisor for another.
💡 Recognizing that this offer removes only the first-year double-cost barrier lets infrastructure teams treat it purely as a pricing lever while deciding migration scope and pace independently, based on their own assessment.
How Ask Red Hat earns trust in enterprise AI troubleshooting
Red Hat
Red Hat cites a review of 562 empirical studies on human trust in AI finding that capability, explainability, transparency, and individual user factors consistently predict whether people rely on an AI answer, and says Ask Red Hat was built specifically to solve that trust problem. Ask Red Hat is a conversational AI embedded across Red Hat's websites that isn't meant to match the breadth of frontier models, but instead aims to be the best Red Hat expert you can verify, drawing on more than a million pieces of Red Hat expertise. Internally, the team separated skill routing from answer generation so routing accuracy and answer quality can be evaluated independently rather than debugged as one black box. Rather than collapsing trust into one aggregate confidence metric, which would blur the difference between a low-risk lookup and a question that could affect production, Ask Red Hat instead surfaces sources to verify and clear warnings when stakes are high. Anyone with a Red Hat subscription, including the no-cost developer subscription, can try Ask Red Hat today, and thumbs up/down feedback on each answer goes directly to the team for improvement.
💡 Separating skill routing from answer generation for independent evaluation lets teams running internal support chatbots debug retrieval problems separately from generation problems, shortening MTTR on accuracy issues.
Introducing Azure Multicloud Interconnect for AWS
Azure
Microsoft and AWS jointly announced Azure Multicloud Interconnect, using a standardized Open API specification to give customers dedicated private connectivity between Azure and AWS through a simplified experience. Previously, assembling multicloud connectivity meant physical connectivity, routing configuration, provisioning coordination, monitoring, and lifecycle management done manually across multiple providers, and this service abstracts that complexity away. Azure Multicloud Interconnect extends to Azure Private Link to provide high-capacity private connectivity, designed for training and inference workloads that need to access data distributed across cloud boundaries. Microsoft pairs it with AWS's own AWS Interconnect-multicloud and highlights built-in MACsec security, four-nines availability, and scalability at the click of a button. Both companies frame this as a step beyond a single cloud-to-cloud relationship, toward broader interoperability across hyperscale cloud providers using the same open API specification.
💡 Two hyperscalers standardizing dedicated private connectivity on the same open API spec means network teams running multicloud architectures can drop much of the manual dedicated-line and routing work they used to assemble themselves.
Inside Microsoft’s marketing team: Scaling expertise with AI
Azure
Microsoft describes how its marketing organization used Microsoft Foundry, its platform for building and managing enterprise AI applications, to create agents grounded in business knowledge and embedded in the flow of work. The core lesson was that AI is only as good as the data it can reach, so the team used Microsoft IQ to connect agents to information scattered across documents, workflows, business systems, and communications, instead of asking employees to assemble it themselves. The marketing team reviews and publishes more than 200 blog posts a year, and a small number of subject matter experts were spending much of their time reapplying the same review criteria over and over. To cut that load, one content lead documented and refined the rubric she already used to judge a strong blog post, so drafts no longer needed review from scratch every time. The piece argues the real breakthrough wasn't any single agent but making a successful agent or AI skill from one team reusable by others across the organization.
💡 The fact that reusability across teams, not any single agent, was the real breakthrough means an internal platform team should prioritize a shared, reusable agent catalog over supporting one-off agent builds if it wants adoption to scale.
Introducing Adaptive Intelligence: Undermining the economics of every bot attack
Cloudflare
Cloudflare introduced Adaptive Intelligence, a bot detection system built to reverse the economics of every bot attack. It argues that rule-based detection is deterministic, always producing the same output for the same input, which lets attackers learn the system's edges through repeated automated probing until they find a way through. The most sophisticated attackers spread requests across a large residential proxy network, keep each address's rate low, and rotate user agents or bot fingerprints, so a login, checkout, or account-recovery flow gets through without any single source crossing a rate limit. Adaptive Intelligence aims to flip that economics by satisfying two conditions at once: making it cheaper for the defender to react than for the attacker to work around, and starving attackers of the feedback they'd otherwise use to adapt. Cloudflare claims no other bot detection works this way, and frames the goal not as blocking every attacker outright but as making an attack slow and costly enough that it stops being worth running.
💡 Starving attackers of the feedback their automated probes rely on is a structural way for teams that have depended on deterministic, rule-based WAF or bot defenses to escape a rule-update arms race they were always going to lose.
DevOps & Infrastructure
Claude Fable 5.1 watermark: It has a blind spot developers can’t ignore
The New Stack
Anthropic embedded a statistical watermark, a statistical signature, into the text generated by Claude Fable 5.1, launched on a Tuesday. That watermark does not apply to code tokens, because watermarking code could break its accuracy. The same release added a new API restriction aimed at large-scale model distillation. The headline frames this watermark gap as a blind spot developers should not ignore. The full article body could not be fetched, so this summary is based only on the title, excerpt, and page description.
💡 Because code tokens are excluded from the watermark, any deployment pipeline relying on text watermarking to trace or detect AI-generated code cannot assume that guarantee holds on the code path.
Runway wants to generate software as you use it. Solaris is its first step.
The New Stack
Runway introduced Solaris on Monday. It's described as the first model in a new class of AI systems the company calls Interface World Models. According to the announcement, the model turns the visual itself into the application, rather than just rendering a static screen. The idea is that what you see on screen becomes something you can directly interact with, not just an image generated from a prompt. The full article body could not be fetched, so specifics on implementation, benchmarks, or release timing are not confirmed, and this summary relies only on the title, excerpt, and page description.
💡 If the 'the visual is the application' concept holds up, teams running frontend deployment pipelines or UI-generation automation should expect the usual boundary between rendering and deployment to blur.
Anthropic’s Fable 5.1 is a bit cheaper, a bit smarter, and refuses a lot less
The New Stack
Anthropic launched the latest versions of its flagship models on a Tuesday, Fable 5.1 and Mythos 5.1. Pricing stayed at Fable's existing $10 input / $50 output per million tokens. Cache read costs were cut by 75%, lowering the effective cost for workloads that make heavy repeated calls. Anthropic also retuned the safeguards that had previously caused Fable 5 to punt certain requests to Opus. The full article body was not available, so these details are confirmed only at the title, excerpt, and page-description level.
💡 The 75% cut in cache-read pricing directly lowers real-world API cost for workloads with long or repeated prompts, meaning teams running Fable 5-based pipelines should recompute their cost baselines.
Secure mainframe access with HashiCorp Boundary
HashiCorp
HashiCorp announced Boundary integration for mainframe access. Traditional mainframe access relies on long-lived shared usernames, passwords, and SSH keys with limited rotation, which fragments audit trails and expands the attack surface through VPNs and jump hosts. Boundary replaces that with identity-based access control through OIDC providers like Okta and Ping Identity, policy-controlled target access, and just-in-time credential injection for SSH and TN3270 sessions. It supports three mainframe access paths, HTTPS for the HMC, SSH for z/OS, and TN3270/TN3270E, and integrates with HCP Vault Dedicated, HashiCorp Vault Enterprise, and IBM Vault Self-Managed for Z and LinuxOne. The deployment model runs a mainframe-adjacent worker on a Linux VM on the same network as the mainframe, which opens an encrypted outbound connection to the control plane and proxies authorized sessions to the targets, with every session recorded and logged centrally to close the audit-trail gap that shared credentials created.
💡 Applying OIDC-based identity control and session recording to mainframe access lets z/OS and HMC operations teams move off shared accounts and get per-user audit and compliance evidence.
HashiCorp Vault agentic IAM is now generally available
HashiCorp
HashiCorp Vault's agentic identity and access management (IAM) capabilities are now generally available. First announced in public preview in June 2026, the feature reaches GA in Vault Enterprise 2.1 and extends Vault's existing human and non-human identity management to cover AI agent identities as well. Agents authenticate with signed OAuth JWTs carrying an authorization_details claim, which Vault validates and checks against authorization controls. New capabilities include an Agent Registry UI that shows agent identities, authentication activity, and policies in one view, and Rich Authorization Requests (RAR), built on IETF RFC 9396, which enforce fine-grained, per-request authorization. On-Behalf-Of (OBO) workflows let agents act for a user by validating delegated OAuth JWTs, and new Terraform resources, vault_agent_registration and vault_oauth_resource_server_config_profile, let teams manage this as code. Integration with identity providers including IBM Verify, Auth0, PingFederate, Microsoft Entra, and Okta has also been validated.
💡 Folding agent identities into Vault's existing IAM model lets operations teams audit and constrain AI agent permissions within their existing secrets and access policies instead of building a separate agent-identity system from scratch.
Bringing the Most Advanced Sampling to the OpenTelemetry Collector
Honeycomb
Observability platform Honeycomb is donating its adaptive tail sampling processor, built on years of experience running its open source tail sampling proxy Refinery, to the OpenTelemetry Collector. Sampling is a skill every team running an observability pipeline at scale eventually has to learn, trading off bandwidth, CPU, and memory against cost and backend performance. Historically there were only three sampling mechanisms; adaptive tail sampling is presented as a fourth option that changes those tradeoffs by keeping important context during traffic spikes without blowing the budget. The donation also includes trace fingerprinting and sample-rate attribution, so teams can trace which trace patterns were sampled at what rate. It's available to try today through the Honeycomb Collector Distribution.
💡 With adaptive tail sampling and sample-rate attribution landing in the standard OTel Collector, teams can manage trace budget and context retention together without a vendor-specific sampling proxy, directly lowering observability pipeline cost.
Making Rust observability reliable at scale with OpenTelemetry
Datadog
As Datadog built more production services in Rust, tracing became the part of its observability stack that most needed to evolve, since different teams used different libraries, context propagation varied by which crates were in the request path, and sampling decisions depended on local configuration rather than end-to-end behavior. Datadog collects more than 100 trillion events a day, and that inconsistency got worse as Rust adoption grew for performance-sensitive infrastructure. Many teams had bolted OpenTelemetry exporters onto the tracing crate, a popular structured logging library, which meant tracing-based and OpenTelemetry-based instrumentation mixed within the same request path and fragmented traces on export. To fix this, the Datadog APM team contributed upstream to OpenTelemetry and built an opinionated Rust tracer, dd-trace-rs, on top of it. The post walks through the design trade-offs around propagation and sampling and the lessons learned operating Rust service tracing in production.
💡 Fixing trace fragmentation at Rust service boundaries by standardizing on one opinionated tracer is a reminder that per-language instrumentation fragmentation in a polyglot microservice fleet should be treated as an observability cost problem, not just a library choice.
From traces to experiments: A loop for improving AI agents
Datadog
Datadog frames the problem with an example: a support agent shipped last quarter demoed well, but months later summaries of long conversations started truncating and monitors showed latency spikes on billing API tool calls. Teams' first instinct is usually to tweak prompts or upgrade the model, but even when performance seems to improve afterward, they can't tell why it helped or whether it will hold as traffic changes. The issue isn't a lack of telemetry, Datadog argues, since teams building agentic systems typically capture more trace data than they can possibly review, but lack a repeatable way to find where an agent underperforms and to measure whether a change actually improves the outcome. The post covers reading agent traces as a roadmap for where to invest, why teams should run both evaluations and experiments, and how to combine them into an optimization loop. As an example, it shows traces linked to evaluation scores turning a vague concern into a specific, testable claim, such as a summarization prompt underperforming on threads over 15 messages where those tickets reopen at twice the normal rate.
💡 Linking traces to evaluation scores to produce testable claims moves agent operations teams away from tweaking prompts or models by feel and toward confirming with experiments whether a change actually holds.
Visualize how CUPED adjusts experiment results with Datadog
Datadog
CUPED (Controlled-experiment Using Pre-Experiment Data) is a technique that uses pre-experiment data to reduce metric variance and get precise experiment results with less data. However, the gap between an experiment's CUPED-adjusted lift and its raw lift can be hard to explain when many pre-exposure metrics and subject properties are involved. The new CUPED adjustments visualization in Datadog Experiments breaks that gap down into a sequence of specific, visualized adjustments. It connects each metric lookback or assignment property to an upward or downward adjustment in the estimated lift, making it clear at a glance which covariates had the greatest influence. This lets teams understand why CUPED changed their lift estimate, trace each adjustment through a CUPED waterfall, and interpret the result with more context.
💡 Breaking the CUPED adjustment gap down by covariate reduces the risk that a team running an experimentation platform distrusts its own lift numbers simply because it can't explain where they came from.
Testing cookie behavior across hundreds of web surfaces with our in-house auditor
Dropbox
Dropbox says it built a cookie auditor that uses Playwright browser automation to behave like a real visitor, checking cookie behavior across hundreds of Dropbox web pages to make sure they only load cookies consistent with a visitor's stated preferences. It kept the list of approved cookies and known exceptions outside the auditor's source code, so the Privacy team can update classifications without waiting on engineers to change code and ship a release. Because Dropbox built its own cookie banner instead of using an off-the-shelf product, it could integrate the auditor directly with its existing consent infrastructure, making it easier to adjust what gets tested as services and regulations change. For every page, the auditor runs three separate tests in a fresh, isolated browser session, simulating a standard US visitor, an EU visitor, and a visitor sending a Global Privacy Control (GPC) signal, and first records which cookies load before anything is clicked. It then finds the page's consent controls, which can appear as a banner, a floating control, a preferences window, or a footer link across 22 supported languages, declines non-essential cookies, and reloads the page to see what happens next.
💡 Pulling the cookie allowlist out of source code and auditing it automatically with Playwright is a pattern for folding privacy compliance, which manual QA can't keep up with at web scale, directly into CI.
Fin's CTO on Building Great Engineering Organizations in the AI Era
Honeycomb
Darragh Curran, CTO of Fin (formerly Intercom), set a public goal to double engineering productivity and ended up nearly tripling it instead. Honeycomb co-founder Charity Majors invited him onto the first episode of a new video series, Leading With Observability, to discuss AI writing code at scale, building an AI-driven PR review system, and leadership becoming more hands-on through that transition. Curran describes observability as the trust mechanism that makes all of that work. He contributed a chapter on leadership to the book Observability Engineering, which he sums up as a simple loop: do a thing, learn something, do the next thing. The video is the first episode of a series designed to run around 15 minutes each.
💡 Putting observability in place as the trust mechanism before leaning on AI-driven PR review suggests engineering orgs trying to scale code output with AI should invest in observability alongside, not after, that productivity push.
Optimize EKS operations with agents: Reduce MTTR with AWS DevOps Agent and a Kubernetes Operator
AWS DevOps
AWS argues that the data-collection phase of responding to EKS failures like OOMKilled or IP exhaustion is pure overhead on mean time to resolution (MTTR), since the incident stays open while an engineer manually gathers data a machine could capture instantly. Existing AI tools fall short: K8sGPT only analyzes current resource state, and Amazon Bedrock Agents requires manual tool integration and pipeline setup, so neither provides end-to-end automated incident investigation. The post introduces the DevOps Agent Operator, a Kubernetes Operator that automatically triggers AWS DevOps Agent, a frontier agent that connects code repositories, observability tools, CI/CD pipelines, and skills to autonomously analyze root causes, through a webhook. The Operator matters because Kubernetes keeps events for only about an hour, restarted containers overwrite their logs, and deleted pods lose them entirely, so evidence is gone for good if nothing captures it right after a failure. It retries S3 or CloudWatch Logs uploads with exponential backoff on failure, uses a single reconcile worker and a processed annotation so a mass failure of, say, 100 replicas crashing at once is handled one pod at a time without duplicate reports, and lets WEBHOOK_MIN_SEVERITY and WEBHOOK_SKIP_CATEGORIES environment variables narrow which failures trigger an investigation.
💡 Having an Operator automatically capture Kubernetes events and logs before they vanish within an hour removes the evidence-gathering time on-call engineers used to spend, genuinely shortening MTTR while also preventing an alert storm during a mass-failure event.
곧, if(kakao)26의 이야기가 시작됩니다.
카카오
This is Kakao's teaser post for its tech conference, if(kakao)26. The slogan this year is Intelligence in every connection. Kakao frames the conference as a place to share the struggles and questions it faced while building technology. It adds that the conference also shares the experience and discoveries gained along the way. The specific schedule, venue, session tracks, speakers, and registration details are not confirmed in this teaser's title and excerpt. The full article body could not be fetched, so this summary relies only on the title and excerpt.
💡 Since this is only a teaser with no schedule or sessions confirmed yet, cloud or DevOps teams weighing attendance should wait for the official if.kakao.com announcement before deciding based on actual session tracks.
같은 장애를 두 번 겪지 않기 위해, 배포 전에 리뷰합니다 — KRIS 개발기
카카오
This post is a KRIS development diary that follows up on an earlier Kakao post evaluating the response quality of its internal AI code review service, CodeBuddy, using LLM as a Judge. As the title suggests, the core goal is to review code before deployment so the same incident doesn't happen twice, and KRIS appears to be the system built around that pre-deployment review. The post says it picks up from the natural next question that came up after the team had set up its evaluation framework. However, what KRIS actually does, how the pre-deployment review works in detail, and how it relates architecturally to CodeBuddy could not be confirmed, since the article body could not be fetched. This summary relies only on the title and excerpt.
💡 The stated goal of using pre-deployment review to stop the same incident from recurring backs up treating incident-recurrence rate as a core metric for any internal deployment gate.
This digest was collected from RSS feeds and summarized by AI (Claude). See the original links for full details.