Free Next Step Kit. Beta is open. You know the mountain. What you need is one step you can do this week. Email [email protected] and get one written next step back. No calls. Email during beta and you keep Next Step Kit free for life. getnextstepkit.com

Palo Alto's CVE-2026-0322 needs an authenticated attacker with high privileges. It was exploited anyway. Published October 14: root code execution through the PAN-OS management interface, on PA-Series, VM-Series and Panorama. CVSS 4.0 8.6. "No special configuration is required to be affected by this issue." Found internally, and still: "Very limited exploitation has been observed targeting the Palo Alto Networks management interface." CISA added it to KEV the same day, with a three-day deadline for federal agencies. A needs-admin label is the kind of thing that pushes a bug to the next maintenance window. KEV gave this one three days. Palo Alto publishes two scores. Management interface reachable over the network: 8.6. Restricted to a jump box: 8.5. The jump box does not fix the bug. It shrinks who can reach it. "No known workarounds exist for this issue." Threat Prevention coverage is "limited" and needs SSL decryption of management traffic routed through a data port. Fixed builds include 12.2.4, 11.2.16 and 10.2.18-h12. The advisory lists three IPs tied to exploit attempts: 66[.]42[.]72[.]14 208[.]83[.]239[.]114 149[.]248[.]47[.]234 Which addresses can reach your firewall management interface, and can you name every one?

One of eMudhra's CA private keys was the number 4. Chrome and Firefox stopped trusting it within hours. Your SSL inspection box may still trust it. Scott Helme recovered that key and the others from the public certificates: "it took less than a second." The browser side was fast. Chrome got the report on October 17 at 18:05 UTC and blocked the eight intermediates by CRLSet at 19:45 UTC. Mozilla finished its OneCRL push "in less than 3 hours". On the default update path, neither needed a browser update or restart. That fast path ends at the browser. Mozilla updated NSS for apps that "do not receive OneCRL updates". Google removed emSign ECC Root CA - G3 from the Chrome Root Store, release expected Tuesday morning, October 27 (PDT), for consumers "that do not consume CRLSet updates". Anything that keeps its own trust store, from proxies to containers, waits for someone to update it. Fortinet says the root is "still present in version 1.00064 and lower of the FortiOS Certificate Bundle" and "cannot be removed manually, only disabled": config vpn certificate ca edit "emSign_ECC_Root_CA_-_G3" set ssl-inspection-trusted disable next end On my own machines I patched certifi and rebuilt the containers. The Mac's system curl and git still trusted the compromised chains, and SIP would not let me edit that bundle. How many devices in your network carry their own CA bundle, and who updates them?

One command puts a service from a laptop on the public internet: cloudflared tunnel --url http://localhost:8080 Cloudflare's Quick Tunnels docs, updated September 30: "You do not need a Cloudflare account or domain." And: "Anyone with the URL can access your local service." Flavio Copes tested his guide on September 22 with cloudflared 2026.9.1. On local models: "Ollama has no authentication. Whoever has the URL can run your models and burn your GPU, and can pull models onto your disk through the API." For a network team, this is the line that matters: "Your router and firewall never see an inbound connection, so there is nothing to configure and nothing for a port scanner to find." The tunnel is opened from the inside. No inbound rule, no NAT entry, no firewall change to request. There is a guard: "Use --allowed-mail to require email authentication." Two limits, though. Cloudflare says email authentication "does not support non-interactive clients," so it fits a person in a browser, not a script calling an API. And it is opt-in. Whoever types the command decides whether it is there. Copes on coding agents: "I want the agent to ask me first." I agree, and I would go one step further. An agent that can run shell commands can run this one, with or without the flag, and your inbound rules never get a vote. The first control has to sit where the command runs, in what the agent is allowed to execute. If an agent on one of your engineers' laptops ran that command this afternoon, what would tell you?

Cisco's ASR 9000 advisory from yesterday has no workaround. It has a mitigation, and if your edge iACL already permit-lists what may reach the router, you have it. CVE-2026-76505, CVSS 7.5, IOS XR 64-bit. In scope: ASR 9000 and 9900 with a Lightspeed or Lightspeed-Plus line card, and ASR 9902 and 9903. Condition: IPv4 configured on any interface. Crafted IPv4 packets processed as for-us traffic can reset the network processor, and the line card loses traffic while it recovers. Repeat it, and "the network processor may enter a persistent shutdown state, in which case an explicit line card reload may be required to restore traffic." "Transit IPv4 traffic does not trigger this issue and IPv6 traffic cannot trigger it." The target is the router's own addresses, not what flows through it. "There are no workarounds that address this vulnerability. However, there is a mitigation." An infrastructure ACL on edge interfaces that drops UDP destination port 1701, the L2TP port, toward router addresses, while transit passes. Fixes: 7.9 through 24.3 need the listed maintenance release plus the CSCwn39554 SMU (24.2.21 alone also counts). 24.4 is fixed in 24.4.2. 25.1 and later are not affected. 7.8 and earlier: migrate. Cisco says it is not aware of malicious use. Two commands from the advisory tell you if you are in scope, the third whether it may already have happened: show platform show ipv4 vrf all interface brief show logging | include "NP.*reset" Does your iACL list what may reach the router, or only what may not?

Researchers fuzzed 273 MCP servers and found verified bugs in 118 of them. The paper is ToFu, submitted to arXiv on October 9 by Md Nazmul Islam Ananto, Arslan Khan and four co-authors. Across 3,405 tools they "identified verified bugs corresponding to CWE weakness classes in 343 tools across 118 of the servers." The paper's comments put the total at 253 verified semantic security bugs. The conclusion: "Our findings show that real-world tools frequently fail to enforce their documented input semantics, making it unsafe to treat LLM-generated arguments as trusted." The paper measured the tool side: tools accepting whatever the model hands them. Picture a network MCP tool. It takes an interface name, a VLAN ID, an ACL line. The documentation says what each field should be. The paper's finding is that documented is not enforced. If the tool never checks that the VLAN is in range and the interface exists on that device, a model's mistake, or text someone planted upstream, reaches the device as an argument nobody validated. The tool is the last layer that knows the device. If it does not check the argument, nothing between the model and the switch does. If your agent sent an interface name that does not exist on the device, which layer would reject it: the model, the tool, or the switch?

CISA's deadline for CVE-2025-61624 was yesterday. Fortinet rates it Medium, CVSS 6.0. In the intrusion Unit 42 published on October 14, it was the step from admin to root. The intrusion hit a telecommunications organization in September 2024. Step one was CVE-2024-47575 on a central FortiManager. From that single appliance, Unit 42 says the attackers took running configurations, cryptographic material and database files "containing information about more than 500 managed FortiGate firewalls." Those configs stored credentials as reversible ciphertext. Unit 42 confirmed the admin and SSL VPN passwords were recoverable by brute force. So the admin requirement behind the Medium score was not much of a barrier. Step two was CVE-2025-61624, which "allows an authenticated administrative account to read and write arbitrary files as root" through path traversal in the FortiOS auto-script engine. Step three was PEERSTITCH, which "leaves no persistent binary on disk, opens no listening ports and initiates no outbound network connections." Fortinet published the advisory in April 2026. Fixed in 7.6.5 and 7.4.10 or later. For 7.2, 7.0 and 6.4, every version is affected: "Migrate to a fixed release." CISA added it to KEV on October 16. Then the part no upgrade touches. The trust material for every managed device "remains valid until it is rotated," and Unit 42 says to "treat the credentials and certificates those interfaces hold as compromised" once the platform is. One check from the report: search FortiOS configuration revisions for auto-script objects with ../ in the name. When did you last rotate the certificates your management platform holds for every firewall?

Cisco listed fixed builds for an exploited Secure Email Gateway bug on September 14. The CVE for that bug arrived on October 14. September 14 was a security hardening release. Cisco grouped internally found bugs by weakness class and "assigned a single Common Vulnerabilities and Exposures identifier (CVE ID) to each CWE grouping." Path traversal, CWE-23, went under CVE-2026-76440. Fixed builds: 15.5.5-014 and 16.5.0-780. For 16.0, migrate. October 14 was CVE-2026-76519, CVSS 9.8, an arbitrary file write in Advanced Malware Protection, classed CWE-23. "In October 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability." Same fixed builds. CISA added it to KEV that day. The September advisory now reads, under CVE-2026-76440: "One vulnerability that belongs to this vulnerability class is known to be actively exploited." If your tracker keys on CVE IDs, this bug had no ID of its own for a month while the fixed builds were already listed. Cisco also ships the fix in Content Scanner Tools 25.3.0.5525 and later, to "all licensed and supported Cisco AsyncOS Software releases," and updating it "does not require a software upgrade or a product restart." The patch is the easy part. The compromise check is grep "System Security" system_logs on each cluster device, plus network and firewall logs outside the appliance, because attackers "may remove or hide evidence of exploitation and indicators of compromise." Cisco warns private SSH keys shared between cluster members could be accessed on a compromised appliance, and recommends restoring every member of a cluster with at least one compromised appliance. Does your vulnerability tracker key on CVE IDs, or on fixed releases?

Two lines published a day apart in late September point, I think, at where the senior network job is moving. Joe Vaccaro, SVP/GM for Network Platform and Assurance at Cisco, September 23: "Agentic AI represents a fundamental paradigm shift: moving from running operations to orchestrating intent." Christian Dupuis, Senior Principal Software Engineer at Docker, September 24: "Dockerfiles made software reproducible. Kits make authority reproducible." One company sells networking. The other sells developer tooling. Both point at the same split. The doing is what gets automated. Deciding what the doing may touch stays with people. Vaccaro's blog lists what leaders want in place before agents act: "explainability, approval gates for higher-risk actions, policy-based limits, audit trails, emergency override, and role-based access." Read that as a job description. Most of it will be familiar to anyone who has sat through a change advisory board. Approval for the risky change. Limits on scope. A record of who did what. A way to pull the plug. Networking has been through this before: templates, scripts, then controllers each moved the keystrokes somewhere else, and the question of what a change was allowed to break stayed with whoever had the context. Dupuis puts the agent version plainly: "Each entry is a request, and the host decides." In his text the host is the runtime. The runtime only enforces the list. Someone still has to write and review it, and in the model I would run, that is someone who knows which link carries the payroll traffic and which box must not reload during business hours. That knowledge took years to build. In this model it sits at the approval gate, and I would staff that gate with the most experienced people on the team.

On September 21, Dragos announced it had acquired runZero and NetRise. Robert M. Lee, Dragos CEO: "Dragos has acquired NetRise and runZero, a move that coincides with the close of Accenture's majority investment in Dragos." Accenture's announcement puts the dates in order. NetRise closed July 31. Accenture's majority investment in Dragos closed September 16. runZero closed September 17. Accenture gives approximately $4.175 billion as the combined enterprise value of the whole package: the Dragos stake plus both acquisitions. What the three pieces do is more useful than the price. runZero, HD Moore's company, does exposure management "across IT, IoT, and OT." It finds what is on the network. NetRise "looks inside the software running on OT devices to find hidden vulnerabilities before they're exploited." It finds what is inside the box. Dragos already watches what is targeting the box. Lee's line for the combination: "Defenders have one place to see everything in their xOT environment, understand what's running on it, and stop what's targeting it." That puts three questions in order: what do I have, what is running on it, and what is coming at it. The third usually gets attention first, because alerts arrive on their own. The first is where audits stall. A device nobody listed does not get patched, does not get a baseline, and does not show up in the exposure report. Every KEV entry starts with the same question: do we run this, and where? Lee's sentence starts with seeing everything. For anyone who has had to answer that KEV question at short notice, it is the right place to start.

Verizon says its network made over 70 million configuration changes last year without a technician typing them. Yago Tenorio, Verizon, in June: "In 2025 alone, our closed-loop automation platforms executed over 70 million network configuration changes autonomously." And: "Implemented by hand, these granular changes would have required thousands of technicians working around the clock." In late September, Anil Guntupalli, Verizon's SVP of Technology and Product Development, spoke at RCR's Intelligent RAN Forum. As RCR Wireless reported it, in paraphrase: automation is what you already know and can script. Autonomy is what you do not know, where an agent has to reason. In that account, agents get configuration changes, software updates, node resets, sleepy cells. People keep intent and guardrails, priority-one incidents, and changes to network state. RCR also reports one more requirement. If an agent changes a network configuration, Verizon wants to know which agent did it, what network state it saw, which data it used, and in what context. That is the part I would copy first. At tens of millions of changes a year, line-by-line review is not realistic. What you can review is the record. A typical change log answers who and when. It rarely answers what the actor believed the network looked like at the moment it acted. With a human engineer, that gap was survivable. You could walk over and ask. You cannot ask an agent what it saw last Tuesday unless the record kept it. If you are piloting agents on your own network, check whether your logs could answer Verizon's four questions today: which agent, what state, which data, what context.

Cisco publishes its next security advisory bundle tomorrow, October 7. Last Wednesday, Cisco PSIRT posted an advance notice with five products: Application Policy Infrastructure Controller (security hardening release) Finesse License On-Prem, formerly Cisco Smart Software Manager On-Prem (security hardening release) Meraki (security hardening release) NX-OS Software for MDS 9000, Nexus 3000, 7000, and 9000 Series Switches, Nexus 9000 in ACI mode, and UCS Fabric Interconnects (security hardening release) Cisco is clear that the list can move: "this schedule is not a final commitment of releases." And: "Products may also be added when releases are ready ahead of schedule." No CVE numbers yet. No severity. Most of the preparation does not need them. Start with inventory: which of the five you run, and on which trains. NX-OS is the long line, and MDS, Nexus standalone, Nexus in ACI mode and UCS Fabric Interconnects often sit with different teams. Then owners. Finesse and License On-Prem are easy to miss in a network inventory, so find out who owns them before the advisory lands. Book a change window for later this week, in case tomorrow brings a fix you need. Cancelling a slot costs less than finding one at short notice. And save current versions and configs tonight, so tomorrow you compare the affected releases against a file instead of memory. The notice explains the rhythm: hardening releases and advisories "on the first and third Wednesday of each month," with a "seven-day advance notice." This one came with a week's notice and a list of five product names, which is more than most advisories give you.

Google's threat intelligence team says the NetScaler campaign has been "ongoing since at least early September." Citrix published its security bulletin on September 27, and CISA added both CVEs to KEV the same day. So the attacks had been running for weeks before defenders had a bulletin to act on. The two CVEs, CVE-2026-88771 and CVE-2026-88772, affect NetScaler ADC and Gateway. Both are CVSS 9.5 (CVSS 4.0). The federal deadline was September 30. Unit 42 also saw more than 100 systems fingerprinted on August 21 and 22. Palo Alto's Cortex Xpanse counted 50,277 exposed instances as of September 27 that could potentially be vulnerable. Which is why CISA puts the compromise check before the patch: "If possible, users are encouraged to check for indication of compromise prior to patching." And: "Should your organization suspect compromise, it is important to preserve forensic evidence prior to applying updates, as updates may result in loss of forensic visibility." Unit 42 says it plainly: "Updating and patching will not remove access for attackers that have already established persistence." The tooling shows why. Google describes WHIPSHOT, a web shell that hides its command channel in HTTP headers, and SLAPSHOT, a Python tunneler that exits after 10 minutes idle. Neither cares which build you are on. For a suspected VPX instance, Citrix's guidance is not a patch: "Cloud Software Group recommends replacing and restoring the instance." For physical MPX appliances, it says to erase and reinstall. Then: "Monitor the rebuilt system closely for suspicious activity for at least 90 days after recovery." Fixed builds: 14.1-73.37 and 13.1-64.23. If your NetScaler faced the internet in September, the build number tells you whether it is vulnerable now. It does not tell you what happened before you upgraded. Pull the logs first. Citrix says to keep remote syslog and NetScaler Console logs, not just the local ones. Then patch.

Cisco published a critical SD-WAN Manager advisory on Wednesday. CISA added it to KEV the same day. CVE-2026-76504. CVSS 9.8. Cisco's summary: an "unauthenticated, remote attacker" could reach the system "with privileges of the admin user." The cause is small. A URI-encoded request slips past an authentication rule meant to protect one API endpoint. Cisco's IOC examples show one encoded letter: %6a in place of the letter j in j_security_check. Cisco also says any single encoded character works. Grep for %6a alone and you can miss it. Three lines from the advisory decide the weekend: "In September 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability." "There are no workarounds that address this vulnerability." "This vulnerability affects Cisco Catalyst SD-WAN Manager, regardless of system configuration." No workaround. The only mitigation Cisco lists is to let only known, trusted hosts reach the manager, and Cisco calls that temporary. Active exploitation. The KEV deadline for US federal agencies is October 3. First fixed releases: 20.9 -> 20.9.10.1 20.12 -> 20.12.8.2 20.15 -> 20.15.6.1 20.18 -> 20.18.4.1 26.1 -> 26.1.2.1 26.2 -> 26.2.1 Older than 20.9: migrate. Cisco-managed SD-WAN Cloud is already fixed, no action needed. Before you patch, check the logs Cisco names: serviceproxy-access.log and vmanage-server.log, requests to j_security_check from addresses you do not recognize, and in vmanage-server.log users whose names start with viptela-reserved-. Cisco warns these entries can also appear in normal operation, so compare against your baseline. Patching closes the door. It does not tell you whether someone already walked through it. The manager holds the policy for every edge in the fabric. Admin on the manager is, in practice, admin on the WAN. Cisco says it was found while resolving a TAC support case. If you run SD-WAN Manager, this is the weekend change window.

You named the mountain. Step one is still fog. Free Day-1 kit for Almost-Starters: one written next step this week. Async. No calls. getnextstepkit.com or [email protected] - subject: Start the free Next Step Kit.

Docker published a permission format for AI agents on September 24. Network engineers will recognize the grammar: it reads like an access list. The Docker Sandbox Kit Specification v3, open source under Apache 2.0. A Kit is an ordinary OCI image carrying the agent, its tools, and a typed list of what it asks for: network rules, credentials, volumes, ports, devices. The problem it targets, in the words of Docker's Eli Aleyner and Srini Sekaran: "There is no shared format for what an agent is allowed to do." Here is part of the GitHub CLI example from the spec author, Christian Dupuis, rewritten as a firewall rule: allow github.com allow api.github.com, methods GET HEAD POST PATCH PUT DELETE deny api.github.com, method DELETE, path /repos/** A broad permit, then a narrow deny that overrides it. Dupuis: "because deny wins. The token that can open a pull request cannot delete the repository." The token is proxy-managed. Per Dupuis, "inside the sandbox there is only a sentinel". Every entry on the list is a request. "A Kit grants itself nothing." Enforcement needs a conforming runtime, and without one "the annotation is inert". Docker Sandboxes is the first such runtime. Updates can be gated too. In a runtime that gates updates, "Any widening stops and asks, and removing a deny rule counts". That last rule is how firewall change control should work. A new permit gets reviewed. A deleted deny gets reviewed too, because removing it can open access just like a new permit. On governance, the wording matters. Docker "has committed to submitting its Kits specification" to the CNCF. A commitment to submit is not an accepted CNCF project. The CNCF's CTO welcomed the move, on Docker's own blog, which is still not the same thing as acceptance. If you want to try it, Cloud Sandboxes start at $0.07 an hour for 1 vCPU and 2 GiB, metered by the second. The spec does not decide what your agent should reach. Someone still writes that list and reviews it every time it grows. We have been doing that job for packets for decades.

Roughly 21 network alerts a day. That is how many a typical practitioner can clear, according to a report Cisco published on September 23. The same research puts the average organization at "about 4,100 monitoring alerts and events each day". The full report says 51% of them are network related. Roughly 2,100 network alerts a day. Divide 2,100 by 21 and you land where Cisco's Joe Vaccaro lands in his blog: "clearing the daily backlog manually would require a team of roughly 100 IT specialists". Who was asked matters. The survey was run by Omdia: 1,000 IT and network operations leaders at organizations with 500 or more employees. The respondents are leaders, and the report carries Cisco's name. Read every number below with that in mind. What happens today to the alerts nobody reaches, per the report: 46% of network alerts are closed without investigation. 45% of investigation time goes to false positives. What leaders say they are doing about it: "51% run agentic AI that acts in production today." "80% are comfortable granting AI a high or fully autonomous role in NetOps, including 24% who are comfortable with AI acting with no human oversight." "84% expect an AI-led operating model within twelve months." That one is a forecast, not a measurement. And the condition they attach: "69% require detailed explainability for agent-driven actions." That last number is the one I take most seriously. Look at the 46% again. Nearly half the network alerts already close with no investigation at all. An agent that closes an alert and records why would at least leave a trail someone can check. The 69% are asking for the right thing. I would ask the same of the humans and scripts closing alerts today. If an agent closed 2,000 alerts tomorrow, what would you need to see before you signed off on its work?

Zyxel's advisory describes the attacker for this switch bug as a "LAN-based, unauthenticated attacker." GreyNoise counted 996 exploited switches in 48 countries. The target was the Zyxel GS1900 series. CVE-2026-7273, a stack-based buffer overflow in the CGI program. CVSS 8.8. Zyxel shipped patches for ten GS1900 models on June 16. GreyNoise published its analysis on September 21 and dates the exploitation to "On or about 17 August". CISA added the CVE to KEV the same day as the report, with a September 24 deadline. What the actor took, per GreyNoise: "configurations, root level credentials (hashed), and networking information." In other words, the map of the network and the keys to it. GreyNoise again: "While the credentials were hashed, 564 of the victims had factory default credentials." 564 of 996. When the password is the factory default, the hash protects very little. Top three countries by victim switches: Italy 133, United States 129, Taiwan 123. GreyNoise describes the actor as "a suspected Chinese speaker possibly working in UTC+8", based on the operational timeline and Chinese comments in the tools. That is an assessment of language and working hours. It is not a state attribution. Back to "LAN-based". Either those management interfaces were reachable from wherever this actor was sitting, or the actor was already inside those networks. GreyNoise does not break that down, and I will not guess. Neither answer is comfortable. Access switches are easy to leave out of a CVE review. Two months between the patch and the exploitation GreyNoise documented suggest these ones were. Check the firmware on every GS1900 you own. Then check the password. On more than half of these switches, it was still the factory default.

On September 22, CISA added four exploited vulnerabilities to KEV in one alert: F5, Check Point twice, Arista. Every federal deadline was September 25. Those deadlines have passed. The better question now: would a version check have told you whether you were exposed? For three of the four, the answer is in the configuration, or on a box that sits behind everything else. F5 BIG-IP APM, CVE-2026-94127. CVSS 9.8 (v3.1). Unauthenticated remote code execution. F5's CVE record says the flaw "is only present when BIG-IP APM is configured as an OAuth Authorization Server." Same record: "This is a data plane issue; there is no control plane exposure." So the usual reflex, lock down the management interface, is not the fix here. Check Point CVE-2026-93616. CVSS 9.8. Pre-auth path traversal in the Security Management web service. Check Point: "we observed a handful of pinpointed attacks on July 23, 2026." The fix shipped with the September 22 advisory. Same advisory: "Check Point LivePatch Take 28/29 does not address this issue." Check Point's hardening guidance for it: "Make sure that access to port TCP/19009 is only possible from Trusted IP addresses." Check Point CVE-2026-85102 is the gateway side. Fixed September 9. Exploitation attempts against Spark customers started September 12. Arista VeloCloud Orchestrator on-prem, CVE-2026-93952. CVSS 10.0 (v3.1). Exposure requires certificate-based authentication from the Edges to the orchestrator. Arista: "This issue was discovered externally and is known to be actively exploited." Fixed releases exist for the 5.2.3 and 6.4.2 trains. Other trains "will be added over time." CISA's KEV note for the F5 flaw puts the order in writing. Apply the vendor iRule first, "to allow for proactive forensic triage," then patch. Look at what is on the list. An access gateway that issues OAuth tokens. The server that holds every gateway's policy. The orchestrator that manages every branch Edge. A version number tells you what is installed. It does not tell you whether APM runs as an OAuth authorization server, whether your Edges authenticate with certificates, or who could reach TCP 19009 on the management server since July. That evidence comes from the config and the logs.

Cisco's product chief opened Splunk .conf26 by comparing AI agents to teenagers. The next day, Cisco announced more agents to run your SOC. Jeetu Patel, President and Chief Product Officer, gave the welcome keynote on September 14. Zeus Kerravala reported it for SiliconANGLE: Patel said agents are like teenagers, and Kerravala summed up the comparison as intelligent, fearless and notorious for poor judgment. In Cisco's own press release he framed it as three questions customers keep asking: "Can I trust it to do the job? Can I afford it? And, most importantly, can I secure it?" What was announced on September 15: new agent capabilities for the Splunk Agentic SOC Workforce that, in Cisco's words, mirror how elite teams work across "detection engineering, proactive threat hunting, autonomous investigation, coordinated response, and policy governance." Plus a Tokenomics module in Splunk Agent Observability that tracks what the agents cost. One number from the keynote is already travelling. Per Kerravala's write-up, Patel said that in February agents consumed more tokens than humans for the first time, and that seven months later they were consuming five times as many. The report names no source. The closest public data I know comes from an OpenRouter analyst, reported by The Decoder in August: a possible February crossover on OpenRouter's own traffic, agent usage up 14x since, human usage up 2.8x. If the keynote figure comes from there, it describes one platform. I would want the source before putting 5x on a slide. SiliconANGLE's September 15 coverage describes the boundary customers are setting. Autonomy is configurable per agent. Its example: routine triage fully automated, isolating infrastructure or disabling an account still subject to approval. Splunk's platform GM, per the same article, says many SOCs are comfortable with autonomous triage and still want a human approval loop for actions and mitigations. That is the boundary I know from network automation. Read-only and low-risk changes run on their own. Anything that can take a site down waits for a person. The vendor selling the agents is telling you to parent them. I would take that literally. Allowance, curfew, and no car keys to production.