Claudia de Luna published a step-by-step description of how you can use SuzieQ data with an AI agent.
That’s definitely interesting, but I found the list of MCP resources at the end of her blog post even more valuable; that’s a keeper even if you never looked at SuzieQ (in which case you REALLY SHOULD).
The Images service, built in Rust on Workers, runs on every machine in Cloudflare’s edge network. To handle client connections, we use hyper, an open-source HTTP library for Rust.
Last year, we introduced the Images binding to enable custom, programmatic workflows for processing remote images in Workers. At the end of 2025, we rearchitected the binding to provide a more direct, local connection between the Workers runtime and the Images service.
Shortly after rollout, we received reports that transformation requests from the binding were failing — but only intermittently and only for larger images. Even stranger, the responses for these requests returned a 200 status without any errors logged. The image data was simply cut short: A response that should have been two megabytes might arrive with a few hundred kilobytes instead.
We spent six weeks chasing a nearly invisible bug — a race condition that occurred only under specific conditions — in the hyper library that impacted how the Images binding returned processed image data back to the client. In the end, it took four lines of code to fix it.
When developers build on Cloudflare, they compose full-stack applications from a set Continue reading
If you look back at every Netmiko script we have written in this series, you will notice something (very ) uncomfortable, the username and password are sitting right there in the script as plain text. That has been fine for learning, but it is not something you want to do in real scripts.
In this part, we will look at safer ways to manage credentials in your scripts. We will cover a few different approaches, from the simplest (asking the user to type the password when the script runs) to the more common patterns used in real projects (environment variables and .env files). We will also touch on .gitignore
There is no single "correct" way to manage credentials. Different projects and different environments call for different approaches. What matters is that you understand the trade-offs and stop hardcoding passwords into your scripts.
Let's start by being clear about why this matters. Take a look at a script you have written in the last couple of chapters.
device = {
"device_type": "cisco_ios",
"host": "192.168.202.101",
"username": "admin",
"password": "admin"
}
This looks harmless on your own machine, but think about everything that could Continue reading
Charity Majors wrote an excellent article describing AI enthusiasts in a race against time and AI skeptics in a race against entropy. Fair warning: its very first sentence triggered an acute case of PTSD:
I recently attended a talk where one of the presenters made some pretty…astonishing claims about what they had achieved by the pure, uncut power of vibe coding.
I’ve seen way too many presentations making “astonishing claims” about the unlimited unicorn-driven powers of OpenFlow, SDN, OpenDaylight, or Ansible.
I've been running Proxmox for maybe two years now, and I'd consider myself somewhat of a beginner. I set it up once using Proxmox version 8.x alongside Proxmox Backup Server and pretty much forgot about it. I can spin up new VMs and CTs, or remove existing ones, and that's about it. Fast forward to mid-2026, Proxmox released version 9, and I'd been meaning to upgrade. I went through a few guides and forum posts, and people tended to recommend backing up the VMs and CTs using PBS, then reinstalling Proxmox with the new version and restoring from backup.
I upgraded my Proxmox setup from version 8.x to 9 without doing an in-place upgrade. Instead, I used a spare node already on version 9 as a temporary home and rebuilt the other two nodes one at a time. The idea was to back up everything with PBS, restore onto the spare, then wipe and fresh install version 9 on each node before joining them into a new three-node cluster. Once the cluster was sorted, I also rebuilt pbs-01 to version 4 and cleaned up the old backups. The whole thing was seamless, I didn't lose anything, and Continue reading
In the last part, we got Netmiko up and running, connected to a device, ran a show command, and printed the output. That is enough to write some genuinely useful scripts, but Netmiko can do a lot more than just run a single command.
In this part, we will look at what else Netmiko has to offer. We will cover how to run multiple commands, push configuration changes, load config from a file, save the running config, and use enable mode when the device requires it. We will also look at how to parse command output into structured data instead of raw text, which is a huge time-saver when you are trying to actually use the output for something.
By the end of the chapter, you will have a much better feel for what Netmiko can do, and you will be ready to start writing scripts that actually make changes to your network instead of just reading from it. For the examples in this chapter, I will be using three real Cisco IOS devices in my lab.
devices = [
{
"device_type": "cisco_ios",
"host": "192.168.202.101",
"username": "admin",
"password": "admin"
},
{
"device_type": "cisco_ios",
"host": "192.168.202. Continue reading
In this blog post, we will cover upgrading Palo Alto firewalls in HA using Ansible. This only covers upgrading minor versions, so it won't work if you are going from 10.x to 11.x, for example. This also only supports an HA pair.
This playbook is based on the repo from Palo Alto itself. There are many playbooks there covering scenarios like upgrading the major version, upgrading the content, and so on, but we will only focus on one specific playbook for HA, which I tweaked a little bit to suit my own setup.
Of course, this post assumes you already know how to upgrade the firewalls manually. In case you don't, here are the steps. Palo Alto also recommends upgrading the active unit first and then the passive. You download the image to the active unit and tick the box to sync it to the peer, then suspend the active unit to trigger a failover so the passive takes over. Install the image on the suspended unit, reboot it, and wait for it to come back online so the HA pair syncs again. Once it is back, suspend the current active unit (the original passive) Continue reading
One of the most common questions I get from CCDE candidates is: “What should I read?” and “Where should I start?” This post is the CCDE reading list I actually…
The post CCDE Reading List appeared first on JTnetwork.io.
Welcome to Technology Short Take 197! I’ve been traveling for business for the last week, so this Technology Short Take has a tad fewer links than I typically include. Even so, I still have links on radical new network designs, the impacts of AI on code security, things beginners get wrong about AWS IAM, and more! Let’s get into the content.
Everyone's writing code with AI agents today. But the moment an agent needs to deploy something — and needs to sign up and create an account — it slams face-first into a wall built for humans: a browser-based OAuth flow, a dashboard to click through, an API token to copy-paste, a multi-factor authentication prompt to satisfy. For an interactive copilot sitting next to a developer, that's annoying. For a background agent, it's a hard stop.
Today we're rolling out Temporary Cloudflare Accounts for Agents.
Agents can now deploy websites, APIs, and agents right away, without first needing to sign up for an account.
Any agent can now run wrangler deploy --temporary and deploy a Worker to Cloudflare. This temporary deployment stays live for 60 minutes, during which time you can claim the temporary account, making it permanently your own. If you don't, it expires on its own.
Our goal? Let your agent code and ship.
Frictionless temporary accounts matter more than it might first seem:
Background AI sessions have no human in the loop, and are becoming the norm. Any auth step that needs a browser, a copy-paste, or "click here Continue reading
As DNS is more widely used to distribute certificate information, proving ownership of a resource becomes more critical. The constant challenges required to prove resource ownership, however, increase delay in connecting or using a resource. DNS persists–as the name implies–creates a persistent connection between a resource and a certificate authority. Henry Birge-Lee, Michael Slaughter, and Shiloh Heurich join Russ and Tom to explain how this new record type works and it’s importance to DNS.
download
A few weeks ago, we published our initial findings from Project Glasswing, looking at what happens when you point frontier security models at an enterprise codebase. We also explored how our defensive structures adapt to protect our infrastructure and customers from threats posed by frontier AI. Since then, the AI ecosystem has continued to shift rapidly — developers who've built tightly around a single model have already experienced what happens when that model is no longer available or gets superseded by a more capable one. These market shifts only reinforce our core thesis: no matter which underlying model is leading the pack on any given day, the future of agentic workflows will not be found in standalone models, prompts, or single-agent sessions.
Moving from a localized security "skill" to a continuous, fleet-wide scanning pipeline requires an architecture where models are treated as interchangeable components. Relying on a single model inherently limits defensive coverage, as the same system will tend to look at code paths through the exact same lens. To counter this, models should be frequently interchanged and cross-tested. By varying the models across the pipeline — such as using one model for initial discovery and an entirely different Continue reading
We launched Lynx this week. Instead of restating the pitch, I want to explain how it’s built and why we made the architectural choices we did. If you run Kubernetes and you’re starting to put AI agents on it, this is roughly the system you’d end up designing yourself.
Lynx is a control and data plane for all agentic AI traffic, providing a registry, gateway, audit, authentication with token exchange, policy enforcement, agent sandboxing, shadow agent discovery, and advanced AI capabilities such as red team agent and a guardian supervising agent to keep your agents on track. Lynx is single control point in the path of every agent call – agent-to-agent, agent-to-MCP, agent-to-LLM. Every call is authenticated, authorized against policy, and recorded, with no changes to agent code.
Four principles shaped the design: