Worth Reading 071526


Reports of AI corporate implementation failures have continued to mount over the last year.

 


AI assistants now hand you a single, ready-made answer, and a harder question comes with it: who decides what we get to know, and what never makes it into the reply?

 


Vendors are trying to position “confidential computing” as the technical backbone of Europe’s sovereign cloud ambitions. But new research shows that a security protocol used to prove cryptographic trust in the system may have a fundamental architectural flaw.

 


The Internet should stop asking only who was in the room. It should ask who can bind the party bearing the loss.

 


America won’t beat China by banning AI. We’ll win by building the world’s best open models and letting innovation—not government—lead the way.

Content: New Parameter in Multiple something_config Ansible Modules

Last December, I wrote a pretty ranty post explaining how Ansible release 12 broke (some?) network device configuration playbooks. The inevitable anonymous troll (why are they always anonymous?) couldn’t resist asking whether I opened an issue on GitHub. I didn’t (more about that later), but when the solution to that rant was “we’re deprecating using templates in src” parameter, I opened an issue arguing why that’s not a good idea.

Read more …

What happens when your VPN meets 200 AI agents

Providing secure access for your human staff is no simple task. For one, traditional VPNs often grant unnecessarily broad access, so you may have replaced that aging technology with a newer zero-trust network access (ZTNA) solution. And you may have hammered your human-centered privileged access management (PAM) tools into working order, so your engineers are just as happy as your security auditors. But what happens when you add dozens or hundreds of AI agents to the equation? We know that today’s enterprise is racing to become agentic. Or what if you want to run continuous integration (CI) and continuous deployment (CD) jobs? After all, you want a modern DevOps stack! You’ll learn quickly that the tools you built and tuned for human access come up short. Checking identity upfront isn’t enough to securely control access. You need to be able to tailor access based on need, not merely identity. And you’ll need to be able to revoke access when work is completed and provide an audit trail to boot. Even more, you don’t want to run separate access architecture for humans and agents.  To support both human and agentic network access, companies need a unified architecture that can handle Continue reading

Source Specific Multicast (SSM) VII

Source Specific Multicast (SSM) VII

In this post, we will look at Source Specific Multicast, or SSM. This is a different approach to multicast that simplifies the overall architecture by removing the need for an RP entirely.

In the previous posts, we covered PIM Sparse Mode, where receivers join a shared tree rooted at the RP and then optionally switch to the shortest path tree toward the source. We also looked at Auto-RP and BSR, which solve the problem of dynamically distributing RP information to all routers. SSM takes a different approach by eliminating the shared tree concept altogether.

Multicast PIM Sparse Mode
Sparse Mode only sends traffic to parts of the network that explicitly request it. Routers with interested receivers send Join messages toward

Any Source Multicast (ASM)

Before we look at SSM, let's briefly talk about Any Source Multicast, or ASM. This is the traditional multicast model we have been using throughout this series.

With ASM, receivers join a multicast group without specifying a source. They simply say 'I want traffic for group 239.1.1.1' and the network figures out how to deliver traffic from any source sending to that group. This is why it is called Any Source Multicast.

Continue reading

NB582: Infoblox Adds Network Observability with Kentik Buy; Satellite Data Centers vs. the Environment

Take a Network Break! We start with a critical vulnerability in Adobe Coldfusion. On the news front, Infoblox acquires Kentik to add network observability to its portfolio, data center electricity consumption jumps worldwide, and Exabeam rolls out AI-agent focused detection in its Agent Behavior Analytics platform. DriveNets and WhiteFiber connect two AI data centers over... Read more »

Introducing Precursor: detecting agentic behavior with continuous client-side signals

Bot mitigation is an adversarial game: attackers adapt, defenders respond, and the cycle continues. At Cloudflare, we stay ahead by combining visibility across our global network with signals from the client-side environment. At the network level, we analyze over 1 trillion requests per day to understand reputation, patterns, and anomalies across more than 20% of the web. On the client side, we’ve pushed detection deeper with Cloudflare Turnstile, which has evolved from a CAPTCHA replacement to a risk-based managed challenge that adapts the amount of friction needed to verify the user is authentic.

Today, Turnstile runs nearly 3 billion times per day on some of the most sensitive endpoints on the Internet, helping verify users at key moments like login, signup, and checkout. This improves protection on the most important areas of customer applications, but still leaves limited visibility into the rest of the application — how humans and bots actually interact across the full user journey.

This is the visibility gap we’re closing today with our launch of Precursor.

Introducing Precursor

Precursor is a client-side, session-based verification system, built with privacy in mind, that uses dynamically injected JavaScript to continuously collect behavioral signals as visitors interact with your Continue reading

netlab 26.07: GRE, Wireguard, Graceful Restart, and Scale-Out Labs

The highlights of netlab release 26.07 include:

But wait, there’s more ;)

Read more …

SONiC: Populating CONFIG_DB

Introduction

Before a switch can forward data traffic, its ASIC must first be programmed with the device's port configuration. This includes information such as the number of front-panel ports, their supported speeds, the number of lanes assigned to each port, the speed of each lane, and the administrative and operational state of every port.

SONiC relies heavily on a Redis-based database model. During startup, the configuration stored in config_db.json is loaded into CONFIG_DB. The *mgrd daemons running inside the SWSS container then receive the changes relevant to them through Redis Pub/Sub notifications. After a daemon has processed its part of the configuration, it publishes the corresponding application-level state to APPL_DB.

The orchagent process in the SWSS container monitors changes in APPL_DB, translates the application-level state into hardware objects suitable for ASIC programming, and publishes the resulting hardware objects to ASIC_DB. The actual ASIC programming takes place in the next stage: the syncd container monitors ASIC_DB changes and passes them through the SAI interface to the vendor-specific SDK, which interacts with the ASIC driver stack to program the physical switch ASIC.

This chapter focuses on port programming because it clearly illustrates the complete programming pipeline. Other configuration objects follow the Continue reading

Worth Reading 071126


A unanimous Supreme Court reversed a $1 billion dollar jury award against a broadband provider in its March 2026 ruling in Cox Communications v. Sony Music.

 


Differential privacy (DP) data synthesizers are increasingly proposed to afford public release of sensitive information, offering theoretical guarantees for privacy (and, in some cases, utility), but limited empirical evidence of utility in practical settings.

 


LLMs are relentless data miners that train on unimaginably large text databases, looking for multi-dimensional statistical relationships among small chunks of text called tokens.

 


Regulatory filings and new business models suggest hyperscalers are shifting from simply building AI capacity to managing the enormous financial risks that come with it.

 


olicymakers are casting more and more problems as issues of cybersecurity. So reframed, wildly different policy issues, from misinformation, to child social media safety laws, to antitrust regulations, to alleged journalist misconduct, to anti-sex trafficking statutes become what this Article calls “cybersecuritized.

Prescribed Enterprise AI Architectures for Small, Mid-Size, and Large Organizations

The first article in this series, Enterprise AI Adoption: Requirements for Security, Governance, and Scale, defined the problem: enterprises consume AI through coding tools, standalone hosted applications, custom agents, and enterprise knowledge systems, but need consistent controls across identity, credentials, data, cost, providers, and operations. The second article, A Reference Architecture for Governed Enterprise AI, … Continue reading Prescribed Enterprise AI Architectures for Small, Mid-Size, and Large Organizations →

A Reference Architecture for Governed Enterprise AI

In the first article in this series, Enterprise AI Adoption: Requirements for Security, Governance, and Scale, we identified four ways enterprises consume AI and seven requirements that apply across them. Those requirements cover identity, non-human credentials, cost governance, security and data controls, model flexibility, optimization, and observability. This article translates those requirements into a reference … Continue reading A Reference Architecture for Governed Enterprise AI →

Enterprise AI Adoption: Requirements for Security, Governance, and Scale

AI adoption inside enterprises rarely begins with a coordinated platform strategy. It usually starts with individuals and teams selecting tools that solve immediate problems. A developer subscribes to an AI coding assistant. Another team builds an application using a foundation-model API. Employees begin using standalone cloud applications such as ChatGPT, Claude, Gemini, or Codex. A … Continue reading Enterprise AI Adoption: Requirements for Security, Governance, and Scale →

Tiered Network Policy: Scaling Kubernetes Security

As Kubernetes clusters scale from a few development sandboxes to massive, multi-tenant production environments, platform teams often find themselves facing a configuration management crisis. A small number of microservices suddenly demand hundreds of individual Kubernetes NetworkPolicy objects. Managing them becomes operationally expensive, auditing them is difficult, and a single developer misconfiguration can easily drop critical production traffic or open a massive security hole.

To scale cluster security without slowing down engineering velocity, we must abandon the flat, uncoordinated rule planes of the past. The solution lies in establishing a clear, multi-layered framework: a hierarchy of trust powered by tiered network policies.

The Core Problem with Standard Kubernetes NetworkPolicy

Standard Kubernetes NetworkPolicy resources are genuinely useful for basic application microsegmentation, but they have major architectural and organizational bottlenecks when scaled across an enterprise:

  1. Namespace-Scoped by Design: Standard network policies are inherently scoped to a namespace. If your security team mandates a cluster-wide rule, such as blocking all internal pods from querying the cloud provider’s metadata API (169.254.169.254), you have to copy-paste that policy into every single namespace. If a developer creates a new namespace, that guardrail doesn’t exist until someone manually applies it.
  2. Organizational Friction: Because anyone with Continue reading
1 2 3 … 3,886