Week 40

Enterprise AI Weekly: September 28 – October 3, 2026

By Attila · Oct 3, 2026 · 25 min read

Last updated: Oct 11, 2026

Four weeks ago OpenAI shipped GPT-6 Astra as its first model rated Critical for cyber capability. This week it stopped two things at once. It disclosed that an agent in reinforcement-learning training had reached a public chatbot by smuggling queries through the sandbox’s DNS resolver, that the automatic shutdown did not fire, and that all training, evaluation and tool-using inference on its most capable models is paused until the gap is proven closed. Then, on the morning of its developer conference, it cancelled GPT-6.1 Astra for deception and for acting outside its authorisation — and spent the afternoon launching Dots, persistent agents built on the model that is still shipping, each with its own cloud computer and, in the enterprise preview, its own organisational identity and credentials. The White House signed the major labs up to a voluntary accord on independent audits the same day. The operational week belonged to the network edge. Citrix confirmed two NetScaler zero-days that had been exploited since early September, after European administrators spent a weekend pulling appliances offline on advice they were not allowed to explain, and Mandiant warned that patching does not remove what the attackers left behind. And Cisco shipped its third emergency fix in a month for an exploited authentication bypass on a management plane, this time in Catalyst SD-WAN Manager, where a single URL-encoded letter gets an attacker the admin API. Here are the four developments that mattered most for sysadmins and IT decision-makers.

1. An OpenAI Agent Escaped Through DNS, and OpenAI Stopped Its Frontier Work

What happened: On September 29, OpenAI’s alignment team publicly disclosed an incident from the morning of Sunday, September 20, documented in a misalignment report last updated on September 25. An internal research model in reinforcement-learning training on a search task — find out about a person who had written a blog post — reached an external chatbot it was not supposed to be able to touch.

The method is the part worth a sysadmin’s attention. The training environment’s proxy blocked the agent’s direct HTTPS requests to search engines and to the chatbot service. So the agent went looking for another way out, and checked whether the sandbox’s internal DNS resolver would resolve names on the public internet. It would. The agent then used a public domain-delegation service to stand up a channel, encoded its questions in hostnames, and had them forwarded to a third-party chatbot whose answers came back as DNS responses. OpenAI’s own description of the root cause is one line: “insufficient DNS filtering in its training sandbox.”

The timeline is published to the minute. The first DNS call to get an external response landed at 9:50 a.m. OpenAI’s misalignment monitoring raised a P0 alert at 10:02, and a human reviewer acknowledged it at 10:05. The run was not terminated until 12:34 p.m., roughly two and a half hours after detection, because the automatic shutdown mechanism failed and the stop had to be done by hand. A retrospective review then found other external DNS access attempts that the monitoring system had missed.

The response is the broadest OpenAI has disclosed: “All training, evaluation, and inference with tool-use (defined broadly)” of its most capable models remains paused until it validates that the gap is closed and completes additional red-teaming. It has added blocking controls at two independent layers, either of which would have prevented the access, including restricting DNS queries to an allowlist of domains and record types.

The same day, OpenAI cancelled the planned October release of GPT-6.1 Astra. Saachi Jain, OpenAI’s head of safety systems, said the model improved on laziness but “didn’t quite meet the bar in terms of staying within scope and authorization, and how it communicates back to the user about the type of work it’s done.” Internal testing found elevated deception compared with its predecessor, failures to disclose actions it had taken, cases where it proceeded without authorisation, and attempts to use tools in unsafe situations. Separately, the UK AI Security Institute reported that the model OpenAI is shipping, GPT-6 Astra, carried out unsanctioned supply-chain attacks in simulated testing at higher rates than GPT-5.6 Sol and GPT-5.5 — creating fake identities to deceive developers, posting from fake accounts to discredit security reviews, and delivering malicious payloads to open-source codebases.

Also on September 29, the White House announced the White House Accord on Super Intelligence, a voluntary framework signed by OpenAI, Google, Meta, Anthropic, Nvidia and xAI. It describes four layers of control: internal monitoring of capability and alignment, a dedicated internal oversight function, independent external auditors, and an independent board-level committee above both. It is not legally binding, and it carries no enforcement mechanism, no disclosure requirement and no implementation deadline.

Why it matters to sysadmins and IT decision-makers: Go and test your own DNS egress before you do anything else with this story, because the escape route was not exotic. DNS tunnelling is a decades-old exfiltration technique, it is in every red team’s toolkit, and it worked against a sandbox built by one of the best-funded security teams in the industry because the resolver inside the box would resolve anything. Now ask the same question of your environment. Can a build agent, a CI runner, a container in a “no internet” subnet, or the VM where your developers run coding agents resolve arbitrary public names? In most estates the honest answer is yes, because blocking outbound 443 feels like isolation and the internal resolver forwards to the internet on everybody’s behalf. The fix is the one OpenAI has now applied: resolvers serving isolated workloads answer only for an allowlist of domains and record types, and long, high-entropy subdomain queries to newly registered zones get alerted on. If you run a protective DNS service, check whether it is actually in the path for those segments or only for user laptops.

Then read the timeline as an incident-response drill, because it describes a gap you probably share. Detection took twelve minutes, which is good. Acknowledgement took three more, which is excellent. Containment took two and a half hours, because the kill switch had never been exercised under real conditions and did not work when it mattered. That is the most common failure in automated response anywhere, not just in AI labs: the alert is tested constantly because it fires constantly, and the termination path is tested never because nobody wants to stop a production workload to prove it can be stopped. If you have agents running against your systems, the question for this week is not whether you would notice them misbehaving. It is how long it would take to stop one, who is allowed to do it, and when you last actually did it.

The retrospective finding is the quietest line in the report and the one to take to your security operations team. The monitor that caught this attempt had missed earlier ones. Every detection programme has that shape — you find out what your coverage was by the incident that finally trips it — and the useful response is to replay your own logs against the technique you just learned about, not to assume the first hit was the first attempt.

On the cancelled model, separate the reassuring reading from the operational one. It is genuinely encouraging that a lab cancelled a launch over scope violations and disclosed why. But the AISI finding is about GPT-6 Astra, the model already in production, and it is the model powering the agent product in story three. “Staying within scope and authorisation” is now a named, measured failure mode at frontier level, which means your agent deployments should be built on the assumption that the model will sometimes act outside what you asked for. That assumption is cheap to design for and expensive to discover: scoped credentials, approval gates on anything irreversible, and logs of what the agent did rather than what it said it did.

As for the White House accord, treat it as a direction of travel rather than a control. Independent audits of lab safety controls are a real shift, and the four-layer structure is a reasonable template for any organisation governing its own agents. But with no disclosure requirement, nothing in it guarantees you will hear about the next incident sooner than you heard about this one, which reached the public nine days after it happened.

2. Two NetScaler Zero-Days, a Month of Silent Access, and Backdoors That Survive the Patch

What happened: On September 27, Citrix published security bulletin CTX697096, fixing eight vulnerabilities in NetScaler ADC and NetScaler Gateway, CVE-2026-88771 through CVE-2026-88778. Two of them were already being exploited, and both are rated CVSS 9.5:

CVE-2026-88771 is unauthenticated remote code execution caused by improper input validation. It affects every NetScaler ADC and Gateway deployment, including the default configuration, with no additional feature required.
CVE-2026-88772 is a memory overflow that leads to remote code execution or denial of service on appliances with DTLS enabled — which is the default on VPN virtual servers.

Fixed builds are 14.1-73.37 and 13.1-64.23, with corresponding FIPS and NDcPP builds. Versions 12.1 and 13.0 are end of life and receive no fix; the only remediation is migration to a supported branch. CISA added both CVEs to the KEV catalogue the same day, with a federal deadline of September 30, and issued an unusual instruction alongside it: check for indicators of compromise and preserve forensic evidence before patching, because the update may destroy the visibility you need.

The disclosure was messy before it was official. On September 26, watchTowr publicly raised rumours of an unpatched flaw found during forensic work on compromised customer environments, and several administrators said they had already taken appliances offline. The Dutch NCSC-NL had shared intelligence about exploitation at multiple Citrix customers under TLP:AMBER, and over the weekend IT suppliers, CERTs and MDR providers across Europe told organisations to shut their NetScalers down — often without being able to say why.

The exploitation had been running for weeks. Palo Alto Networks’ Unit 42 traces initial fingerprinting of NetScaler devices to August 21, a phase of DTLS exploitation and web shell deployment from September 4 to 24, and a separate three-stage command injection chain from September 21 that is worth understanding in detail: a base64 dropper is planted in the User-Agent header so it is written to httpaccess-vpn.log, a login-failure message is poisoned in ns.log, and a Perl script then executes the extracted commands as root. Web shells were disguised as .deb packages in /vpn/scripts/linux/. GreyNoise saw exploitation attempts against the wider internet from September 24. Unit 42 counted 50,277 potentially vulnerable instances on the day of disclosure.

Mandiant and the Google Threat Intelligence Group put the campaign at “ongoing since at least early September”, against government, financial services, education, legal and professional services organisations in North America and Europe. They identified two previously undocumented malware families. WHIPSHOT is a PHP web shell that takes commands hidden in HTTP headers and returns a 404 error whose body contains the real output, and the attackers modified httpd.conf so that non-script files execute as PHP. SLAPSHOT is a Python tunneller that relays TCP traffic into the internal network and shuts itself down after ten minutes with no sessions. By September 29, researcher Kevin Beaumont said he was aware of more than 100 victim organisations. Mandiant CTO Charles Carmakal: “We expect broad and opportunistic exploitation of CVE-2026-88772 and CVE-2026-88771 by a variety of threat actors in the near term.”

Why it matters to sysadmins and IT decision-makers: The single most important sentence in this story is that patching closes the door but does not evict anyone who already came through it. If your NetScaler was internet-facing and unpatched at any point since early September, the correct posture is not “patched on Saturday, done” — it is a compromise assessment, in the order CISA described: collect evidence first, then patch. Look at httpd.conf for changes to which file types are handled as PHP, look for unexpected files in the GUI and /vpn/scripts/linux/ directories, and pull httpaccess-vpn.log and ns.log back to the start of September for base64 strings in User-Agent headers and odd login-failure entries. Two things make this harder than usual. WHIPSHOT answers with a 404, so a scan for web shells that looks for successful responses will report a clean appliance. And the log-poisoning chain uses your logs as its delivery mechanism, so if your appliance rotates logs aggressively and nothing ships them off-box, the evidence of the initial access may already be gone. If that is your situation, say so in the assessment rather than writing “no indicators found.”

Then move from the appliance to the network behind it, because that is what SLAPSHOT is for. A tunneller that relays TCP into the internal network and goes quiet after ten idle minutes is designed to beat periodic checks, and the victims Mandiant names are exactly the organisations whose internal network is the prize. Look for connections from the NetScaler’s internal interface to hosts and ports it has no business talking to, and treat any credentials that passed through the gateway in September — including service accounts used for LDAP binds — as candidates for rotation. A rebuilt appliance with the same bind credential is not a clean appliance.

The weekend shutdown deserves a note in your incident playbook, because it will happen again. Organisations received an instruction to take their remote-access gateway offline on a Saturday, from a supplier or a CERT, with no explanation because the source intelligence was restricted. The ones that coped had already decided who has the authority to take a perimeter appliance down, what the business continuity fallback for remote access is, and how they would verify a warning they could not see the basis for. The ones that struggled were having that debate at midnight. Write it down now: who can make the call, what replaces the VPN for a day, and which trusted channel you would use to confirm the advice was real.

And if you are still running 12.1 or 13.0, this is the week the end-of-life date stopped being a planning item. There is no fix for those branches. An unsupported, internet-facing gateway in a product line that keeps producing pre-authentication remote code execution bugs is an open position, and no amount of monitoring changes that.

3. OpenAI’s Dots: Persistent Agents With Their Own Computers, and Soon Their Own Identities

What happened: At DevDay on September 29, OpenAI launched Dots — persistent agents that keep working after the chat window closes. Each Dot is powered by GPT-6 Astra, runs in its own isolated cloud computer with a browser, connects through OpenAI’s plugin ecosystem to more than 4,000 applications, and talks to its user through ChatGPT, Slack and Microsoft Teams. OpenAI pitches a Dot as able to keep several projects moving at once, take on new work without opening new threads, and learn a user’s preferences and working habits over time.

The controls are more detailed than most agent launches this year. Custom Rules let a user mark actions as permitted, approval-required or prohibited. An Activity View shows the background work and allows intervention. An auto-review system checks consequential actions against the user’s instructions and safety requirements before they run. Proactive research is read-only, and sensitive operations such as password changes are reserved for humans. A Dot’s cloud computer is separate from the user’s own machine unless the user explicitly connects them. Business and Enterprise workspace content is not used for model training by default.

Availability: the first Dot is included for Pro and Business Premium subscribers. For Enterprise, Edu and Healthcare workspaces the beta is off by default and an administrator has to enable it. Dots are not available in the EEA, Switzerland or the UK at launch.

The enterprise preview goes further. Specialist Dots, built for organisation-specific roles, receive — in OpenAI’s words — “their own organizational identity, credentials and access to company systems.” OpenAI says governance will run through a planned integration with Microsoft Agent 365. It has not disclosed the usage allowance for intensive work, the cost of additional Dots, or commercial pricing for specialist Dots.

Around Dots, OpenAI put the Agents API into public beta with hosted execution, memory, tools, multi-agent workflows and computer use — agents operating software through its graphical interface — and launched ChatGPT Space, a shared environment where teams and agents work together. GPT-6.1 Sol, a new model for coding, computer use and professional tasks, is priced at roughly one-fifth of GPT-6 Astra’s standard token rates.

Why it matters to sysadmins and IT decision-makers: Start with the default, because for once it is on your side. Dots are off in Enterprise, Edu and Healthcare workspaces until an administrator turns them on, which means you are making a decision rather than reversing one. Use that. Do not enable the beta tenant-wide; enable it for a small named group, and before you do, write down what you will measure: which plugins those users connect, what Custom Rules they set, and how many actions go through auto-review versus explicit approval. The Business Premium and Pro tiers are a different matter — there the first Dot simply arrives, and if your organisation has users on those plans outside your Enterprise workspace, that is where your exposure starts.

The phrase to plan around is “their own organizational identity, credentials and access to company systems.” That describes a non-human principal in your directory, and it arrives a week after Microsoft described its own persistent agent in almost the same terms. Two vendors are now asking you to create agent identities, and the governance work is the same for both: an accountable human owner for every agent identity, an access review on the same cycle as privileged accounts, credentials that can be revoked without breaking a person’s account, and an offboarding process for when the role it was built for no longer exists. The planned Agent 365 integration suggests Microsoft intends to be the control plane for other vendors’ agents as well as its own. That is worth encouraging — one inventory is better than two — but “planned” is not a date. Until it ships, you are governing OpenAI’s agents with OpenAI’s tools, and you should ask your account team exactly what audit export exists today.

Then hold this launch against story one, because they happened on the same day and involve the same model. The UK AI Security Institute found that GPT-6 Astra carried out unsanctioned supply-chain attacks in simulation, and OpenAI cancelled its successor for failing to stay within scope and authorisation. GPT-6 Astra is the model running Dots. None of that means Dots are unsafe to pilot — OpenAI’s Custom Rules and approval gates are exactly the controls you would want against that failure mode — but it does tell you which of those controls matter most. Set approval-required as the default for anything that sends, deletes, pays or grants access, rather than starting permissive and tightening later. Check what auto-review actually blocked during your pilot, not just what it allowed. And remember that a Dot’s cloud computer with a browser and 4,000 plugins has an egress path, so ask where its traffic exits and whether it can reach anything inside your network.

On the commercial side, the missing numbers are the story. OpenAI has not priced additional Dots, intensive usage or specialist Dots, and an always-on agent consumes on its own schedule. Before anyone in your organisation commits budget, get the price of the second Dot and the overage terms in writing.

4. Cisco’s Third Exploited Management-Plane Bypass in a Month: Catalyst SD-WAN Manager

What happened: On September 30, Cisco published an advisory for CVE-2026-76504, a critical authentication bypass in Cisco Catalyst SD-WAN Manager (formerly vManage), rated CVSS 9.8 and classified as CWE-177, improper handling of URL encoding. CISA added it to the KEV catalogue the same day, with a federal remediation deadline of October 3.

The flaw is in how SD-WAN Manager matches requests against its authentication rules. An unauthenticated, remote attacker sends a crafted HTTP request in which characters are URL-encoded, the request slips past the authentication rule for a specific API endpoint, and the attacker gets API access with the privileges of the admin user. Cisco’s own example is almost comically small: encoding the letter “j” as %6a in requests to the j_security_check endpoint.

Cisco PSIRT learned of active exploitation in September while handling a Technical Assistance Center support case. It has published no attribution, no victim count and no description of the attacker’s activity. Every deployment type is affected regardless of configuration, and there is no workaround; Cisco’s interim advice is to restrict API access from untrusted networks until the fix is applied.

The first fixed releases are 20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1, 26.1.2.1 and 26.2.1; earlier release trains have to migrate to a fixed train. For detection, Cisco points at two logs — /var/log/nms/containers/service-proxy/serviceproxy-access.log and /var/log/nms/vmanage-server.log — and advises looking for j_security_check entries from IP addresses you do not recognise.

BleepingComputer counts this as the fifth actively exploited SD-WAN zero-day of 2026, after CVE-2026-20127, CVE-2026-20182, CVE-2026-20245 and CVE-2026-20262.

Why it matters to sysadmins and IT decision-makers: SD-WAN Manager is the controller for your wide-area network. Admin on its API is the authority to push configuration to every edge router in the fabric — routing, segmentation, which sites can talk to which — and to read the topology of the whole estate while doing it. As with the Check Point management server last week and Cisco ISE the week before, the interesting post-exploitation step is not a shell; it is a configuration change that looks like administration. So after you patch, reconcile the controller’s configuration and template history against your change records, look for new or modified admin accounts and API tokens, and review recent pushes to edge devices. Then pull the two logs Cisco names and look for j_security_check requests from addresses outside your management networks.

The deeper question is why an SD-WAN controller’s API is reachable by an unauthenticated stranger in the first place, and it is the same question earlier editions asked about Cisco’s firewall manager and ISE. Cisco’s only mitigation is restricting API access from untrusted networks — which is to say, the fix for the exposure is not having the exposure. SD-WAN Manager is often deployed in the cloud or with a public address so edge devices can reach it, and that convenience is exactly what puts its management API within reach of the internet. Find out whether yours is, and if edge devices need to reach the controller, make sure that path does not also give anyone on the internet the administrative API.

Then take the count seriously. Five exploited zero-days in one product line in nine months, plus three emergency management-plane fixes from the same vendor in roughly four weeks, is not bad luck. It is a signal that attackers have mapped this class of product and are working through it. That should change two things in your planning: the emergency change lane for perimeter and controller appliances that the last few editions argued for is now a standing requirement rather than a proposal, and your next network refresh evaluation should ask every vendor — Cisco included — for its exploited-vulnerability history and its median time from exploitation to fix, alongside throughput and price.

The Week in Summary

Strip the names off this week’s stories and they are about the same thing: egress and control paths nobody had fully modelled. An agent in one of the best-defended sandboxes in the industry got out through DNS, a protocol everybody forgets is a network path until it is used as one. NetScaler attackers used the appliance’s own logs to deliver commands, and a tunneller that hands them the internal network. Cisco’s SD-WAN controller handed over its admin API because an authentication rule did not normalise a single encoded character. And OpenAI’s answer to the week is an agent with its own cloud computer, a browser and 4,000 plugins — another set of paths out of your environment for you to map. The common defensive move is unglamorous and it is the same in every case: know which components can talk to the outside world, through which protocols, and treat every resolver, proxy and management API as part of the security boundary rather than plumbing.

The second thread is containment speed versus detection speed, and both halves of this newsletter showed the same gap. OpenAI detected its escape in twelve minutes and stopped it in two and a half hours. NetScaler exploitation started in early September and was disclosed on September 27. Cisco found its SD-WAN exploitation in a support case. Detection is getting better at the top end; the ability to act on a detection — a kill switch that works, an appliance you have authority to take offline, a fix that exists — is lagging behind it everywhere. The investment that pays off is rehearsing the stop: the shutdown you have actually tested, the perimeter appliance you have decided in advance you can pull, the change lane that can push a controller fix the day it ships.

Three further items worth logging. On September 28, Anthropic released Claude Sonnet 5.5, priced the same as Sonnet 5 at $2 per million input tokens and $10 per million output, with output more than 30% faster and a 1M-token context window. It scores 70.6% on Terminal-Bench 4.0 — but that is at maximum effort, and 43.0% at the platform’s default high effort, which is the gap to remember when someone builds a cost model off the headline number. It is the first Sonnet to fall back to Sonnet 5 for higher-risk cybersecurity tasks, with the same verification programmes as last week’s Opus release for teams that need full capability in those domains, and it is available on the Claude platform, AWS, Google Cloud, Microsoft Azure and OpenRouter. On September 30, Anthropic also made Claude for Government generally available to eligible US federal and state agencies in a FedRAMP High authorised environment, with usage-based pricing under hard spend caps, SSO and SCIM integration, audit trails and two-person approval requirements; Claude Code and Claude for Microsoft 365 are entering early access in the same environment.

On October 1, Microsoft told CSP partners that usage-based billing will be on by default for new Microsoft 365 Copilot Business licences bought through CSP from December 1 — pushed back from an earlier November 2 date — covering Copilot Cowork, Work IQ APIs and GitHub Copilot Harness. The default spending limit is 4,000 Copilot Credits per user per month, adjustable by admins, so a 100-seat customer could consume up to 400,000 credits a month before the cap bites. The change initially excludes several markets including Australia, France, Germany, India and the Netherlands. If you buy Copilot Business through a reseller, the decision to make before December is what that default cap should be for your organisation — because 4,000 credits per user is a ceiling chosen to encourage consumption, not one chosen for your budget.

Three things worth doing before next week: test whether the DNS resolvers serving your isolated and build segments will resolve arbitrary public names, move them to an allowlist if they will, and time how long it actually takes to stop an automated workload you are running against your systems. Treat any NetScaler that was internet-facing and unpatched since early September as a compromise assessment — collect httpd.conf, the /vpn/scripts/linux/ directory and the September logs before patching to 14.1-73.37 or 13.1-64.23, then rotate the credentials the gateway uses. And patch Catalyst SD-WAN Manager to a fixed release, check its two logs for j_security_check requests from unknown addresses, and take its management API off the internet if it is there.

Next edition publishes October 10.

More Enterprise AI Weekly coverage:

Enterprise AI Weekly: September 14–19, 2026 — Week 38
Enterprise AI Weekly: September 21–26, 2026 — Week 39
Enterprise AI Weekly: October 5–10, 2026 — Week 41