This summer, the White House rolled out the Gold Eagle Initiative, billed as an “unprecedented” effort to coordinate cybersecurity vulnerability disclosure across government and industry. It was easy to miss this news with all of the other safety concerns in the world of AI, but the timing isn’t a coincidence — and neither is the terminology. Gold Eagle is just one in a fast-growing category of security clearinghouses. Although it has already been scaled back once, recast in an August CISA fact sheet as a narrower triage layer rather than the sweeping coordination system first announced, it still indicates a trend we’re seeing in the world of cybersecurity.

To understand what a clearinghouse is, and why the number of them is increasing, it’s important to understand what has broken — namely (and hugely), the vulnerability disclosure process. For many years, vulnerability disclosure worked like this: A researcher found a bug, reported it privately, and honored an embargo period that gave vendors time to patch quietly (and hopefully quickly) and ship the fix before the bug was made public. This gave the good guys a chance to patch before the bad guys had a chance to use the vulnerability for bad guy things. The process was tedious, but it worked because the economics worked — historically, only nation-states had the resources to hunt for — or reward teams of experts to hunt for — undisclosed vulnerabilities at scale.

Of course, AI has changed all that — all of that. The average gap between the discovery of a vulnerability and its weaponization has collapsed from something measured in years to negative seven days. The bad guys are finding CVEs and exploiting them long before the good guys have had a chance to patch them. A terrifying prospect, to be sure. And it’s something I embarrassingly admit has happened to me personally several times recently.

Frontier AI models are democratizing the finding, chaining, and weaponization of flaws faster and cheaper than any team of human experts. Indeed, it’s the chaining — and AI’s mastery of it — that may be the most debilitating. In chaining attacks, two or three low-severity and moderate-severity bugs get stitched together by an AI system. On their own, these bugs are pretty unremarkable. However, by joining the “right” ones together (something AI is very, very good at), a model can achieve a full compromise.

Several major AI labs have already disclosed that their own models were used to breach unrelated systems, evidence that the old assumption about who can afford to hunt for exploits no longer holds. Anyone with API access to frontier models can now run what amounts to a small (and very efficient and intelligent) hacking team. Worse, these models can be resold illicitly to embargoed countries, and there’s an entire ecosystem of jailbreaking models to get them to do even more nefarious things.

Why clearinghouses?

At its core, the AI hacking threat is a scale problem that software development, be it proprietary or open source, was never set up to handle. It’s not just big projects like Linux and Kubernetes that are targets; it’s every one of the libraries underneath every application. There are literally millions and millions of packages available on PyPi (Python), npm (Node.js), RubyGems (Ruby), Crates (Rust), NuGet (C#/.NET), and Packagist (PHP), along with tons of smaller language ecosystems. These are ecosystems that power almost everything built today.

AI-generated vulnerability reports arrive faster than volunteer maintainers can read them, let alone verify and fix them. A single, real bug can spawn a dozen duplicate CVE filings from different automated scanners, each with its own tracking number, essentially serving as a distributed denial of service attack on the upstream. And, this is from the good guys, trying to do the right thing.

This “gap” (to put it mildly) is what clearinghouses are designed to close. Historically, a bug fix loop looks like:

1. Discover bug
2. Report to maintainer
3. Honor embargo
4. Maintainer patches
5. Release fix to the world

In the world of clearinghouses, here’s what it looks like:

1. Discover bug
2. Report it to clearinghouse
3. Receive patch
4. Clearinghouse handles the rest (handle embargos, reporting upstream, etc.)

It could look even as simple as:

1. Sign up for clearinghouse
2. Receive patches from clearinghouse
3. Clearinghouse handles the rest

The clearinghouse is essentially a trusted intermediary, run by a vendor, an association, or other entity, which triages the flood of AI-generated reports, identifies which are real, accepts or builds a fix, validates it, sends it to customers and partners, and only then works to merge it back into the upstream project. This still must be done at a pace that the upstream can handle.

There are also ethical dilemmas to handle here. It is not fair to force upstream projects to operate at the speed that for-profit and gigantic public entities require, especially large, demanding organizations like Fortune 500 corporations and governments. Remember, many people participate in open source projects for “fun”. Working for organizations demanding responses to thousands of CVE patches, faster and faster, is not fun or it would not be called work.

Assessing clearinghouses

Not all clearinghouses work in the same way. Some efforts function as a permanent fork that patch (and keep patching) the vulnerable code with AI-generated maintenance, and never reconcile with the original project. Others push every fix back upstream so it becomes permanent, which benefits the whole community. The latter seems to be the more functional option because if you can’t get your stuff back upstream, things could be locked in a clearinghouse forever. That feels a lot like vendor lock-in, as much as dressing a proprietary product in “open source” clothing does. You simply can’t have an open source clearinghouse that’s proprietary.

What else should an enterprise security team be looking for in a clearinghouse? Some hard questions to ask include:

• Can it triage the noise?
• Can it correlate multiple reports into one confirmed vulnerability?
• Can it produce a working patch, and not just an alert?
• Does it have a credible path upstream, rather than trapping users on a permanent fork?
• And, most importantly, who’s paying for it, and will they keep paying? In a word: Is it sustainable?

Clearinghouses may or may not become a viable tool in the fight to stay ahead of (or maybe just keep up with?) vulnerabilities in the AI age. Regardless, the bigger and more uncomfortable question is whether software itself needs to change. There are initiatives in place to quash entire classes of bugs: memory safety, thread safety, etc. Some are looking to write new Linux kernel drivers in Rust, a memory-safe language that structurally eliminates entire categories of the chaining bugs AI is so good at identifying and exploiting.

Other tactics include looking at compiling C/C++ with tricky new methodologies (fat pointers, or auxiliary pointers) to, again, remove entire classes of memory and threading bugs. Whether decades-old languages such as Python, Node.js, and friends can be hardened in similar ways, or will need to be rewritten from the ground up, remains to be seen. The world of open source is ablaze with experimental solutions.

For now, it’s less about a silver bullet and more about recognizing that vulnerability response has become a team sport at a scale nobody planned for. Every major bank, utility, and software vendor is running its own AI-augmented triage operation, and those operations increasingly need to talk to each other. The organizations that ask hard questions about triage speed, upstream commitment, and funding durability rather than taking a clearinghouse’s staying power on faith will be the ones standing strong under relentless vulnerability fire.        

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Most teams building AI agents are pouring effort into better memory, longer context windows, conversation summaries, retrieval systems that pull up anything the agent has ever seen. These are useful tools. But they do not solve the problem of knowing whether an action actually completed. Memory tells an agent what happened. It doesn’t tell the agent what’s true right now. And for any agent that takes real action — refunding money, changing an order, updating an account — that distinction is the whole ballgame.

Memory can remember a request without knowing the outcome

Picture a customer service agent that approves a refund. The refund actually goes through, but the confirmation response times out before the agent hears back. From the agent’s point of view, all it has is a record of a request it made, not proof of what happened next. If the agent trusts its own memory, it sees an unfinished task and tries again. The reasoning is sound. The second refund is still wrong.

More conversation history doesn’t fix this. What the agent needs is a record it can trust: the request ID, the current status, the confirmed outcome. Memory can tell you what the customer asked for. It can’t tell you what another system actually did. This isn’t a new problem; recommendation systems ran into a version of it years before agents existed.

A prediction is not the same as current intent

I spent several years building recommendation and personalization systems, and one thing became clear fast: more history doesn’t automatically mean a better decision. A recommender looks at what someone bought, browsed, or listened to, finds a pattern and predicts what they’ll want next. These are all informed guesses rather than facts. I saw this play out around election season. A customer buys several books about a candidate or a political topic and the system, correctly, learns that as an interest. Weeks later, the election is over and the customer has moved on, but their purchase history hasn’t changed. The purchase history is still accurate. It just no longer reflects the customer’s current intent. So, customer data changes with each interaction, so recommendations need to respond to new information.

Freshness in a large-scale personalization system

Early in a real-time personalization platform I worked on, one of the hardest problems wasn’t traffic volume; it was freshness. A customer’s inferred interests could lag well behind their actual recent behavior, so the system would keep confidently recommending things that no longer matched what the person wanted. We rebuilt the pipeline so that signal updates reflected recent behavior almost immediately instead of with a long delay. That gap between what the system knows and what’s currently true is small when you’re recommending a book. It’s a much bigger problem once you move from recommending content to an agent that’s authorized to act on someone’s behalf. Consider a customer who has just started a trial and is eligible for a $0 first-item offer. Personalization should show that available benefit instead of another invitation to start a trial. A fresh eligibility signal lets it change the next offer. Unlike inferred interests, trial eligibility is a recorded fact.

Stale data can produce a bad recommendation. Stale data acted on by an autonomous agent can produce a real-world mistake. Agents need more than memory; they need a reliable state.

Reliable state tells the agent what’s true right now

Reliable state is a verified record of a specific operational fact. In the refund example, the conversation records what the customer requested. The payment system records whether the refund happened. The order system records the order’s status, while current policy and permission records determine whether the action is allowed. Each fact has its own authoritative source. State can itself become stale, so the agent must check the relevant source rather than rely on its memory of an earlier answer.

This matters even after the “yes/no” check passes. A customer might withdraw permission mid-process. An order might fall outside the window where changes are allowed. And even when every check passes, the action itself can still fail partway through, so the agent also needs a safe way to retry without duplicating the damage. The action system must enforce current permissions and other preconditions when it executes, because they can change after an earlier check.

Designing a privacy-request architecture

In privacy and compliance architecture work I’ve done, a single customer request, like asking to delete their data, can trigger a long chain of downstream effects across many internal systems. The challenge wasn’t any one system doing its job correctly; it was making sure there was one authoritative, centralized place that recorded whether the overall request had actually been completed, rather than each system independently assuming it had. That’s the same principle an agent needs: a system of record it defers to, rather than trusting its own memory of what it asked for.

A few categories of tooling exist specifically to solve different slices of this “what’s true right now” problem:

• Business state/workflow databases, Postgres, DynamoDB, Spanner, Cosmos DB.
• Workflow orchestration, Temporal, AWS Step Functions, Azure Durable Functions.
• Agent state, tools like LangGraph checkpoints.
• Session/cache state, Redis, Memcached.
• Event history, Kafka and similar streaming systems.
• Permission state, Open Policy Agent, Amazon Verified Permissions.

None of these replace the others. A production agent usually needs several of them working together, which raises the next question: what happens when an action only partly succeeds?

Safe actions need a receipt and a recovery plan

Every important action an agent takes should carry a unique identifier, like a receipt number. If the response gets lost, the agent must reuse that ID for the same intended operation. The receiving system must recognize the ID and prevent the operation from being applied twice, within its supported deduplication window. This is how an idempotent API makes retries safe; attaching an ID alone is not enough. A preliminary status check cannot prevent two concurrent requests from executing the same action. The AWS Builders’ Library explains this design in Making retries safe with idempotent APIs.

Teams also need reconciliation, regularly comparing what the agent believes happened against what the system of record actually shows, the same way you’d check a receipt against a bank statement. When they disagree, someone needs a clear next step: recheck, reverse the action, or escalate to a human. None of this works without clear ownership.

Reconciliation at high transaction volume

In large-scale commerce infrastructure work, we treated “did this transaction actually complete” as something that could never be answered from memory or assumption, at high volume, even a small rate of unconfirmed or duplicated actions adds up to real customer impact. We built reconciliation directly into the system so that what one part of the pipeline believed had happened was continuously checked against what was actually recorded, with idempotency built in to prevent retries from creating duplicate transactions. The lesson generalizes directly to agents: never let an action retry blindly without checking a source of truth first.

Before you give an agent more autonomy, decide who owns each critical fact and who’s responsible for cleanup when something breaks, because something eventually will.

Monitor the decision, not just the model

All of this changes what a team should actually be watching. Latency, cost and model accuracy matter, but none of those metrics will tell you that an agent acted on a stale permission or announced a refund that never happened. For each consequential decision, trace the information used, its freshness, the rules checked, the attempted action and the confirmed result. What you actually want to be able to trace is:

• what information the agent used
• when that information was last updated
• which rules were checked before acting
• what action was actually attempted
• what result was recorded afterward

As a leader, the job isn’t just watching model quality; it’s making sure every piece of information an agent acts on has a clear source and a way to verify it’s current. Agents are genuinely good at interpreting messy, ambiguous situations and deciding what to do. But they shouldn’t be the record of truth themselves. That job still belongs to the systems built to hold it.

Memory tells an agent what happened. Reliable state tells it what’s true now, and whether it’s safe to act.

One of the first questions I ask devops organizations is to walk me through their development and operations standards. What are the non-negotiable devops practices? What are the data governance first principles? What observability standards are in place? How is security embedded in devops? This is the starting point. From there, we might review standards on how functional requirements are written. For businesses developing AI agents, I’ll ask about their non-functional requirements (NFRs) and how testing is performed.

Now that many devops organizations are using AI code generators, vibe coding, and applying spec-driven development practices, the questions increase. How does the AI know your organization’s standards? What processes monitor and enforce these standards? What are the developer responsibilities for owning the outcomes?

“Generative AI will happily hand you the movie set of an app with looks of a house from the street. The doors and windows open, and the demo runs clean,” says Mike Toole, director of security and IT at Blumira. “Behind the facade, there’s no plumbing and no wiring: no input validation, no auth boundaries, nothing actually holding it up. If your only gate is ‘does it run and look right,’ you’re shipping a set, not a building.”

One report shows that 92% of developers use AI coding tools daily in 2026 and that 41% of all global code is now AI-generated. Will all that code deliver value, operational issues, or mounting AI debt? I spoke to several experts about how to keep AI-generated code aligned with organizational standards and how to define an AI code generator’s context beyond just functional requirements.

Document like a construction specification

A general contractor in the construction industry will review building information models that provide a view of what they are developing. But many of the details are in the construction specifications, including component stipulations and performance requirements. Devops teams without equivalent documentation for their organization, architectures, and applications may have gotten away with this omission in the pre-AI era. But institutional knowledge and compliance requirements are the context AI code generators need before you share the first functional prompts with them. 

“AI-generated code stays aligned with engineering standards only when those standards are explicit, available, and difficult to bypass,” says Eddie Zhou, founding engineer at Glean. “Put architecture, approved libraries, data-handling rules, security controls, naming conventions, observability, test expectations, and non-functional requirements into specs and automated checks. Then, ensure you give the model that context but treat its output as untrusted until it passes the same reviews, tests, scans, and production monitoring as human-written code.”

Overcoming tribal knowledge was always challenging as devops teams had too much pressure to push features and little incentive to maintain documentation. Two of my top AI leadership skills are change management and agile collaborative leadership, because devops teams need practice alignment while introducing AI capabilities.  

Zhou adds, “AI amplifies ambiguity and weak governance as efficiently as good engineering. If standards live only in tribal knowledge, AI will expose that problem, not solve it.”

Encode non-functional requirements as automated tests

The problem with requirement documents and reference architectures is they aren’t directly enforceable with human or AI developers. Once a devops team agrees on standards and documents them, the next step is to develop approaches to encode them as automated acceptance criteria in CI/CD pipelines.

“AI code generators and human developers optimize for functional correctness—making the feature work—and quietly skip the non-functional requirements where most of your real standards live, including performance, security posture, error handling, observability, and auditability,” says Michael Bevilacqua, vice president of AI product management at Adeptia. “Encode your NFRs as executable acceptance criteria that generated code must pass before it merges, so ‘aligned with our standards’ becomes a gate the pipeline enforces on every change.”

An example: Performance requirements stating that all web pages should have a total page weight under 2MB can be validated during the pull request, and requiring the time to first byte (TTFB) to be under 800ms can be automated in CI/CD in a staging environment.

Requirements for stakeholders and AI

Architecture and automated non-functional requirements covering performance, security, and other organization-level compliance requirements should become the base-level context standards shared with AI-code generators. The next set of considerations for setting accurate contexts starts with application- and agent-specific requirements, their intended use cases, and specific compliance guardrails.

“CIOs are mandating AI to build apps faster, but many are realizing speed isn’t the bottleneck because more code doesn’t automatically create business value,” says Matt Healy, senior director of product strategy and marketing at Pegasystems. “Before developers write any code, organizations must understand customer needs, assess legacy systems, stay current with regulations and best practices, map enterprise architectures and integrations, and align business and IT.”

Consider three stages of understanding requirements. Once stakeholders set business value and intent, developers must first align on an implementation strategy and discuss performance, cost, and other trade-offs. Then, developers should reconvene with stakeholders and review implementation trade-offs. Healy adds, “On large projects, defining the solution and success metrics can take as much time as building it. Leaders aren’t just using AI to accelerate development, but to help executives, business analysts, product owners, and IT teams collaborate more effectively.”

The third stage is gathering the goals, user requirements, and implementation approach into a development-specific context. But we’re not done yet, because data requirements and operations considerations must also be included in the context fed to AI code generators. 

Build governance into the specs

How the application or AI agent being developed can use the data it has access to requires clear specifications. Data governance programs should have standards based on data sets, defined roles, entitlements, and usage specifications.

Kash Mehdi, vice president and field CTO at Reltio, says the teams that are pulling ahead treat data governance as an input to AI, not an audit after it. “They ground their tools in trusted, semantically consistent data models, approved specs, and security policies, so the AI inherits the organization’s standards instead of inventing its own. Without that governed context layer, you don’t scale from a handful of AI-assisted workflows to thousands; you just accumulate inconsistent code faster,” Mehdi says.

Here are two options to consider in creating standards: First, establish repurposable data sets as data products with defined integrations and usage rules. Organizations with many data sets and integration points should consider data fabrics. The second (and key requirement) is to standardize the format of data contracts, using human- and machine-readable formats so that data owners, users, and AI code generators operate from a consistent set of principles.  

“AI writes code that compiles and passes tests but quietly ignores your data contracts, so the failures show up in production as corrupted state, not build errors,” says Ed Huang, cofounder and CEO of TiDB. “The fix is to make governance machine-checkable, including schema constraints, access policies, and data-quality rules enforced at the database layer where the AI can’t route around them, not documented in a wiki the model never reads. Treat the database as the enforcement point for your standards, and it stops mattering whether a human or an agent wrote the query.”

Observability and testing first

When AI generates the code, a best practice is to use static application security testing (SAST) and other code analysis tools to perform automated code reviews. Another best practice is to put applications through penetration testing and other application security validations. But many of these tools are outside in view of what the AI developed. To get an inside view, observability and testing requirements must be included as a standard, with specific requirements around the key transactions you’re asking the AI to develop.

Sanjay Gidwani, CEO and founder at Kosmos, says, “More code volume just means more time spent investigating, and the fix isn’t reading the code more carefully before it ships. It’s connecting the observability signal, the thing that broke, back to the specific change that caused it. Without that link, you’re doing the same manual investigation as before, just with a bigger haystack.”

Testing requirements must go beyond generating automated tests, using synthetic data to expand the test patterns, and implementing continuous testing. “Instead of testing one input against one output, test whether an invariant holds across a wide range of generated inputs, which is a good fit for AI’s unbounded input space and non-deterministic outputs,” says Lior Gavish, cofounder and CTO at Monte Carlo. “I treat it as one layer in a stack with evals mapping the input space, property-based testing stress-testing it for edge cases and brittleness, and observability on live traffic checking whether production is drifting from the properties you defined as non-negotiable.”

Package and evolve the standards

Ed Frederici, CTO at Appfire, recommends codifying standards as machine-readable rules, including linters, formatters, and type checks. Merge the organizational and application standards into one context shared with the AI code-generating tool. His other recommendations:

• Enforce standards in continuous integration so violations block merges.
• Give the AI persistent context, such as CLAUDE.md, style guides, and architecture docs.
• Keep changes small and reviewable.
• Require human review of every pull request because AI-generated code must get the same scrutiny as any contributor’s. No exceptions.
• Back this approach with solid test coverage to catch regressions.
• Periodically audit for drift as your standards evolve.

It’s also important to remember that as code must be extended and maintained, so must the underlying development standards. “AI-generated code only stays aligned with your standards when it’s powered by a context engine that keeps learning, not a static snapshot of your rules,” says Itamar Friedman, CEO and cofounder at Qodo. “That means an engine that continuously adapts to your codebase’s evolving standards, your team’s PR history, and the prior decisions your engineers have already made, so the AI isn’t just following instructions but actually understands how your team works.”

As more devops organizations rely on AI code-generating tools, developers have an important opportunity to develop the standards and automated validations required to ensure what is built meets engineering and compliance requirements.

One of the problems facing those who develop agents today, especially when building agents that run on edge systems with a mix of local and cloud AI, is trust: ensuring that the code that runs on users’ PCs doesn’t access private data or call unexpected APIs. How can we keep systems that don’t have predictable operations under control, when it’s that very unpredictability we’re relying on, as they orchestrate calls across local and remote systems, building and running workflows on the fly.

If you worked on agents the first time around, back in the 1990s, when they were tools designed to manage and run long workflows for users, you’ll recognize the problem. After all, the security risks associated with delivering arbitrary code to PCs and servers were what blocked those first agents from wide adoption (that and the complexity of building and sharing the necessary runtimes).

Securing modern agents

Computer systems have evolved considerably over those decades, especially with the arrival of hardware support for virtualization, a technology that Microsoft has built into much of its modern platform. Hardware virtualization is key to technologies like secure containers, to Windows’ own internal isolation model for critical OS components, and to cross-platform tooling like the Windows Subsystem for Linux. New tools like the WSL container platform have begun to extend that virtualization model with SDKs that allow programs to launch and control the virtualization life cycle.

Virtualization also underpins Microsoft’s approach to building a trustworthy framework for agent operations, allowing them to operate in a secure manner by isolating their operations from the operating system as a whole, locking down access to functionality and running them in secure containers and microVMs. With agents working autonomously, it’s essential to keep them isolated from desktop systems, giving them access only to the services they need — as examples of badly configured agents with overly broad prompts deleting files have shown.

Developers need tools to manage that isolation, allowing them to develop code in a permissive environment, before shipping locked-down applications that operate with policy-based restrictions. This approach needs tooling to build and manage those restrictions, providing a framework based on managed, isolated containers. This is where Microsoft Execution Containers (MXC) come into play.

What are Microsoft Execution Containers?

Intended to be cross-platform, MXC offers Windows, macOS, and Linux controls, working with more than one virtualization framework. The tooling is designed to offer a common abstraction layer, so you only need to build policies once before delivering them to all supported operating systems and virtualization environments. By using policies to control payloads, MXC can provide different levels of control for different workloads. An agent that’s designed to provide personalized search will need fewer guardrails than an OpenClaw-like system that’s being set up as an agentic personal assistant with full access to your data and applications.

An early adopter of MXC is GitHub Copilot. Here a single command in any CLI session (once you have enabled experimental mode) switches you into sandboxed mode with limited access to your file system (locking it down to your PATH, your working directory, Windows temp folders, and your profile), with outbound-only connectivity. There is a config option that allows you to open more directories if you need wider access, but the out-the-box guardrails should help reduce risks to your code from out-of-control agents.

Getting started with MXC

MXC is an open-source project, written in Rust, with the project hosted on GitHub. It’s configured using JSON and provided with a set of TypeScript SDKs that help manage the sandbox life cycle, which is defined as a set of steps: provision, start, execute, stop, de-provision. Sandboxes can be run as “one-shot” (a single execution) or as part of a long workflow to support the local elements of a business process.

Getting started requires a Rust tool chain and a recent build of Node.js, along with npm. Although regular releases do include binaries, it’s still best to clone the MXC repository and build it yourself. (Release source code is available, but working with the repository keeps you up-to-date with the latest changes.) The latest release, MXC 0.8.0, offers the most up-to-date set of policies, which are essential for managing the sandbox guardrails used to corral agents. It also improves networking support, with better security and improved tooling for delivering policies across different sandbox environments.

It’s a good idea to spend some time understanding the MXC policy schema. This is where you learn what MXC can do and what it can’t. It’s important to understand that MXC cannot provide more isolation than you get from a locked-down virtual environment, and that it can’t switch virtualization endpoints on the fly. The schema documentation shows the principles that are used by MXC’s development team. For example, they indicate that policies are an expression of intent, that the enforcement mechanisms are implemented in the tooling, and that the default position on any policy is “deny.” Thus, users need only define the policies they want to have a more permissive approach, as having no policy definition is by default an opt out.

Further, the tooling is designed to be cross-platform. You need only define policies once, and the Windows, macOS, and Linux versions of MXC will implement them on a target sandbox. How they are enforced will differ among the platforms and sandboxes, but whatever MXC does, it is driven by user intent. Putting the user requirements first is key, as the purpose of MXC is to provide a way for users to trust agents and to know that agents won’t run amuck and destroy data.

Using MXC to understand agent behavior

If you’re using MXC to develop agents and you want to tune the rules it uses, you can run MXC in audit and learning modes. This allows operations that would otherwise be blocked; instead of denying the operations, it logs them along with other operations, allowing you to tune your policies to actual agent behavior. Of course, it’s a good idea to run audit and learning modes on a virtual machine, or on a scratch test install, to ensure that your development systems are not impacted by an uncontrolled agent.

Once you have written a JSON policy, you can either use it either to spawn and run a sandbox directly or to generate a sandbox-specific configuration file that can be used with multiple sandboxes. If you take the latter approach, you can edit the generated configuration JSON and use it to launch sandboxes programmatically. It’s important to note that whichever approach you take, MXC lets you avoid working with kernel-level tools to manage hypervisors and their associated networking.

Interestingly, one of the supported isolation environments is Windows Sandbox (WSB). While this lightweight desktop sandbox is often used as a development tool, it can be configured to launch with managed access to defined selections of the host Windows file system. Although the applications you want to run in a WSB sandbox must be installed explicitly, it’s easy to imagine an MXC-managed agent using Windows Sandbox with a set of scripts to install a pre-defined set of applications, with mapped read-only access to a subset of the host’s files. The agent could then use its own APIs and local Model Context Protocol (MCP) servers to work with local data in the background of a user’s own sessions, treating the agent as a user’s “shadow.”

Locking down microVMs with MXC and Hyperlight

Finally, there’s even scope for working with microVMs that host single-process applications and microkernel-like environments, using technologies like Hyperlight to host agents and other high-risk applications, with MXC providing additional isolation. This approach allows a low-risk agent orchestrator to launch higher-risk agents as needed, without compromising overall security.

By using microVMs, you’re able to manage resources more effectively, running a dense network of secure agents with the same resources as another VM might use for one agent. It’s an approach that allows you to conserve resources by spinning up and tearing down microVMs as needed, something that will be useful in constrained edge environments.

Microsoft also is using MXC in conjunction with its cloud-based virtual PC environments, improving isolation and protection in its Windows 365 for Agents Cloud PCs. Here you can pre-configure virtual environments where agents can operate without affecting users’ systems, by working with cloud replicas of local systems that can be reset in the event of sandbox escapes or other failures.

MXC is still a very young project, and the final release is likely to differ considerably from the current preview release, as both the code and its supported sandboxes evolve. For now, though, MXC is well worth investigating as a way of securing agents that run on edge endpoints as well as agents that run in your own workflows, using tools like the ones built into GitHub Copilot.

I’ve had a version of the same conversation probably 30 times in the past year. A VP of engineering or a senior SRE describes their observability stack — the dashboards they’ve built, the alerting they’ve tuned, the Datadog or Grafana setup they’ve spent months getting right. And then they describe the last major incident. How the alert fired in seconds. How the dashboard showed exactly where the degradation was. And how their team still spent two to three hours figuring out what caused it before they could fix anything.

The framing I hear most often goes something like this: “We can see everything. We just can’t explain it.”

That gap between seeing and explaining is worth digging into, because it’s quietly become one of the more expensive problems in operations.

What observability was built to answer

Observability tools are excellent at what they were designed for. They surface what is happening inside systems — latency spikes, error rates, resource exhaustion, dependency failures — and they do so at scale, in real time. That capability is foundational. Without it, you wouldn’t know something broke until a customer told you.

But observability was built around a specific question, what is happening inside the system right now? It answers that question well. A different question, why is this happening and what triggered it, sits mostly outside its reach.

Those sound similar. They are not the same question.

“What is happening” lives in the infrastructure layer: metrics, traces, logs. The observability stack captures it. “Why is it happening” often lives outside the infrastructure entirely, in a deployment that went out two days ago, in a support queue that started spiking before the alert fired, in a change record that engineering approved last sprint. That context isn’t in the telemetry because it was never meant to be.

The investigation that precedes the fix

When a customer-facing incident occurs, the information that would explain it is rarely concentrated in one place.

Engineering is looking at the infrastructure signal. They know what the system is doing, but not which customers are affected or what those customers reported before the monitoring alert fired.

Support has the cases, the complaints written in plain language by people describing symptoms they can’t name technically. Support often knows something is wrong before engineering does, but the deployment history isn’t a system they can search.

Somewhere in Jira or a CI/CD pipeline is a record of what changed and when, with a timestamp, an author, and a scope. That record doesn’t know about the support cases or the anomaly.

So somebody has to connect all of it by hand. That means reading the customer complaints, cross-referencing the deployment history, holding multiple systems in their head simultaneously until the pattern surfaces. That is what the investigation actually is; not problem-solving, but reconstruction.

It takes hours. And it runs entirely before the resolution process can begin. Mean time to resolution (MTTR), the metric most teams are tracking and trying to improve, measures what happens after the investigation ends. The investigation itself is outside the frame.

Who actually does this work

This is the part I think gets systematically under-reported.

The manual correlation work does not fall to anyone with spare capacity. It routes to whoever knows the system well enough to read across these different views simultaneously. The engineer who remembers what shipped last week and why it was unusual. The support lead who can translate a customer’s description of a problem into a technical hypothesis. The person who has been around long enough to recognize the pattern.

That person gets pulled from whatever they were doing. Not because they are available, but because the investigation requires them specifically.

In my experience this is not an edge case. It is a structural feature of how incident response works when the relevant signals are distributed across systems that do not talk to each other. The investigation always finds the person with the most context. And that person is never the most available; they are the most consequential.

The hours they spend reconstructing a timeline are hours they are not doing the other things only they can do. That cost is real and it compounds. It shows up in velocity. In recurrence. In the quiet attrition of senior people who have been in the war room one too many times. It does not show up in MTTR or any incident metric most organizations track.

Two kinds of work

There is a distinction that rarely gets made in incident response conversations: the difference between investigation work that requires human judgment and investigation work that is, at its core, data assembly.

Deciding whether to patch or roll back requires judgment. So does knowing which customers are actually affected and which alerts are noise. These are high-context calls that require judgment that takes years to develop.

Cross-referencing timestamps across Jira, Salesforce, and a deployment dashboard to determine which change shipped before which customer complaint started; that is data assembly. It is tedious and time-consuming. It is what consumes the first two to three hours of almost every serious incident.

The problem is these two types of work have always arrived bundled together. The person who can make the judgment call also has to do the assembly, because no system was built to do the assembly for them. So your most experienced engineer — the one whose judgment you actually need — spends the majority of the investigation doing work that is far below their capability. Work that is numbing, not demanding. Work that clears their day and produces, at the end of it, a starting point for the actual decision.

That’s the waste that rarely gets named. Not the hours themselves, but the quality of what those hours contain.

What changes when they’re separated

The signals that would explain why an incident happened are already sitting in your systems. The customer cases, the deployment records, the infrastructure signals. They were there before the alert fired.

The investigation cost is a correlation problem, not a data problem. The data exists. It has just never been assembled automatically.

This is where a newer category of tooling is starting to take shape, sometimes described as operational intelligence: software that sits across observability, ticketing, and deployment systems and does the cross-referencing automatically, before a human ever opens a second tab.

When that assembly work is separated from the judgment work, the picture changes. The engineer in the war room arrives with a structured view of what happened, the deployment, the cases, the timeline. Their job becomes confirming it, refining it, and deciding what to do next. That’s the work they’re actually good at, and the reason they became engineers in the first place.

The organizations that get ahead of this won’t necessarily have better engineers or better observability stacks. They’ll have recognized that the investigation itself is a workflow, not an inevitability, and that data assembly and human judgment are separable. As AI-driven correlation tools mature, that separation is where the real leverage in incident response is likely to come from.

The observability stack tells you an incident is happening. What teams need next is the context that explains why. One of those capabilities has matured significantly over the past decade. The other is where the work is now.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

AI agents are being connected to real systems faster than most organizations are learning how to secure them. That should concern us.

The first wave of AI security discussion has been useful, but limited. The industry has learned the vocabulary: prompt injection, indirect prompt injection, tool misuse, data leakage, excessive agency, unsafe retrieval, and broken authorization boundaries. These terms are important because they give teams a way to talk about risk. 

But vocabulary is not containment.

The harder problem is what happens after a dangerous behavior is discovered. A team may adjust a prompt, restrict a tool, add a guardrail, or change the surrounding application logic. That may solve the immediate issue. What it does not automatically solve is the next release, the next model change, the next tool integration, or the next developer who unknowingly breaks the assumption behind the original fix.

This is where AI agent security still feels immature. In traditional software engineering, serious bugs become regression tests. The lesson is captured in code so the same failure cannot quietly return later. Security should work the same way. Agentic systems need a way to preserve discovered failures as repeatable checks.

That is the gap the OWASP Agent Security Regression Harness is trying to address. As a community-led open-source initiative within OWASP, this project aims to turn security insights into practical engineering work.

Agent security is becoming a systems problem

A chatbot can give a bad answer. An agent can take a bad action. That difference changes the security model.

Once an AI system can call tools, inspect repositories, query databases, open tickets, summarize internal documents, interact with APIs, or trigger workflow automation, the boundary is no longer just the model. The boundary includes permissions, tool design, application logic, data flow, logging, authorization, and the assumptions developers made when they connected everything together.

The risk is not limited to strange model behavior; the risk is system behavior. An agent that reads untrusted content and treats it as instruction is not merely confused—it has crossed a trust boundary. An agent that leaks private context through a tool call is not just producing a bad response; it is exposing data through an action path. These are the kinds of failures teams will face as agents move from prototypes into production.

The security industry has seen this pattern before. Cloud platforms and CI/CD pipelines increased leverage, making teams faster but making configuration errors more consequential. Agentic AI is another increase in leverage. That is why a one-time review is insufficient. Regression testing exists for exactly this kind of problem.

The missing workflow in agentic AI

Security teams do not need another reminder that AI agents can be manipulated. They need a workflow that turns manipulation into evidence. A hidden instruction inside a support ticket should not remain a warning; it should become a scenario that can be rerun. A tool call that leaks context should become a check with a clear failure condition.

The value lies not only in finding the first failure, but also in preserving the lesson. Production incidents become postmortems, serious bugs become tests, and security findings become backlog items. AI agent security should not be exempt from that discipline simply because the system includes a model.

The challenge is that agents are harder to test than traditional code. A brittle test that expects one exact sentence will fail in real-world conditions. Useful agent security tests must focus on outcomes. Did the agent cross a boundary? Did the agent call an unsafe tool? Did it disclose protected data? The OWASP Agent Security Regression Harness provides a standardized way to work on these questions in the open, focusing on practical, reproducible tests.

Why OWASP matters for AI

OWASP is valuable when it turns security problems into shared practice. The OWASP Top 10 did not eliminate web application vulnerabilities; its value was giving teams a common language and a practical reference point. AI agent security now needs the same kind of shared structure.

The field is moving quickly, and fast-moving fields tend to produce two unhelpful extremes: one side turns everything into hype, while the other turns everything into fear. A regression harness is a more useful answer because it is narrow and practical. It does not claim to solve every AI security problem, nor does it replace threat modeling or architecture review. It simply provides a necessary method for teams to prove that their controls hold after the system changes.

OWASP project stewardship

Open-source security projects need clear technical direction to turn a broad concern into something engineers can understand, run, and maintain. Under the leadership of OWASP Project Lead Mert Satilmaz, the OWASP Agent Security Regression Harnesshas moved past a theoretical idea into a functional tool. Satilmaz is a widely known leader in the AI security community, and this is reflected in the practical direction he has set for the project and the engineering skill involved.

The project benefits from a focus on release discipline, contributor workflows, and wide adapter coverage—supporting everything from the OpenAI Agents SDK to LangChain/LangGraph. By generating machine-readable results, it allows security teams to integrate these checks directly into CI pipelines. This approach treats agent security as a systems engineering problem rather than just a model behavior problem.

The method is the contribution

One OWASP project will not solve agent security by itself. That is not the point. The important part is the method the project represents.

AI security needs to become less dependent on warnings, one-off demonstrations, and claims that are difficult to verify. It needs more repeatable scenarios, clearer evidence, and better ways to test system behavior under security constraints. Teams should not be satisfied with saying a weakness was fixed. They should be able to prove the relevant control still holds after the system changes.

The best security work often looks boring from a distance: a harness, a test case, a clean project structure, and a workflow that lets another engineer reproduce the problem. AI agents will continue to become more capable and more connected to sensitive systems. Security teams need methods that are as practical as the technology is powerful. Regression testing is one of those methods, and adopting this workflow is an important step toward making secure AI a reality.

GitLab has released GitLab 19.2, an update to the company’s devsecops platform that allows teams to fix vulnerable dependencies automatically, use Security Review Flow to catch logic flaws that scanners miss, and run AI agents straight from the terminal, the company said.

Highlights in GitLab 19.2 include the following:

• Dependency Scanning Auto-Remediation, in public beta, uses AI to fix build-breaking changes and iterates until your pipeline passes, with every change governed by your existing gates and audit trail.
• Security Review Flow, also in public beta, analyzes code changes as a security engineer would and catches authorization gaps, business-logic errors, and race conditions that static scanners structurally cannot see.
• GitLab Duo CLI, now generally available, gives developers access to agents and multi-step agentic flows for all software life cycle tasks without leaving the terminal. 
• Custom Flows, now generally available, let teams replace manual multi-step workflows with agentic automations for software development, triggered by GitLab events.

“Coding agents made it possible to generate far more code and moved the bottleneck downstream to reviews and security,” said Manav Khurana, chief product and marketing officer at GitLab, in a statement. “GitLab 19.2 puts agents to work on that bottleneck: fixing vulnerable dependencies, catching the flaws scanners miss, and automating the steps in between with a person still approving what ships.”

Microsoft addressed 722 CVEs this month once the 427 Chromium upstream relays are set aside — roughly three times a normal cycle and one of the largest single months in recent memory. Two vulnerabilities arrive under active exploitation: an elevation of privilege in Active Directory Federation Services (CVE-2026-56155), and an elevation of privilege in SharePoint Server (CVE-2026-56164). A third, a BitLocker security feature bypass (CVE-2026-50661) is publicly disclosed but not yet exploited.

The July 2026 Patch Tuesday earns Patch Now recommendations for Windows, Office, Exchange, and SQL Server. SharePoint has two critical RCEs on top of its exploited zero-day, and Exchange Server returns with a critical on-premises spoofing flaw. Adding to our (dear) administrator’s efforts, SharePoint Server 2016/2019 and SQL Server 2016 all reach end of support today. The Readiness team has provided a handy infographic of the expected risk profile of this month’s Patch Tuesday updates.

(More information about recent Patch Tuesday releases is available here.)

Known issues

The July release note flags known issues against the following updates:

• BitLocker recovery prompt on first restart – the PCR7 recovery condition tracked since April remains live on the platforms that did not receive the Boot Manager servicing fix (Windows Server 2022 and Windows 10 22H2). Devices with BitLocker on the OS drive, the Group Policy “Configure TPM platform validation profile for native UEFI firmware configurations” set with PCR7 included, and Secure Boot State PCR7 Binding reported as “Not Possible” may be prompted for the recovery key on the first restart after installing this update. This month’s publicly disclosed BitLocker security feature bypass (CVE-2026-50661) keeps the component in focus.

• WSUS synchronization error details suppressed (Windows Server 2025 and 2022) – WSUS no longer displays synchronization error details in its error reporting, a deliberate change made to address the Remote Code Execution Vulnerability CVE-2025-59287. Sync still works, but administrators triaging a failed synchronization lose the detail pane and must fall back to the SoftwareDistribution logs.

Windows Update can still replace manually installed graphics drivers with older OEM versions from the catalogue (the four-part Hardware ID ranking issue acknowledged on the Hardware Dev Center). The two-part HWID pilot runs to September 2026.

Major revisions and mitigations

Between the June and July Patch Tuesdays, MSRC Security Update Guide notices updated 651 reported CVEs across six notification dates (15, 19, 26 June and 3, 8, 11 July), 532 of them routine Chromium upstream re-publications. Of the roughly 30 Microsoft revisions, almost all were cross-platform Office catch-up with no bearing on a Windows enterprise estate. No further action required for IT administrators for this Windows update cycle.

Windows lifecycle and enforcement updates

This is the deadline cycle June pointed at. The July end-of-support wave lands today, and it collides with the month’s heaviest patching. SharePoint and SQL Server take some of their most active security updates ever on platforms receiving their last.

• SharePoint Server 2016 and 2019, Project Server 2016 and 2019, SQL Server 2016 and InfoPath 2013 have all reached end of support. SQL Server 2014 ESU Year 2 reaches end of support today. SharePoint 2016/2019 take an actively exploited zero-day and two RCEs this cycle, and SQL Server 2016 takes a critical RCE, all as their final security update. Now is the time to get moving on updating these platforms.

The 2011 Secure Boot certificate expiries have now passed; devices that never took the Windows UEFI CA 2023 key updates under CVE-2023-24932 can no longer receive updated boot components, with the Windows Production PCA for the boot manager still ahead on 19 October 2026. Kerberos RC4 hardening (CVE-2026-20833) has been in enforcement since April 2026; the July 2026 update removes the RC4DefaultDisablementPhase rollback control that let administrators defer it, making enforcement final.

Microsoft’s July 2026 Patch Tuesday is a security-only release: 180 test-guidance entries, 14 of them high risk (June had one). Printing and graphics are the centre of gravity: win32kfull.sys, the kernel-mode window manager, is the most-patched binary (14 entries), and seven high-risk flags sit alongside it – the Print Spooler, four win32k entries, and two GDI+ metafile entries. NTFS is the second theme, with 10 entries, two high risk. Every entry reports no functional changes – it’s pure regression validation. The packages span Windows 11 26H1 back to Server 2012 ESU.

Printing and graphics (high risk)

The Print Spooler flag centres on shared printers, whose queue status must track jobs accurately; the win32k flags cover 32-bit application printing, font rendering in printed and exported output, on-screen rendering, and window management; the GDI+ flags cover metafiles.

• Share a printer from a print server, print from a separate client in varied sizes and formats, and cancel a job, confirming the queue reflects every state change
• Print from your 32-bit applications, and print text-heavy, graphics-heavy, and multi-page documents to physical and virtual (PDF or XPS) printers, repeating after orientation, scaling, and resolution changes
• Export documents with varied fonts to PDF and confirm fonts and layout survive; render EMF+ files that apply effects to very large images, and convert EMF files to WMF
• Open and close windows rapidly, drive common dialogs by mouse and keyboard, and close parents with children open – no orphaned windows

Storage and file systems (high risk)

Both NTFS high-risk flags target integrity – extended attributes, and volume recovery after an unexpected shutdown. File History carries its own high-risk flag on clients. A Windows Server 2025-only bundle across boot, BitLocker, and ReFS demands the full Secure Boot/BitLocker matrix. Eight entries hit Server 2025 alone, including WSL, GPU partitioning, and a scripted Windows Server Backup pass repeating recovery after rolling the date 90 days forward.

• Exercise NTFS extended attributes – older-system EAs, backup workflows that preserve them, concurrent same-file operations where supported – with antivirus, encryption, or storage filters active
• Simulate an unexpected shutdown during file activity, verify the volume mounts intact, run chkdsk, and confirm indexing, shadow copies, and backup still work
• Run a full File History pass: back up, modify and back up again, exclude folders, change frequency, move the destination
• On Server 2025, boot all four Secure Boot/BitLocker combinations, in standard and confidential VMs where supported

Devices, input and networking (high risk)

Three further high-risk flags land here: HID input (hidparse.sys with win32k) – touch, keyboard, mouse, touchpad, through disconnects and restarts; the WinSock bundle (afd.sys plus Bluetooth and multicast drivers); and IrDA. The heaviest ask is not high risk at all: the NetAdapterCx driver (24H2/25H2, Server 2025) wants 500-plus adapter enable-disable cycles under Driver Verifier.

• Run the connectivity suite: browsing, large downloads, mapped drives, an RDP session idle 30+ minutes, a Teams call, an hour of streaming, and localhost apps such as Docker or WSL
• Stress Bluetooth: pairing, 10+ minutes of audio, input after idle, and reconnection after sleep
• Where infrared hardware exists, transfer a file and run at least 100 connect-disconnect cycles
• Sweep the rest: DNS Server (zone data must stay under its configured database directory), the client resolver (five entries), DHCP Server (five entries), SMB, NFS, Message Queuing (five entries), RRAS administration, client VPN, and WinHTTP/WinINet consumers

Other windows components

Windows Installer itself is patched: testing should include application install, uninstall, repair, and force a rollback. Hyper-V wants virtual-switch traffic as part of its testing exercises with Virtual Filtering Platform policies enforced. Sixteen media-related security entries cover playback, HEVC and MPEG-TS, USB audio, and MIDI 2.0.

Shell hardening and LSA isolation

These two entries are a little different from the rest of the cycle: they ask you to confirm a security behaviour actively works, not just that nothing regressed. A pass here means the protection fired, so treat them as functional checks rather than box-ticking.

• Shortcut handling (windows.storage.dll; Windows 11 23H2 and earlier, plus Server 2022): drop a shortcut file carrying the Mark of the Web into a folder and confirm the system refuses to extract its icon and leaks no NTLM credential hash – include the zero-click paths, where the icon would otherwise render without you opening anything
• LSA isolation and KeyGuard (24H2/25H2, Server 2025): run the supplied PowerShell validation script, which turns on Virtualization-based Security if it isn’t already, exercises KeyGuard key operations in both required and best-effort isolation modes, and reports pass or fail – it needs TPM 2.0, UEFI with Secure Boot disabled, and PowerShell 7
• Run that script on a dedicated test machine, never a shared one: it enables test signing, disables automatic updates, and reboots without asking

Office & SharePoint

July’s Office wave is security-only; everything landed on 14 July, and nothing critical or non-security shipped in the 7 July preview. It’s an MSI-only cycle, so Click-to-Run estates can sit this one out.

• On MSI Office 2016, apply the client updates – Excel (KB5002886), Word (KB5002890), PowerPoint (KB5002867), and five further Office 2016 security updates (KB5002273, KB5002887, KB5002748, KB5002857, KB5002830) – then exercise macros, external data, embedded objects, and any line-of-business add-ins
• On SharePoint Server, patch 2016 (KB5002891, plus the KB5002892 language pack) and Subscription Edition (KB5002882), then check browser-based editing; the guidance lists SharePoint 2019 with a baseline but ships no 2019 package, so there is nothing to install there

Mind the rollback rules before you schedule the window: most client updates can be uninstalled, but the server updates cannot and always require a reboot.

Developer tools & databases

The developer estate gets a broad but low-drama sweep this month. Both .NET and SQL Server patch widely, but the ask is representative-application validation rather than anything exotic – install on the matching branch and confirm normal behaviour.

• .NET: install the SDK updates (8.0.423, 9.0.316, 10.0.302, x64 and x86) and the Framework rollups spanning 3.5 through 4.8.1 – which reach from Windows Server 2012 up to Windows 11 26H1 and Server 2025 – then run a representative set of applications and confirm they function normally
• SQL Server: the GDR updates span 2016 SP3 through 2025 – install each on its matching branch and test that each removes cleanly
• Check an encrypted client connection through the separately patched Windows SQL client (dbnetlib.dll), which ships outside the server branches

The Readiness team recommends the following priorities for your larger enterprise deployments:

• Start with printing and graphics: half the high-risk flags sit in the Print Spooler, win32k, and GDI+, so regress shared printers, 32-bit printing, PDF export, metafiles, and window management before anything else
• Take NTFS next – extended attributes and crash recovery both touch data integrity – and add a client File History backup-and-restore pass
• Give Server 2025 its wider matrix – the Secure Boot/BitLocker combinations, WSL, GPU partitioning, and the scripted backup pass – and work through the stress suites
• Run the scripted KeyGuard validation on any VBS estate, preferably on a dedicated machine.

Each month, we break down the update cycle into product families (as defined by Microsoft) with the following basic groupings:

• Browsers (Microsoft IE and Edge)
• Microsoft Windows (both desktop and server)
• Microsoft Office
• Microsoft Exchange and SQL Server
• Microsoft Developer Tools (Visual Studio and .NET)
• Adobe (if you get this far)

Browsers

Edge has had a busier month than usual. Microsoft addressed 46 Microsoft Edge (Chromium-based) CVEs this cycle. None critical, but heavily weighted to remote code execution (21 entries) and spoofing (13), led by CVE-2026-58289, a remote code execution flaw. A run of further RCEs (CVE-2026-57981, CVE-2026-56645, CVE-2026-57974) follows.

• Microsoft Edge – the Edge-specific fixes ship in the Edge stable channel (version 150.0.4078.65, released 9 July). The concentration of RCE and spoofing this month is worth a look for managed Edge estates rather than a routine wave-through.
• Chromium upstream – 427 CVEs relayed through MSRC this cycle, spanning the weekly Chrome release cadence since the June report: use-after-free, out-of-bounds read/write, type confusion, and inappropriate-implementation flaws across V8, Dawn, ANGLE, Skia, and Tint. The same fixes ship in the Chrome Stable channel; see the Chrome releases blog for the upstream notes.

The Chromium volume looks (quite) alarming but is routine plumbing: it flows to Edge through its own auto-update channel. Add these browser (Edge) updates to your standard release schedule for your managed environments.

Microsoft Windows

Windows carries the bulk of this month’s updates: 406 CVEs, 31 rated critical and 374 important. Elevation of privilege dominates by volume (226 entries), followed by remote code execution (70), information disclosure (70), denial of service (23), and a scatter of security-feature-bypass, tampering, and spoofing entries across the following feature groupings:

• DHCP – the standout network cluster: DHCP Server remote code execution (CVE-2026-50518, “Exploitation More Likely,” and CVE-2026-56159), with further critical DHCP Server and DHCP Client RCEs behind them (CVE-2026-48564, CVE-2026-50370, CVE-2026-54128). DHCP servers are the deployment priority.
• VMSwitch and Hyper-V – the Windows VMSwitch elevation of privilege (CVE-2026-57092) is one of the month’s highest-severity flaws, joined by two critical Hyper-V elevation-of-privilege entries (CVE-2026-50680, CVE-2026-54127), guest-to-host risk on virtualisation hosts.
• Network stack RCE – a Windows Server Network driver RCE (CVE-2026-56188, “Exploitation More Likely”), plus TCP/IP (CVE-2026-54999), the Reliable Multicast Transport Driver (CVE-2026-54982), and SSTP (CVE-2026-50694).
• Graphics – Windows GDI+ remote code execution (CVE-2026-50380) and a DirectX Graphics Kernel RCE (CVE-2026-50382), both reachable through document-rendering paths.
• Windows Media – a large cluster: three critical Media Foundation RCEs (CVE-2026-57090, CVE-2026-57094, CVE-2026-57087) lead 14 Windows Media and seven Media Foundation entries overall.
• Identity infrastructure – beyond the exploited ADFS flaw, Active Directory Domain Services takes a critical RCE (CVE-2026-49164) and Active Directory Certificate Services a critical elevation of privilege (CVE-2026-54121). Domain controllers take priority again.
• Print Spooler, WSUS, and MSMQ – critical RCE/EoP in the Print Spooler (CVE-2026-58608), Windows Server Update Services (CVE-2026-50444), and Message Queuing (CVE-2026-54992, “Exploitation More Likely”), all server-role attack surface.

The Windows Kernel is the most-patched component (28 CVEs, seven “More Likely”), followed by NTFS (21), Windows Runtime (17), Windows Media (14), ReFS (12), and Win32k (15 across its two entries). Add this Windows update to your Patch Now deployment schedule.

Microsoft Office

Microsoft released 96 Office CVEs this month: 19 critical, 76 important. Remote code execution leads (53 entries), ahead of information disclosure (27) and spoofing (10). SharePoint is the centre of gravity: it touches 39 of the 96 CVEs and supplies the family’s one actively exploited flaw.

• SharePoint Server: has been exploited (who would have guessed) and reaches end of support today. CVE-2026-56164, an elevation of privilege, is under active exploitation. Above it sit two critical remote code execution flaws, both “Exploitation More Likely” (CVE-2026-50522, CVE-2026-58644) and a critical security feature bypass (CVE-2026-55040). SharePoint Server 2016 and 2019 reach end of support on 14 July, so this exploited, critical-heavy set is the final security update those on-premises farms will receive.
• Office has experienced a long run of critical remote code execution entries across Office, Word, and PowerPoint (among them CVE-2026-55033 and CVE-2026-55127 in Word, CVE-2026-55043 in PowerPoint, and CVE-2026-55018 in Office), topped by CVE-2026-55045.

With an exploited zero-day, two RCEs, and an end-of-support deadline all landing on SharePoint in the same cycle, SharePoint environments are the priority. Add the July Office and SharePoint updates to your Patch Now schedule.

Microsoft Exchange and SQL Server

Both Exchange and SQL Server carry critical-rated security vulnerabilities this month. Exchange Server returns with an on-premises security update for Exchange Server Subscription Edition, the only on-premises release still supported after Exchange Server 2016 and 2019 reached end of support in October 2025; SQL Server takes two critical remote code execution flaws, one of them against SQL Server 2016, which reaches end of support on the same day.

• Exchange Server (on-premises) – CVE-2026-55008, a spoofing vulnerability rated critical and “Exploitation More Likely,” is the headline. Behind it, a remote code execution entry (CVE-2026-55005) and two elevation-of-privilege flaws (CVE-2026-55006, CVE-2026-55009) round out the on-premises set. A separate Exchange Online elevation of privilege (CVE-2026-54998, critical) is fixed service-side with no customer action.
• SQL Server – two critical remote code execution flaws: CVE-2026-54117 (SQL Server 2025) and CVE-2026-54118 (which reaches back to SQL Server 2016 SP3), with five further important elevation-of-privilege and information-disclosure entries behind them. The 2016 exposure matters because SQL Server 2016 reaches end of support on 14 July: a critical RCE on a platform taking its final update.

Both belong on the Patch Now schedule this month: the Exchange on-premises update for its critical spoofing flaw, and the SQL Server update for the two critical RCEs.

Microsoft developer tools

Microsoft released 24 CVEs across its developer tooling this month, all rated important. The weighting shifts from last month’s Visual Studio Code concentration toward .NET and ASP.NET Core, where a run of denial-of-service entries dominates the volume:

• ASP.NET Core and .NET – the two highest-severity entries are ASP.NET Core elevation-of-privilege entries (CVE-2026-47300, CVE-2026-47303), ahead of a .NET security feature bypass (CVE-2026-50528) and two .NET / .NET Framework remote code execution flaws (CVE-2026-50646, CVE-2026-50649).
• Visual Studio and VS Code – a GitHub Copilot / Visual Studio Code security feature bypass (CVE-2026-41109) and a second VS Code security feature bypass (CVE-2026-57102) lead here, with a VS Code remote code execution entry behind them (CVE-2026-50520) and a Visual Studio RCE (CVE-2026-47305).

Add these Microsoft updates to your standard developer update release schedule.

Adobe (and third-party updates)

Outside Microsoft’s own catalogue, July is quiet. Adobe issued no Acrobat or Reader security updates. So, the month belongs to Microsoft, and it is a heavy one: 722 CVEs, roughly three times a normal cycle and one of the largest on record. Worth noting that this lands in the same season Microsoft has been talking up AI-assisted vulnerability management, and the AI stack it is selling as the answer, Copilot and Azure OpenAI among them, sits in the centre of this patch cycle’s own critical-rated updates. The (AI) tooling may be getting smarter, but the patch pile is (definitely) not getting smaller. This may be the beginning of an accelerating curve of ever larger patch cycles. My feeling is that we are in the middle of the beginning of this coming patch surge.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

In many teams, dependency security still happens after the most important trust decision has already been made. A package is added, the lockfile changes, the feature moves forward, and only later does the pipeline ask whether the application should have trusted that code in the first place.

That workflow made sense when dependency security was mostly viewed as a compliance check. Run a scanner. Produce a report. Fail the build if the risk crosses a threshold. Let someone decide what to do next.

But the modern Node.js ecosystem has changed. The risk no longer begins in CI. It begins earlier, at the moment a developer decides to trust a package.

That is why the next phase of Node.js security cannot be limited to better pipeline enforcement. It has to move closer to the developer workflow, before dependencies become part of the application, before a pull request becomes someone else’s problem, and before a build log becomes the first moment anyone realizes that something important has changed.

Every install is a trust decision

The npm ecosystem is built on trust at an enormous scale. Every install is a trust decision. Every transitive dependency extends that decision to maintainers, packages, scripts, release pipelines, and infrastructure the application team may never inspect directly. This model gave JavaScript its incredible velocity. It also created one of its deepest security weaknesses.

Recent npm supply chain incidents show why this matters. In March 2026, malicious Axios versions were published to npm through a compromised maintainer account. Microsoft later described how those packages attempted to retrieve a second-stage payload during installation. In May 2026, TanStack published a postmortem explaining that 84 malicious versions across 42 npm packages were published through a legitimate release pipeline after an attacker abused GitHub Actions behavior and runner trust boundaries. Security researchers also reported broader Mini Shai-Hulud activity across the npm ecosystem in May, including hundreds of malicious package versions published in a short period.

Not every one of these incidents is a traditional CVE. Some are malicious package compromises. Some involve CI/CD credential theft. Some involve maintainer or pipeline compromise. But they all point to the same larger issue: dependency risk is now part of everyday software engineering, not something that can be pushed entirely to a downstream security process.

The problem is not the scanner. It is the handoff.

Ubiquitous dependency risk changes what developers need from security tooling.

The problem is not that teams lack scanners. Many organizations already run security checks in CI. The problem is that the output of those checks often arrives too late and speaks the wrong language for the person expected to act on it.

A pull request fails. A long vulnerability report appears. The report may be technically accurate. It may contain the right advisory IDs, affected versions, dependency paths, severity labels, and references. But the developer still has to comb through the output and reconstruct the actual engineering decision from the evidence provided.

That reconstruction is rarely simple. The developer has to understand which package introduced the issue, whether the vulnerable dependency is direct or transitive, whether the fix is actually within the application team’s control, and whether the recommended version is safe to adopt. They also have to determine whether the dependency is used in production or only during development, whether the update might break the application, and whether the fix belongs in the current pull request or requires separate engineering work.

That uncertainty is where security work often slows. The scanner has detected risk, but the developer has not been given a clear path from detection to decision.

Security needs to move closer to engineering judgment

This is not a criticism of scanning. Scanning is necessary. CI enforcement is necessary. Centralized security platforms are necessary. But they are not sufficient, because they often operate after the trust decision has already been made.

The real architectural question is this: where should dependency security live in the software development life cycle?

If it lives only in CI, it becomes an interruption. If it lives only in dashboards, it becomes someone else’s queue. If it lives only in periodic audits, it becomes a backlog. But if it lives at the moment a dependency is introduced, upgraded, or reviewed, it becomes part of engineering judgment.

That shift matters because modern JavaScript development is becoming faster than human review can comfortably handle. Developers no longer add dependencies only by reading documentation and choosing libraries manually. AI coding assistants can suggest packages, generate install commands, modify package files, and rewrite code around third-party APIs. Agentic development workflows can make dependency changes as part of broader automated refactors.

AI makes the trust boundary harder to see

That acceleration is useful. It also changes the risk model.

When a human developer adds one package, the team can review the decision. When a coding agent modifies several dependencies as part of a larger task, the trust boundary becomes harder to see. The package file changes, the lockfile changes, the application still runs, and the pull request may look like a normal feature update. But the real security question may be hidden inside the dependency graph.

This is where Node.js teams need a different mental model.

Dependency adoption should not be treated as a small implementation detail. It should be treated as an architectural decision with security consequences. A new package is not just code reuse. It is a new trust relationship.

That does not mean developers should stop using packages. The npm ecosystem exists because reuse works. Most teams cannot and should not build everything themselves. But convenience should not erase visibility. If a dependency becomes part of the application, the team should understand what was added, what changed in the lockfile, what risk comes with it, and what action is available if something is wrong.

Developers need confidence, not just reports

The same applies to remediation. Developers do not want a wall of vulnerability text. They want confidence. They want to know what action reduces risk, what version should be targeted, whether the change is safe, and whether the fix is actually under their control. A vulnerability report that leaves the developer uncertain may satisfy a process requirement, but it does not necessarily improve the speed or quality of remediation.

That is the gap many teams feel today. Security tools are often very good at saying, “There is a problem.” They are less consistent at helping the developer answer, “What should I do next?”

This is the broader problem I have been exploring through CVE Lite CLI, now an OWASP project. The point is not that one command-line tool solves Node.js security. It does not. The larger idea is that dependency security has to move closer to the developer’s moment of decision. A useful developer-side security workflow should not merely report that risk exists. It should help the engineer understand whether the issue is in their control, what change is available, and whether the fix actually reduces risk.

The future is decision support, not just detection

That distinction is important. The future of Node.js security is not just more detection. It is better decision support.

Security teams still need policy. Enterprises still need dashboards. CI still needs gates. But developers need something more immediate: a way to reason about dependency risk while the code is still fresh in their mind. That is where the ecosystem has to evolve.

We already accept that testing belongs close to development. We accept that linting belongs close to development. We accept that formatting, type checking, and build validation belong close to development. Dependency security should follow the same path. It should not be treated as a mysterious report that appears at the end of the process. It should become part of the normal rhythm of engineering work.

Before adding a package, developers should understand what trust relationship is being introduced. Before accepting an AI-generated dependency change, they should inspect what entered the graph. Before merging a pull request, teams should understand whether a vulnerability is direct, transitive, fixable, or blocked by another package. And before treating a CI failure as noise, organizations should ask whether the workflow is giving developers enough information to act confidently.

Node.js security will be won, or lost, before CI runs

The Node.js ecosystem will not become safer by slowing down all development. That is unrealistic. It will become safer when security work is placed where developers can actually use it.

The next generation of Node.js security will be won or lost before CI runs.

It will be won when dependency decisions are still small enough to understand, fresh enough to review, and close enough to the developer for action to feel natural.

That is the shift teams need to make now. Not from insecure to secure in one step, but from late detection to earlier judgment. From vulnerability reports to engineering decisions. From trusting packages by habit to understanding trust as part of software design.

A year ago, most enterprise AI systems generated recommendations. Today, AI systems are approving transactions, routing shipments, updating records, interacting with customers, and triggering downstream software actions with little or no human involvement.

For CIOs, that shift changes the central governance question. The challenge is no longer simply whether an AI model is accurate. It is whether the organization can explain, audit, and defend the decisions the system makes.

When an AI assistant suggests a meeting time or summarizes a document, mistakes are inconvenient. When an autonomous AI system issues a refund, reprices a product, modifies a customer record, or initiates a financial transaction, mistakes carry operational, legal, and reputational consequences.

When those consequences arrive, “the model decided” is not an acceptable explanation.

This is the accountability gap emerging at the center of enterprise AI adoption. Organizations are deploying increasingly autonomous systems while relying on technology that often provides little visibility into how decisions are made. The result is a growing mismatch between the level of authority organizations grant AI and their ability to understand or justify its actions.

Black-box AI may have been acceptable when AI primarily generated predictions. It becomes far more problematic when AI begins taking actions on behalf of the business.

The lesson software already learned

Fortunately, the technology industry has faced a similar challenge before.

As enterprise software systems became more distributed and complex, troubleshooting failures became increasingly difficult. Engineers could no longer rely on intuition to understand what happened when something broke. The solution was observability: the practice of instrumenting systems so their internal state could be understood through logs, metrics, traces, and monitoring.

The goal was not to predict every possible failure in advance. It was to create enough visibility that teams could reconstruct what happened after the fact and identify the root cause.

Enterprise AI now requires a similar discipline.

But AI observability must go beyond traditional software observability. It is not enough to know what action occurred. Organizations also need visibility into why the system believed that action was appropriate.

An auditable AI system should be able to answer questions such as:

• What information did the system rely on?
• Which tools or data sources did it access?
• What alternatives did it consider?
• What verification steps were performed?
• How confident was it in its conclusion?
• What events led to the final action?

These questions are rapidly becoming essential operational requirements rather than technical nice-to-haves.

Why visibility matters more as AI gains autonomy

As AI systems become more autonomous, failures become harder to detect and diagnose.

A human reviewing a single AI-generated recommendation can often spot obvious mistakes. A network of AI agents coordinating multiple tasks across business processes presents a different challenge. Decisions can build upon one another. A flawed assumption early in a workflow can propagate through subsequent actions, creating confident but incorrect outcomes.

The challenge is rarely identifying that something went wrong. Eventually, an error surfaces through a customer complaint, a failed transaction, an audit finding, or an operational disruption.

The challenge is determining why it happened.

Which information influenced the decision? Which tools were consulted? Which safeguards worked as intended? Which ones failed?

Without visibility into the reasoning process, troubleshooting autonomous AI workflows can become significantly more difficult than debugging traditional software systems.

For CIOs responsible for enterprise reliability, compliance, and governance, that lack of visibility creates unacceptable operational risk.

Moving toward glass-box AI

The answer is not to slow AI adoption. The answer is to make AI systems observable.

Increasingly, organizations are seeking AI systems that behave more like a glass box than a black box. The objective is not to expose every parameter inside a neural network. Rather, it is to provide a clear, auditable record of how decisions were reached and why actions were taken.

The most promising approaches share two common characteristics.

The first is verification. Instead of treating a single model’s output as ground truth, systems incorporate independent validation steps before actions are executed. Multiple agents, external checks, business rules, or verification workflows help identify errors before they become operational incidents.

The second is explainability. Effective systems maintain a decision trail that captures inputs, intermediate reasoning steps, tool usage, verification activities, and outputs in a form that human reviewers can understand.

Together, these capabilities create something that has long been expected of human decision-makers but is often missing from AI systems: the ability to show your work.

The regulatory and business reality

The push toward AI observability is not being driven solely by technologists.

Regulators increasingly expect organizations to demonstrate oversight of automated decision-making systems. Emerging AI governance frameworks place growing emphasis on transparency, traceability, accountability, and human oversight.

Customers are moving in the same direction. Whether the decision involves pricing, service, eligibility, or support, people increasingly want the ability to understand and challenge outcomes that affect them.

The result is a convergence of operational, regulatory, and market pressures around a single requirement: organizations must be able to explain what their AI systems are doing.

Three questions every CIO should ask

Before deploying autonomous AI systems, technology leaders should be able to answer three basic questions:

1. Can we reconstruct the complete decision path that led to an action?
2. Can we verify critical outputs before actions are executed?
3. Can a human auditor understand why the decision occurred?

If the answer to any of those questions is no, the organization may be granting more authority to AI than it can responsibly govern.

Accountability will become a competitive advantage

The organizations that succeed with autonomous AI will not necessarily be those that automate the most processes or deploy the largest models. They will be the organizations that combine automation with accountability.

Black-box systems made sense when AI primarily generated predictions. As AI increasingly acts on behalf of businesses, customers, and employees, visibility becomes essential.

The future of enterprise AI will belong not to systems that merely act, but to systems whose actions can be examined, understood, and trusted.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

We’re seeing an interesting infrastructure tug of war today where GPU clouds are being pulled in two directions. For the economics of AI to work, the enterprise market needs to carve expensive hardware into smaller, shareable units and hand it to customers on demand, similar to how CPUs are doled in public cloud infrastructure. But the more the providers push GPUs to behave like elastic cloud infrastructure, the more they run into the reality that this GPU hardware was never built for safe multitenant use, fast fault recovery, or clean isolation between workloads. That tension is becoming one of the defining operational problems of the AI infrastructure market.

When a gamer launches Steam or the Epic Games Store on their laptop, they don’t have to worry about which GPU is being scheduled, how memory is going to be divided, or really any of the security boundaries or hardware assignment issues on their PC. For consumer PCs, these issues are not just hidden from view, they are irrelevant.

But for today’s IT teams managing GPU-driven AI workloads across distributed systems, those types of allocations and partitions need to be managed manually and carefully. This includes deciding which GPU to assign to each workload, how to divide memory, how to isolate tasks, and how to maximize utilization of this very expensive hardware. That’s why you heard so much about “Day 2” AI infrastructure themes around Nvidia’s GTC event this year.

The legacy hardware bottleneck

GPUs were originally developed to speed up graphic rendering and to perform local compute via shaders in service of graphical rendering. Their design assumes a trusted computing environment in which a single application controls the device. When a user runs an application on a GPU, it accelerates that particular workload.

But while GPUs are optimized for throughput, and therefore have thousands of simple cores designed to execute the same instruction over large datasets, this design paradigm creates several major technical limitations regarding context switching and memory isolation. GPUs were designed to produce pixels, not to run sensitive AI applications from multiple tenants using the same hardware.

As a result, GPU infrastructure today behaves less like elastic cloud infrastructure and more like carefully managed hardware appliances.

The partitioning paradox

Today’s AI infrastructure requires GPUs to behave like shared, elastic cloud resources. As inference workloads begin to outstrip large-scale training runs, the ability to slice and share expensive hardware among multiple tenants in real time while maintaining acceptable fault tolerance is no longer optional.

Hardware vendors have introduced new approaches to dividing GPUs into multiple isolated compute slices. Other frameworks approach partitioning through schedulers and container runtimes. But resource partitioning is just one slice of the overall GPU operations pie.

There is currently no widely adopted, cross-vendor operating model for achieving this safely at scale. Most providers are faced with either dedicating a single customer to a physical machine (thus wasting available capacity), or accepting the multi-tenancy security risks currently without a known solution. The current engineering challenge has moved from beneath the model layer and into the infrastructure layer. Success now relies on the ability to quickly launch new workloads and to rapidly contain hardware faults so that a single GPU failure does not bring down all workloads running on the server.

Untrusted code and tenants

The vast majority of current GPU programming models rely on the idea that the driver has complete control over memory protection and that no user will act maliciously. Unfortunately, that assumption completely falls apart in a cloud environment where one VM or container can leave behind data remnants in memory that another VM or container may access. Especially considering that how GPUs execute code is often completely opaque.

A single faulty workload or a single faulty driver failure in a shared GPU environment can also take down every workload (job) that was being run on the same server, increasing the amount of damage caused by an operational failure.

Currently, there are immature options for runtime inspection or behavioral auditing, limiting both visibility and control for security teams. GPU drivers provide a large attack surface and generally limited telemetry from the hardware. In these shared environments, embeddings, weights, prompts, and tokens are now all sensitive data points, creating significant blind spots for those attempting to protect intellectual property.

The high cost of cold starts

The real constraint in many GPU clouds is not model performance but operational efficiency. Right now GPU operations looks like 30 minute tenant spin-up times, 70% idle rates, and engineers continuously debugging infrastructure stacks. Today’s GPU clouds are stalled not due to inferior models, but because the infrastructure layer underpinning these clouds was never designed to support such a high degree of scale.

A 30 minute cold start is a fundamental limitation on the modern AI business model. Those GPU clouds that can spin up workloads in seconds will ultimately win against those that do not. Multitenancy is the only viable means of producing sufficient unit economics to make this very expensive hardware viable for the long term.

Bridging the orchestration gap

Platform teams are beginning to recognize that GPUs require a specialized operating layer between the hardware and workloads. Operators need a unified operating model that supports multiple hardware vendors and GPU models. Cloud providers need a method to safely slice and share servers among tenants, and to prevent cascading failures, while rapidly launching new workloads.

Enterprises are increasingly seeking to run sensitive AI applications with stronger isolation guarantees, and thus are turning to newer categories of software designed specifically to manage the “dirty work” of hardware orchestration.

The race to make GPUs more operational

Prior to Kubernetes standardizing container orchestration, the industry was constantly debating the efficiency of container scheduling and bin packing across clusters. Those operational concerns were eventually automated and incorporated into infrastructure layers that made the complexities invisible to the end user. 

A similar evolution is occurring around GPUs today. While platform teams continue to argue over placement strategies and memory tuning, these decisions will likely be automated within five to 10 years. As AI infrastructure evolves, the most valuable layer may not be the GPUs themselves but the operating layers that make them secure, elastic, and efficiently sharable. So the winners in the AI race won’t necessarily be just those with the most silicon, but those who have the best operating models for making that silicon secure and elastic.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Broadcom today announced multiple security investments in its Spring and Java ecosystems that aim to help protect users from AI-enabled threats.

The company said that, first, it is releasing what it called the largest set of Spring security updates to open source in the product’s history, and, for customers, it is extending its clean-room build architecture to build the Java dependencies for the entire Spring ecosystem.

“Spring is one of the most widely adopted application development frameworks in the world, and as its steward, we have a deep responsibility for its security,” said Purnima Padmanabhan, vice president and general manager of Broadcom’s Tanzu Division. “Because we maintain Spring and are the sole committers, we can better secure it at the source for everyone who depends on it. This investment is about two things we will never separate: the health of the Spring community and the security of our customers who trust Spring to run their business.”

The company also announced that, as the number of security advisories reported by the community has exploded, its engineering team has “significantly scaled” its use of AI tools to help it identify vulnerabilities, assess remediation paths, and validate fixes across the dependency ecosystem. Although Broadcom declined to specify the AI models it’s using in its bug hunting, it is a member of Anthropic’s Project Glasswing, so Claude Mythos is likely part of the effort.

For paying customers only

One perk available only to Tanzu Spring enterprise customers is zero-day access to validated CVE patch-only releases through the Spring Enterprise Repository, before they are released to open source. These patches isolate the security fix from any other changes to let customers remediate more quickly.

“By utilizing Tanzu Spring’s private artifact repositories, customers can be confident that the artifacts are the official, validated patches from Broadcom, the steward of Spring,” Broadcom said in its announcement, adding that it will continue to issue CVEs for all versions of every Spring project under open source support, as well as older versions under Tanzu Spring enterprise support.

Broadcom’s Tanzu Spring enterprise support includes:

• Certified source for secure spring libraries 
• Commercial-first release of patches for both current and older, enterprise supported versions
• Access to dependent Java binaries
• Automated, deterministic upgrades with Spring Application Advisor
• Exclusive Tanzu Spring components for governance and security
• 24×7 support, hands-on expertise and access to the Spring team.

In addition, Broadcom said, it has now added:

• Secured, SLSA Level 3–validated software supply chain for Java dependencies.
• Coverage that spans the full transitive dependency graph managed by the Spring Boot bill of materials.
• Thousands of secured dependencies, built and tested across every supported Spring version. Spring Boot 4.0 alone manages 1,768 of them; across the full supported portfolio, that totals more than 100,000 validated dependency builds.

“This capability gives customers validated dependencies across both current and end-of-life Spring versions, helping customers reduce software supply chain risk while continuing to benefit from the productivity and consistency of Spring Boot’s dependency management model,” the announcement noted.

Security fixes for sale

Seva Ioussoufovitch, senior research analyst at Info-Tech Research Group, sees these moves as mostly positive.

“It’s encouraging to see Broadcom take proactive steps towards dealing with the increase in AI-detected vulnerabilities that many organizations have had to contend with in recent months,” he said. “Announcements like Mythos have made it clear that the industry needs to re-think traditional approaches to security patching.”

Ioussoufovitch isn’t surprised at the size of the update release either, noting that it’s consistent with the result of AI scanning and remediation that has been occurring, and will likely continue.

“More meaningful is the provision of validated and secured dependencies,” he said. “This is a critical move in the right direction, especially with the endlessly growing list of supply chain vulnerabilities the industry has been managing in recent months.”

Ioussoufovitch is less happy with the restriction of zero-day patches to paying customers.

“Putting security fixes behind a paywall isn’t new, but when there are no drop-in alternatives for an ecosystem as critical as Spring, it just looks like a power move to force more of the open-source community onto the monetization track,” he noted. “Another approach might’ve been to release the CVE fixes to everyone while charging for enterprise-grade packaging, validation, and support, but, given Broadcom’s track record of aggressive monetization in recent years, what they’ve chosen here doesn’t necessarily come as a shock.”

In the ever-evolving cybersecurity landscape, Microsoft has introduced various new features in Windows 11 designed to protect users from modern workplace threats. Among such features, Smart App Control (SAC) changes how Windows devices handle, and occasionally block, unwanted or potentially malicious applications.

But what exactly is Smart App Control? How does it work, who benefits most, and are there any caveats? In this story we’ll share some history and explain why SAC has been something of a stealth feature in Windows 11.

What is Smart App Control?

Smart App Control is a security feature in Windows 11 designed to block untrusted or potentially dangerous applications from running on a PC. Built directly into the operating system (through Windows Security), SAC leverages code signing, Microsoft’s intelligence cloud, and artificial intelligence to make real-time decisions about whether an app or application should be allowed to run. Its goal is to minimize the risk that malware, ransomware, and unwanted software could run on users’ systems — with minimal user intervention.

At its heart, Smart App Control is a kind of gatekeeper. When you attempt to run an app, SAC evaluates its trustworthiness. That evaluation is based on numerous criteria: Is the app digitally signed? Is it widely used and recognized as safe by Microsoft’s threat intelligence network? Has it been flagged previously for questionable behavior?

If an app fails one or more such checks and is found suspicious or untrustworthy, SAC blocks its execution, silently preventing a potential security event before it starts.

How does Smart App Control work?

SAC operates using a combination of cloud-based intelligence, local analysis, and digital signatures. Here’s a step-by-step breakdown of how it functions:

• App verification: When a user attempts to launch an application, SAC inspects the file. It first checks if the app is digitally signed by a trusted publisher, an important indicator of legitimacy.
• Cloud intelligence search: SAC then consults Microsoft’s extensive security databases in the cloud. These aggregate threat data from millions of Windows devices worldwide. If the app has been flagged already or is recognized as part of any malware campaign, it is blocked.
• AI-based analysis: For less clear-cut instances, SAC uses AI to evaluate an app’s behavior. That is, it looks for telltale signs of malware or unwanted code. Such a dynamic analysis helps catch emerging threats not yet known to the cloud.

When an app is blocked, the user gets a clear, informative notification. Usually, there’s no way to override SAC’s decision, which puts security ahead of convenience. It also ensures that users will quickly report false positives.

Smart App Control is designed to be simple and automatic. Unlike conventional antivirus or endpoint security, it requires no updates to definitions, nor manual scans. SAC works behind the scenes to block threats in real time. Because it uses both local and cloud-based intelligence, it’s always current.

On the downside, some legitimate apps, especially older or custom business software, may not be digitally signed, resulting in false positives. If SAC decides an app is unsafe, the only way to run the app is to turn SAC off.

Working with Smart App Control

Notably, Smart App Control is enabled by default — but only on “clean installs” of Windows 11 version 22H2 or later. Systems upgraded from older versions of Windows 11 will always show SAC in the “Off” state.

Microsoft made this decision to avoid potential compatibility issues with legacy or line-of-business applications. That means users can’t benefit from SAC unless they have a newer PC or somebody reinstalls Windows 11 from scratch on an older one. (See my Windows clean install tutorial for complete instructions.)

SAC prerequisites

To get granular: SAC requires that the following be present as Windows 11 comes up for the first time:

• Secure Boot, a security feature that allows only trusted, digitally signed software to run as Windows boots up
• A working chain of trust, including current CA-2023 boot certificates in Unified Extensible Firmware Interface (UEFI) and a CA-2023 compliant bootloader

Newer PCs — namely, those built in 2018 or later, with Windows 10 or 11 installed prior to delivery — routinely include UEFI-only boot and support Secure Boot from the get-go. Indeed, Secure Boot was introduced with Windows 8, and the original certificates came along in 2011 (Production PCA 2011, UEFI CA 2011, and KEK CA 2011). They’ve been shipped in firmware ever since.

As long as such machines get updated through Windows Update (or some managed equivalent, such as Microsoft Intune, Windows Autopilot, or Microsoft Configuration Manager), the new certificates and a proper chain of trust should be established on those PCs. (See FAQ: What you need to know about expiring Windows Secure Boot certificates for more information.) All this said, only Windows 11 imposes a working Secure Boot environment as a hard and fast system requirement as of 2021.

In short, Secure Boot and the chain of trust provide the essential foundation for SAC to start with a clean bill of health, security wise, and keep things that way. To learn more about Secure Boot and its various certificates and trappings, consult the Secure Boot and Windows Secure Boot Key Creation and Management Guidance pages on Microsoft Learn.

Modes of operation

SAC has three distinct modes:

• On: SAC actively monitors and blocks untrusted apps.
• Evaluation: SAC quietly observes your usage patterns and system needs before fully activating.
• Off: SAC is disabled and will not intervene.

SAC will normally start in Evaluation mode for up to a month, then turn itself On or Off depending on observed system behavior. Once turned on, SAC cannot be set back into Evaluation mode. Organizations or users who run custom software or specialized workflows should leave SAC in Evaluation mode to ensure that business functions keep working.

To check SAC’s status:

1. Open the Windows Security app.
2. Navigate to App & browser control.
3. Look for the “Smart App Control” section. You’ll see the current status: On, Off, or Evaluation mode, as shown in Figure 1.

Until recently, SAC could not be toggled off and on again — once it was turned off, you had to reinstall or reset Windows 11 to re-enable it. But with the April 2026 Patch Tuesday release of Windows 11 (KB5083769), admins and elevated users can turn SAC on or off as they see fit, as long as the initial setup conditions described above are met.

This toggling capability is a step forward for usability and safety, because it lets users with administrative privileges temporarily disable SAC in order to install, update, or uninstall certain unsigned apps, such as those that rely on Windows Installer Transform (MST) files, and then turn SAC back on immediately.

Note that this feature is being gradually rolled out, so you may not have access to it yet.

Smart App Control compared to other Windows 11 protections

Microsoft has long offered security features like Windows Defender, Controlled Folder Access, and Application Control. SAC differs in its general, automated approach. Rather than relying on static definitions, group policies, or user input, SAC leverages real-time intelligence and AI.

In many ways, SAC takes the best bits of Application Control (previously available through Device Guard and Windows Defender Application Control) and makes them accessible to a wider audience. It also involves little or no manual setup and few, if any, policy issues. Then again, as covered earlier in the story, SAC also functions as a black box: one either lives with its judgments, or does without it.

Real-world impact and industry reception

Feedback from the IT community has been mostly positive. Security researchers note SAC’s ability to block emerging threats before traditional antivirus solutions can respond. But SAC is hardly bullet-proof: a number of studies cite focused exploits or workarounds to bypass or trick SAC. For instance, Elastic Security Labs documented multiple techniques to break SAC in 2021, with follow-ons from Hacker News and TechRadar.

As always, a proactive approach to cybersecurity that includes teaching users to avoid trouble remains a key ingredient in establishing and maintaining a strong security posture.

For end users, SAC’s presence may go largely unnoticed — until, that is, it intercepts a malicious download or prevents installation of a suspicious or malicious program. Or, as the case may sometimes be, when users try to run old, unsigned software that SAC won’t allow.

Tips for IT administrators

For IT professionals considering deploying devices with SAC, certain best practices are worth implementing:

• Test SAC in Evaluation mode before rolling out widely, especially if your organization relies on custom or legacy software, or if anything important is unsigned.
• Educate users about SAC’s presence and purpose so they understand why certain apps may be blocked. Set up a procedure to request support and/or fixes, particularly if important software gets blocked. Possible workarounds include restricted VMs with SAC turned off to run unsigned applications.
• Maintain an up-to-date inventory of critical applications and ensure as many as possible are digitally signed by trusted publishers.
• Monitor Microsoft resources Learn, Support, and Answers forums for SAC updates, compatibility lists, and troubleshooting tips.

The future of Smart App Control

As threats continue to evolve, Microsoft should continue to expand SAC’s capabilities. Undoubtedly it will use more advanced AI models and deeper integration with Windows Defender and Microsoft 365 security. Future updates may introduce more granular controls for enterprise environments, including managed exceptions and better reporting tools.

For now, SAC represents a useful additional tool for Windows security. It’s intended to shift the balance in favor of the good guys in the ongoing war against malware. So far, it’s been a modest step forward. But it’s not unthinkable that SAC could offer more and better protection in upcoming Windows releases.

[Also see: FAQ: What you need to know about expiring Windows Secure Boot certificates]

This article was originally published in September 2025 and updated in June 2026.