Global shipping giant A.P. Moller–Maersk has confirmed an IT security incident involving unauthorized access and data extraction from a legacy system inherited through a previous acquisition.
The company disclosed the incident on November 11 and said its cybersecurity team immediately launched an investigation and secured the affected system.
Maersk has not identified what information was extracted or how much data was taken. However, preliminary findings suggest no sensitive information was disclosed. The company said the incident appears isolated to the affected system, with no indication that other Maersk infrastructure or customer and partner systems connected through APIs and electronic data interchange (EDI) were compromised.
The incident comes nearly a decade after the company’s devastating 2017 NotPetya attack, which reportedly cost approximately $300 million.
Seemant Sehgal, Founder & CEO, BreachLock
“Acquired systems arrive with their own credentials, their own patch schedule, and connections into the parent network that were set up during integration and rarely revisited. Ownership of these systems often gets blurred during acquisitions, so any company that grew through acquisitions should know how many of these systems it inherited and what each one can still reach. A penetration test during due diligence answers that before the deal closes, while there is still leverage to fix it.”
ㅤ
John Strand, Black Hills Information Security
“This breach and the way it’s being handled remind me of the Oracle Health breach involving an acquired company’s legacy systems. It’s weird to see companies talk about an acquired system as though that somehow absolves them of responsibility.
“You bought the company. As soon as the ink is dry, securing those systems is your responsibility. Calling them ‘legacy’ doesn’t change that.
“This is why security due diligence needs to be a serious part of mergers and acquisitions. You need to understand what you’re buying, what’s exposed, and what it will take to secure it. If something catastrophic happens, pointing to the previous owner isn’t much of a defense. You can still be left dealing with the legal exposure and the damage to your customers.”
ㅤ
Damon Small, Board Member, Xcape, Inc.
“Unchecked technical debt from corporate acquisitions remains an enterprise blind spot, yet rapid containment can mean the difference between an operational footnote and a multi-million-dollar catastrophe. Maersk’s November 11 disclosure of an isolated breach in an inherited legacy system appears relatively benign, especially with core logistics platforms and partner electronic data interchange (EDI) feeds uninterrupted. Still, against the backdrop of escalating critical infrastructure attacks globally, the incident underscores the vital role freight and supply chains play in modern society. A decade ago, the devastating 2017 NotPetya campaign cost Maersk an estimated $300 million dollars, but that institutional scar tissue clearly hardened their incident response posture, enabling defenders to isolate the compromised asset before data extortion could threaten vessel movements,cargo flow, or impact customer operations in any significant way. For executive leadership, the mandate is clear: cyber due diligence during mergers and acquisitions must match the rigorous scrutiny applied to financial audits. When organizations inherit digital infrastructure without auditing obsolete servers, unmonitored databases and applications inevitably turn into prime targets for threat actors seeking an easy corporate foothold.
“Critical Takeaways
- Audit acquisition tech debt with financial fervor: Security teams must evaluate inherited legacy environments with the same rigor applied to corporate balance sheets, ensuring unmonitored systems are identified, segregated, or decommissioned promptly.
- Network segmentation preserves operations: Restricting the affected legacy system from core logistics networks and partner EDI connections prevented lateral movement and kept physical cargo operations running without interruption.
- Prior crisis investments build real resilience: The severe operational fallout from the 2017 NotPetya attack forced Maersk to mature its recovery playbooks, turning what could have been a debilitating crisis into a contained, manageable event.
“The 300 million dollar lesson from 2017 paid off: this time, the legacy server took the hit while the ships kept moving.
ㅤ
Darin Fredde, Senior Director and Offensive Security Evangelist, Ridge Security
“The most interesting part of this incident isn’t that Maersk was breached. It’s that the affected system was inherited through an acquisition. That’s a familiar enterprise security challenge. Companies acquire businesses, integrate operations, and sometimes inherit technology that doesn’t receive the same visibility, testing, or security attention as the rest of the enterprise. Maersk’s preliminary findings suggesting the incident was isolated and no sensitive information was disclosed are encouraging. But unauthorized access and data extraction still warrant investigation. The important questions are what the attackers accessed, how they gained entry, and whether the boundaries separating that legacy environment from other systems held. The lesson for organizations isn’t simply to replace every legacy system. It’s to know what you own, understand how inherited systems connect to the business, and continuously validate that the security controls protecting them work.
“An acquisition may close financially in a few months. The security obligations can last decades.”
Legacy systems can be a headache. You need to do your homework and make sure that this is one less headache for you.
OpenAI introduces 35-second kill switch to stop rogue AI agents
Posted in Commentary with tags Open AI on November 11, 2026 by itnerdOpenAI has introduced Control Room, a centralized system designed to monitor and halt AI research workloads when safety or security concerns arise. The announcement follows incidents involving autonomous AI agents acting beyond their intended instructions.
The system can stop models from generating further output within 35 seconds of a shutdown decision, with OpenAI working to reduce that delay to zero.
Control Room integrates with automated monitoring systems that can flag potentially dangerous behavior and terminate affected jobs. It is also designed to fail safely, blocking model output if the shutdown system itself becomes unavailable.
Control Room is already deployed across OpenAI’s research infrastructure, although it does not directly shut down the underlying processes. Instead, it prevents terminated jobs from receiving additional model output.
John Strand, Owner, Black Hills Information Security
“Wow. These look like the kinds of controls OpenAI should have had from the very beginning, before unleashing these systems on the internet.
“As for the 35 seconds, that seems reasonable at this stage. When you give an AI agent a task, it often spends time chewing on the problem, reasoning, and working through multiple iterations. I don’t think 35 seconds alone is likely to be the difference between a catastrophic attack and preventing one.
“But shutting down an agent is more complicated than pulling the plug. When an agent uses MCP servers to launch scans, run analysis, or spin up sub-agents, those activities may keep running after the original agent stops. You have to shut those down, too.
“That’s the real issue. Did you stop the agent, or did you stop everything it kicked off? A 35-second shutdown makes sense to me, provided it accounts for those downstream tasks and actions.”
ㅤ
Seemant Sehgal, Founder & CEO, BreachLock
“35 seconds today doesn’t hold the same power it held a year ago, or even 6 months ago. Especially since today, an attacker’s agent can run tactics and techniques in seconds once it’s fed a prompt. While I’m glad Control Room cuts off model output, governance that sits inside a frontier AI company’s own infrastructure assumes that that their monitoring sees everything the agent can reach. Every team deploying these agents will still need independent controls and verification outside that boundary, because the first time those assumptions fail, the vendor will be investigating its own system.”
ㅤ
Ryan McCurdy, Vice President of Marketing, Liquibase
“What’s interesting about OpenAI’s Control Room isn’t just the 35-second shutdown time. It’s that OpenAI has built a way to stop AI systems independently of the agents themselves. That’s critical as these systems become more autonomous.
“AI agents are probabilistic systems. They make decisions and take actions that aren’t always predictable, which is why the controls governing what they’re allowed to do need to be deterministic. You can’t depend on an AI agent to recognize when it’s crossed a boundary and decide to stop itself.
“35 seconds may be relatively quick for stopping a research workload, but it’s a long time when an agent has permission to make changes to critical production systems. A destructive database operation could be completed well before a shutdown takes effect, and stopping the agent doesn’t undo the damage.
“This illustrates why enterprises need controls at the point of execution, not just the ability to intervene afterward. If an AI agent proposes a high-risk database change, an independent policy should be able to reject it before it executes. The same standards should apply whether that change comes from a developer, an automated pipeline, or an AI agent.”
ㅤ
Darin Fredde, Senior Director and Offensive Security Evangelist, Ridge Security
“Thirty-five seconds can be an eternity in cybersecurity, but the real question is what the system can do during that window. An autonomous agent with access to credentials, APIs, or production infrastructure could initiate consequential actions long before the shutdown takes effect. I give OpenAI credit for moving enforcement outside the model itself. That’s the right architectural direction. But stopping inference is not necessarily the same as stopping execution. What happens to commands already issued, credentials already used, or actions initiated across connected systems?
“As we delegate more authority to autonomous AI, we need independent verification, enforceable permission boundaries, and the ability to contain and recover from actions; not just stop generating tokens. The effectiveness of those controls needs to be demonstrated under realistic operating conditions. A kill switch is an important safety control. Proving what stops when you press it is the real security test.”
At least OpenAI is trying to change course on its rather crappy security posture. But honestly it doesn’t really make me trust OpenAI more. You shouldn’t trust it either.
Leave a comment »