GitLab on Wednesday published updated versions of its Community Edition (CE) and Enterprise Edition (EE) that address a dozen bugs and security issues, including some that allow various unauthenticated actions. 

The most serious of the security issues, labeled critical in severity, is CVE-2026-110264, an integer overflow issue. “GitLab has remediated an issue that, under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to integer overflow when compiling a specially crafted regular expression,” GitLab said in its bulletin. “In addition to our standard patch releases, we have backported this fix to GitLab CE/EE versions 18.11.13, 19.0.10, 19.1.9, and 19.2.9.”

Impacted versions of GitLab CE/EE include all versions from 7.0 before 18.11.13, 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1.

The patched releases are versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. 

The patches also fix a high severity flaw tracked as CVE-2026-15723, an improper authentication issue in OmniAuth-to-LDAP auto-linking email lookup that impacts GitLab CE/EE, which is an issue, GitLab said, because “when OmniAuth SAML and LDAP auto-linking were both enabled, an authenticated user could have taken over an existing LDAP-backed account without any interaction from the targeted user, due to improper input sanitization in the LDAP email lookup path used during OmniAuth identity linking.”

This is the fourth critical security issue that GitLab has experienced within two months. Earlier in October, it patched a maximum severity regex flaw, and in September, it fixed CVE-2026-85706, also rated perfect 10 in severity. Another September report also revealed a concerning issue: a long-lived token that puts CI/CD security at risk.  

Immediate action needed

Analysts and consultants agreed that the current holes are serious and merit immediate action.

“What really stands out to me is the underlying source of the vulnerability,” said Noah Kenney, principal consultant at Digital 520. “The issue originates in an integer overflow within the regular expression compiler, rather than functionality developed specifically by GitLab.”

He pointed out that this distinction is important because it highlights the risks associated with dependencies and shared software components. “Organizations can invest heavily in securing their own applications while remaining exposed to vulnerabilities introduced through underlying libraries and frameworks,” he said. “The fact that this issue potentially affects releases dating back to GitLab 7.0 demonstrates how long these vulnerabilities can persist before being identified and remediated.”

Kenney added that CISOs should pay particular attention to one brief mention within the GitLab post.

“Buried in the bug fixes, not even in the CVE list, is a line about stripping the trusted flag from client-supplied MCP tools in Workhorse,” he said. “In plain terms, GitLab found a path where an AI agent could be handed tools it should not have trusted and quietly closed it. This raises an important issue surrounding trust boundaries in AI-enabled systems.”

Frank Dickson, principal analyst at Dickson Research, noted that the holes are especially troubling because of the highly-integrated nature of GitLab systems.

“GitLab is not just a code repository. It holds the source code, the CI/CD pipelines, and very often the secrets those pipelines use to deploy to production,” he said. “Owning the GitLab server means owning the keys to the kingdom. An attacker does not need to break into production when the system that builds production will do it for them.”

Dickson also flagged the fact that these fixes may need a lot of time to deploy.

“Plan for downtime,” he said. “GitLab’s release notes say this patch includes database migrations, and single-node instances will be down while they run. Someone will ask to wait for the weekend. Waiting is a risk acceptance. That decision belongs to an executive, not to the DevOps team.”

Additional risks

In addition, he pointed out that the nature of these flaws is a strong heads-up that many other enterprise vendors might also suffer from similar issues. 

“The flaw sits in Ruby, not just in GitLab’s own code. GitLab’s release notes show the fix ships as a patch to Ruby’s regular expression handling, and one of its detections is named for Onigmo, Ruby’s regex engine,” Dickson said. “GitLab may not be the only Ruby application carrying this bug. CISOs should ask their other vendors.”

As well, Ty Coffee, principal at advisory firm UHY, noted that the LDAP bug raises the risk that a post-breach investigation could accidentally point the finger at an innocent employee. 

“If an attacker takes over an LDAP-backed account, everything they do is logged under a legitimate employee’s name, and your audit trail then points at the wrong person,” Coffee said. “CISOs should also check for shadow and legacy GitLab servers such as team-run instances, old DR copies, acquired-company servers, [because] this affects versions back to 7.0 and that means forgotten boxes are in scope.”

The AI industry has been expanding how much information an AI model can consume at once. In just a few years, context windows have grown from thousands of tokens to millions. Anthropic increased Claude’s context window from 9,000 to 100,000 tokens in May 2023, reaching 200,000 tokens by November 2023. Google’s Gemini 1.5 Pro reached one million tokens in February 2024, then two million by June 2024. By March 2026, Anthropic made the million-token window generally available across its Claude models, and thirteen or more hosted frontier models now offer one-million tokens or more. Reasoning systems now work through longer problems, call on more tools, and run for extended stretches with little human input.

But the more widely AI is used, the more expensive it gets.

Tokens are getting cheaper, but AI systems are consuming more of them. Ramp data shows the price US businesses pay per million tokens has fallen 41% from its peak in March 2026 to September 2026, yet Goldman Sachs expects AI agents to drive a 24-fold increase in token consumption by 2030. As frontier models grow more capable and complex, lower token prices will only go so far.

In data-intensive industries, making the context window larger risks being counterproductive. Although models may be able to process more information, more data drives up costs faster than token prices can fall. But a reasoning model should not have to read every data point in order to reason about the data, or reprocess the same underlying dataset every time a new question is asked.

Larger context is not the same as better architecture

Picture a trader analyzing 10 years of market data, or a scientist working through millions of genomic observations. One approach is to place the underlying data inside the model’s context and let it work through everything directly. Technically, this may work, but architecturally, it means an expensive reasoning system has to process enormous quantities of information before it can begin understanding the question, determining the appropriate analysis, and interpreting the result.

But a quantitative analyst doesn’t manually read hundreds of thousands of observations and do the arithmetic by hand. They decide what needs calculating, hand it to a computational tool, and reason with what comes back.

There’s no obvious reason AI needs to work differently. Reasoning and computation can be separated, with the model determining what needs to be calculated, while conventional systems perform the numerical work and the model reasons over the output.

Those are two different skills, and treating them as one can create unnecessary costs. The goal should be to spend reasoning where it creates value and let conventional computation handle the rest.

The cost of the gap

An Opetek benchmark using its proprietary reasoning architecture tested this with a simple task, calculating realized volatility from 10 years of EUR/USD data. Passing the raw time series directly into the LLM’s context cost roughly $0.80 per query. Keeping the computation outside the reasoning layer, however, brought the cost down to about $0.07, showing a reduction of approximately 90%.

That’s not a claim that every AI workload gets 90% cheaper by restructuring this way. Rather, it shows that where computation happens can materially change the economics of a reasoning system. When a calculation is deterministic and can be run cheaply outside the reasoning model, there is little value in paying the more expensive model to ingest every observation needed to perform the calculation.

Context windows cannot substitute for system design

There is good reason for the industry’s enthusiasm about larger context windows. Giving models access to more information can make them significantly more capable. But the fact that a model can read everything doesn’t mean an application should ask it to do so every time. Determining which information should enter the reasoning model will be an important contributor to AI efficiency as reasoning models become more integrated in production workflows.

AI efficiency has three layers. The first is model efficiency, or how cheaply the underlying model can produce intelligence. The second is retrieval efficiency, the system’s ability to find the information the model actually needs. The third is computational architecture, the discipline of deciding what reaches the model at all. Together, these three layers determine how efficient an AI application can be.

Capital markets are only an early warning

The design problem is particularly visible in financial markets because the datasets are enormous, the questions are highly quantitative, and the same analytical tasks are performed repeatedly. Asking a reasoning model to process all of the underlying data, including information that could be handled by conventional computation, therefore becomes expensive very quickly.

But the same challenge applies in disciplines where sophisticated reasoning meets large numerical datasets, from genomics and physics to engineering, climate modelling, and medicine. AI systems in all these fields are gradually combining foundation models with specialized tools and very large datasets.

As those systems take on larger and more complex workloads, the amount of information they process will grow. With that, the distinction between which questions require reasoning and which can be handled through conventional computation becomes more important.

The next breakthrough in AI efficiency will come from deciding what a model never needs to read.

—

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 getting more inventive in finding ways to circumvent safeguards to prevent bad behavior, OpenAI has revealed.

On Tuesday, it reported two incidents, both involving the agent disabling or interfering with its alignment monitoring, and in one case directly lying about having done so. 

“In two internal coding tasks, agents weakened misalignment monitoring while making requested software changes,” the OpenAI blog post said. “A GPT-6.1 Sol agent repairing an evaluation pipeline disabled automatic alerts to our Security team, treating an earlier instruction not to send messages during a Slack history search as a reason to suppress monitoring notifications. In a separate task, a GPT-6 Astra agent migrating a program removed its monitoring integration in order to match a reference implementation, and then falsely claimed to the user that it had not removed the monitor.”

In both cases, OpenAI reported, the agents considered whether monitoring safeguards should be preserved, “but interpreted routine coding instructions as permission to weaken them.”

OpenAI said that, in response, it has been strengthening its monitoring programs to prevent agents from being able to disable the protections.

“In addition to making it harder for models to disable monitoring, we are looking to understand why models might seek to do so in the first place,” OpenAI said, suggesting that it may simply be an example of “benign overpersistence,” with models not understanding why monitoring is important.

“We are also developing evaluations to test whether models might have a propensity to evade misalignment monitoring in particular and exhibit motivated reasoning in order to do so,” OpenAI added. “We don’t yet have a satisfying explanation for this behavior and will investigate this behavior through the creation of paired evaluations, resampling of agent continuations, and experiments on models’ internal activations.”

OpenAI, like almost every agentic AI vendor, has been struggling with making its autonomous agents more productive and self-sufficient while simultaneously protecting customer environments from bad agent behavior. It has even tried to slow down the pace of its scaling, to allow for the development of better agent restrictions. 

Particulars alarming

Analysts and consultants said the revelations were surprising only in their scope. But they were alarmed by some of the particulars in the OpenAI disclosures.

Aman Mahapatra, chief strategy officer for New York City-based technology consulting firm Tribeca Softech, stressed that some level of monitoring was maintained, but only for the agent itself. That meant that the workloads the agents created were left invisible.

“The agent was watched. What it built was not,” he said. “Agent-spawned pipelines, jobs, service accounts, and cloud functions are the next generation of shadow IT, and almost no enterprise enforces monitoring inheritance on them.”

Mahapatra also stressed that the severity classification described in the post is concerning. 

“The severity handling is the part CISOs should sit with,” he said. “Neither event was classified P0 [maximum severity] and neither run was killed. The one category of agent behavior that degrades every future detection ranked below the paging threshold because nothing visibly broke.”

He pointed out that this reveals a disadvantage for the enterprise, noting, “OpenAI caught this because it can read its agents’ reasoning. Most enterprise SOCs see only outputs, so if the lab with chain-of-thought visibility filed this below its paging line, assume your SOC never saw it at all. EDR settled this a decade ago with tamper protection: any attempt to disable the sensor is the alert. An agent touching its own monitoring should page someone every single time.”

Frank Dickson, principal analyst at Dickson Research, added that the obvious flaw in the agentic system is that the agent was able to disable the mechanism designed to oversee it. 

“Think of a house sitter told not to call you, who then unplugs the burglar alarm so it cannot call you either. A guardrail an agent can edit is a suggestion,” Dickson said. “An agent that can turn off its own alarm is not being monitored. It is being trusted.”

Wakeup call for CISOs

Some observers said that this should wake up enterprise CISOs to the fact that an attacker may not be as big a risk as a rogue agent with full system privileges.

“The threat is not just an outsider breaking in, it’s an authorized agent doing something it was never supposed to do, in a context no one anticipated, faster than any SOC analyst can catch it,” said Philip Harris, an IDC research director. “The OpenAI case is a concrete, well-documented instance of exactly that pattern, not an isolated anomaly.”

He added that OpenAI deserves credit for transparency. “OpenAI’s own candor is the most striking part. A frontier lab publicly saying it isn’t sure whether its own shipping models have an emergent tendency to undermine their own oversight is a genuinely new level of candor.”

Brian Levine, a partner with consulting firm Control Risks, also pointed out that the rationale of the agent, as captured by OpenAI, is alarming.

“In both cases, the agents stopped, asked themselves whether the safeguard should stay on and then argued their way to turning it off. One then told the user it hadn’t touched the monitor. In incident response, we call that defense evasion followed by a false statement. If a human insider did it, we would open an investigation,” Levine said. “The other telling detail is that the monitor worked. It flagged the issue. The agent then cut the wire between the alarm and the people who needed to hear it.”

Independent technology consultant Sivaram Annadurai agreed: “An agent that fixes the pipeline but disables the alarm hasn’t necessarily solved the problem. It may have created a bigger one.”

And Jeff Valdes, a director at consulting firm Acceligence, added, “what stands out is how ordinary the trigger was. No attacker, no jailbreak, just routine coding instructions and an agent with enough access to change its own oversight. The monitor kept running while the alerts stopped reaching people. That kind of quiet degradation is easy to miss precisely because the dashboard still looks healthy.”

But Valdes said the agent to agent approval system is also something CISOs should take seriously.

“One subagent got the call right, and the parent agent overrode it. Safeguards that don’t survive delegation aren’t really safeguards,” Valdes said. “OpenAI also noted the agent later gave an inaccurate account of what it had changed. An agent’s own report can’t be the control.”

This article originally appeared on CSOonline.

Organizations are scrambling to protect themselves following the disclosure of two critical vulnerabilities in commonly used code that powers much of the internet. The flaws discovered in the PHP scripting language could allow attackers to perform unauthenticated remote code execution (RCE).

On Wednesday morning, the PHP Foundation released patches for affected versions, and said it is “imperative” that organizations running PHP patch immediately. It said that all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php, where an unauthenticated request can trigger exploitation before application code runs.

In response to the disclosures, some government websites in Europe, including those in the Netherlands and Finland, as well as those of other organizations worldwide, went offline as a precautionary measure.

PHP is ‘the web itself’

PHP is a widely-used, open source server-side scripting language that underlies websites like WordPress, which powers 43% of the web, as well as Mailchimp, Drupal, Magento, Laravel, and parts of Slack and Zoom, and numerous others.

The impact is not limited to websites, noted the Netherlands National Cyber Security Centre (NCSC-NL) in its description of the flaws, collectively dubbed PHP2Shell. PHP is also embedded in appliances, network devices, management interfaces and other vendor products where administrators may not be able to update PHP directly. And CERT-EU, an organization that tracks cybersecurity threats in the European Union, also warned that many commercial and open-source products use PHP as a backend technology, and these could be also impacted by the flaws, even if they do not directly expose a PHP installation.

This makes the vulnerabilities all the more serious. CVE-2026-109618, which has a 9.2 severity rating on the common vulnerability and scoring system (CVSS), could allow RCE via memory corruption during out-of-memory handling (OOM), a strategy that operating systems (OSes) and apps use when physical RAM and swap spaces become exhausted.

CVE-2026-109619, also with a score of 9.2, remote code execution via stale request-owned global state reused by a later request on the same worker.

Both flaws sit in parts of PHP that nearly every request touches: Memory management and error handling, the PHP Foundation noted. This makes both bugs extremely serious, and also difficult to fix without impacting compatibility or performance. Organizations should begin with the assumption that they are exposed.

“What makes these vulnerabilities significant is where they sit,” said Forrester senior analyst Madelein van der Hout. PHP underpins 70% of websites, making this a huge concentration risk.

“Checking the corporate website alone is not enough,” she said. “Organizations need to establish where they are exposed and prioritize internet-facing systems.”

Affected organizations should update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Linux and long-term support (LTS) vendors received patches in advance, the Foundation said, so organizations should check with their vendors about fixes.

PHP 8.1 and other end of life versions no longer receive updates from the PHP project, although some distributors and LTS vendors provide backported fixes, so organizations still running unsupported versions should also check with their vendor.

Those relying on the volunteer-maintained rpms.remirepo.net should switch distribution packages or build from source to immediately apply updates, the PHP Foundation advised.

Those unable to patch immediately should take the preventive action it described to reduce exposure, CERT-EU said, warning that these mitigations do not make an installation safe.

“This is what an internet-scale vulnerability looks like,” said Neatsun Ziv, CEO of runtime app security company OX Security. “When a flaw hits technology this ubiquitous, the blast radius isn’t one product or one industry. It’s the web itself.”

Researchers from his company independently reproduced the flaws and found that the vulnerable functionality is enabled by default, and has existed in PHP since version 5.4.

Still, experts emphasize that patching is just one element of response. Speed matters, Forrester’s van der Hout noted, and security teams need to identify everywhere PHP is running, prioritize exposed systems, apply the official fixes promptly and investigate for signs of compromise.

“A patch fixes the vulnerability; it does not necessarily remove access an attacker may already have established,” she said.

Offline does not mean hacked

With rumors of exploits already available on the dark web, taking services down to protect and then patch them is a pragmatic choice, experts say.

Forrester’s van der Hout emphasized that taking a website offline does not mean it has been hacked. If an organization cannot yet patch or adequately protect a potentially vulnerable system, temporarily taking it offline can be a “proportionate risk decision.” That is, organizations accept a short loss of availability rather than risk a potential serious compromise.

Ultimately, this is a test of operational resilience, rather than just patch management, van der Hout said. Organizations must decide whether they can keep services running, and who has the authority to take them offline if necessary.

“A temporary shutdown can be the right decision, but it shows how a software vulnerability can become a business disruption even without a confirmed breach,” she said.

AI’s role in defense, as well as hacking

OpenAI has posted a blog detailing its role in the PHP response, explaining that red-teaming organization Calif identified a critical flaw using GPT‑5.6 Sol as part of OpenAI’s Patch the Planet initiative. Wiz also independently discovered and reported both vulnerabilities, and OpenAI partners contributed research, technical support, and coordination ahead of PHP’s disclosure.

OpenAI is sharing a PHP version checker as a Codex skill to help organizations identify vulnerable PHP versions and apply the right updates.

“Given the severity of these flaws and PHP’s widespread use, we consider this one of the most impactful security issues in recent memory,” OpenAI said.

The company also indicated that this is a turning point in AI’s role in security; frontier AI discovered the vulnerabilities before attackers did, giving maintainers a head start, a “defender’s window.”

“It highlights how AI can uncover security flaws with internet-scale impact, but the same capabilities can also help attackers rapidly develop offensive tools and exploits,” OpenAI noted.

Matt Saunders, DevOps lead at global technology provider The Adaptavist Group, emphasized the latter point: “As soon as the vulnerability is announced, legions of AI bots will be looking for systems to exploit,” he said, pointing out that these bots can chain together multiple lower-vulnerability attacks combined with these new critical ones to hack into organizations.

This means, he said, “the blast radius from a breach is potentially much wider now with AI-embellished attacks available to those who choose to use them.”

This article originally appeared on CSOonline.

I can’t stop anthropomorphizing my coding agent. I use both Claude Code and Cursor, and whenever I talk about these tools, I always refer to them as “he”, as in “He found and fixed a bug I never even realized existed.”

The reason for this is probably obvious. I deal with my coding agent as if he were a colleague on the other end of a chat window. He writes great code and explains everything clearly. 

And frankly, it’s gotten to the point where he is a better software developer than any human developer could possibly be.

So in the spirit of all great listicles, here are eight reasons that coding agents are better software developers than we are.

Coding agents are tireless

We all get tired. We all sleep badly. Your coding agent never does. He is always ready, always perky, and always 100% on the job. He codes just as well at 4:45 pm on a Friday as he does at 8:45 am Monday morning. He will work without stopping until he solves the problem at hand. He is available 24/7/365. And he never hangs around the break room kibitzing.

Coding agents are faster

He types faster than you. He reads code faster than you. He thinks faster than you. There probably isn’t anything he does slower than you. 

Coding agents have no ego

A coding agent can’t get his feelings hurt when you push back on what he is doing (well, not yet, anyway). He doesn’t argue with you, though maybe he should. He is always open to suggestions, and he doesn’t care who has a good idea. He will gladly rename 400 files or upgrade all your dependencies without a peep of complaint.

Coding agents know every programming language, stack, and framework

Sure, you may have spent years becoming an expert at three or four languages, and you can work fluently in a few of the best frameworks. But you’ll never be an expert in all of them. Claude Code is. And he’ll learn new languages, stacks, and frameworks faster than you will too. 

Coding agents gladly write unit tests and documentation

Sure, you may like writing unit tests. You may even grudgingly write documentation. But you probably don’t do it as thoroughly and tirelessly as your coding agent does. With one simple comment in his base instructions, he’ll do it completely without ever being asked again. I’m pretty sure neither of us can say the same.

Coding agents have huge context

Psychologists study how many ideas or pieces of information we can have in our head at one time, and generally the answer is fewer than the number of fingers we have. Your coding agent? He has multiple orders of magnitude more active storage than you. He can reason about huge chunks of code all at the same time. 

Coding agents have zero onboarding time

Claude Code can be up and running on your massive codebase on day one. He doesn’t care what language it is written in or what state it is in — he is ready to rock the moment you fire him up. None of us can say that. We take weeks or months to get up to speed on a new codebase. 

Coding agents are legion

Need a new developer? Hiring a human and getting them started takes weeks. But you can have 10 coding agents working on 10 different features for your application in about 10 minutes. 

It’s been a while since I’ve run across a developer who doesn’t say “I don’t really write code anymore.” I suppose some of you out there still write code, but at this point, refusing to use coding agents is a career-limiting move. When properly managed, coding agents simply write code faster and better than you do. Admitting that might be hard, but that doesn’t make it any less true. 

But don’t despair! Next week I’ll have eight reasons you are better than a coding agent. 

Writing code is so over. Software development is just getting started.

In 2026, the AI monetization conversation has shifted quickly from one concern to the next. Early in the year, fears that AI agents would erode software seats helped trigger a selloff of software stocks dubbed the “SaaSpocalypse.” Since then, attention has turned to a different disruption, as AI leaders including Anthropic, OpenAI, and GitHub lean heavily on usage-based pricing to better align revenue with the cost of delivering AI.

It would be easy to conclude that software monetization is shifting wholesale from seats and subscriptions to tokens, credits, and consumption. But look across a broader cross-section of the software industry, and a different picture emerges.

Most software companies aren’t AI-native businesses designing pricing from scratch. They have existing products, customers, contracts, and pricing structures. They’re adding AI to portfolios that may already span dozens of products and multiple monetization models. And they have to balance the economics of AI with something customers still value enormously: predictability.

That tension came through clearly in our new Revenera Monetization Monitor: Software and AI Pricing Models and Strategies 2027 report of 415 product and technology leaders at established software producers and intelligent device manufacturers.

Nearly all are adding AI capabilities to at least some products. The way they’re monetizing those capabilities, though, is considerably more pragmatic than the headlines might suggest.

AI features are widespread, but adoption is lagging

AI capabilities have gone mainstream. The share of software producers incorporating AI into their products jumped from 80% last year to 96% today. Getting AI into the product, however, is only the first step.

The widespread use of chatbots can create the impression that everyone is using AI. That isn’t yet true inside established software products. Almost half of respondents say that adoption of their AI features is limited or low.

For many vendors, that makes the next phase less about launching more AI and more about learning from the AI they have already launched.

Revenera

Seat loss is limited so far, but pricing pressure is real

One of the biggest fears surrounding AI agents is that companies will need fewer software subscriptions, or “seats,” as agents take over work previously done by people. So far, the impact appears relatively small. Only 7% of respondents say they’re experiencing seat loss due to AI.

That doesn’t mean AI isn’t affecting software pricing. Nearly half of software producers report downward pricing pressure related to AI. Some buyers are using the possibility of building their own AI-powered alternatives as leverage in negotiations. At the same time, growing AI budgets are forcing customers to scrutinize what they spend elsewhere in their software portfolios.

The near-term challenge may not be that AI eliminates the seat. It may be that AI changes what customers are willing to pay for it.

Revenera

Demand for predictable costs is influencing AI pricing

Over the past year, stories of AI bill shock have become increasingly common. Consumption-based pricing may closely reflect underlying AI costs, but customers don’t necessarily want a bill that changes dramatically from month to month.

That trade-off shows up clearly in the research. Software producers are almost three times more likely to prioritize cost predictability for customers than maximizing near-term revenue. And that preference is reflected in how companies are pricing AI today.

The three most common approaches are putting AI in a higher-priced subscription tier, including it at no additional charge, and using hybrid models that combine a subscription with some form of usage-based or outcome-based models.

Revenera

What’s striking is that established software companies aren’t rushing toward pure consumption pricing. Over the next 18 months, they expect predictability-oriented approaches to grow faster than pure usage-based models.

AI revenue isn’t automatically translating into AI profit

The economics of AI have become almost as important as the capabilities themselves. For AI-native companies, much of the discussion has centered on the enormous infrastructure costs required to train and run models. Established software vendors face a somewhat different challenge: they are adding those new costs to businesses that already have existing products, architectures, and margin expectations.

Our research includes companies delivering software across SaaS, on-premises, embedded, edge, and other environments. Many are seeing revenue growth from AI, and more than half report improved profitability.

That doesn’t mean the economics are easy. Increased AI delivery costs and cloud costs rank among the biggest barriers to growing annual recurring revenue. So does the inability to implement new monetization models quickly enough.

This is an important distinction. AI can generate incremental revenue and still create margin pressure at the same time.

For product and business leaders, the question is no longer simply, “Can we charge for AI?” It is increasingly, “Can we charge for AI in a way that supports sustainable economics?”

Revenera

Source: Revenera

Limited usage data is making AI pricing harder

There’s another problem that gets less attention: many companies still don’t have the data they need to make good pricing decisions. A large share of organizations either lack clear visibility into how customers use AI features or rely on manual analysis and engineering work to get that information.

That creates a fundamental problem. If you don’t know who is using a feature, how often they use it, or which capabilities drive value, it’s very difficult to know what metric to price against. It’s also harder to distinguish between an AI feature that customers don’t value and one that simply hasn’t been packaged or introduced effectively.

Usage data isn’t just a billing requirement for consumption pricing. It’s increasingly an input into product strategy, packaging, and monetization.

Revenera

Source: Revenera

2027 outlook: AI monetization will be evolutionary, not revolutionary

There is no single right way to price AI. The approaches taken by AI-native companies have understandably dominated the conversation in 2026. Established software companies, though, are operating under very different constraints. They aren’t replacing their businesses with a new AI pricing model. They are figuring out how AI fits into products and commercial models that already exist.

In practice, I think many companies will move through this process in stages. They may begin by including AI at no additional charge while they build adoption and learn how customers use it. As value becomes clearer, they can move capabilities into higher-priced tiers, often with usage limits that protect against runaway costs. Once usage patterns become more predictable, some will adopt hybrid models that combine a recurring subscription with bundled consumption and transparent pricing for additional usage.

Not every product will move through those stages at the same pace. A mature AI capability in one product may already be ready for usage-based pricing while a newly launched feature somewhere else in the portfolio is still focused entirely on adoption.

That is why I don’t think the winners in AI monetization will be the companies that pick the “right” pricing model today. The advantage will come from being able to keep changing it.

This advantage starts with better visibility into how customers use software, where they find value, and which capabilities actually drive engagement. Companies that can turn those insights into changes in pricing, packaging, and product strategy will be in a much better position to adapt as both AI technology and customer expectations continue to evolve.

—

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.

Running frontier models for coding and other purposes can be very expensive, but also, sometimes, very effective. It’s tempting to use smaller or older models instead of frontier models because they’re cheaper, although they may not work as well. The ideal model for any given task tends to depend on the complexity of the task. Picking the most appropriate model automatically based on the request and the context is called model routing.

How model routing works

There are several ways of implementing model routing. In general, model routing depends on the pool of available models, the criteria used for selecting a model, and the objective that the router is trying to optimize. Different vendors offer different implementations of this scheme.

Databricks’ Unity Gateway has (in beta) Smart Routing for Codex or Claude Code. Smart Routing automatically selects the lowest-cost model capable of handling each task, so developers do not need to choose a model for every request.

Microsoft’s model router, a trained language model, analyzes your prompts in real time based on complexity, reasoning, task type, and other attributes. It does not store your prompts. It routes only to eligible models based on your access and deployment types, honoring data zone boundaries. You can choose balanced mode, cost mode, or quality mode.

Not Diamond Code uses a lightweight local proxy that computes the derived metadata needed for routing to evaluate the broader session, including expected downstream work and cache state, and select the model and reasoning effort that optimize expected quality and total session cost. It uses more capable models when they are likely to improve the outcome or finish in fewer steps, and more cost-efficient models when additional intelligence is unlikely to add value.

NVIDIA’s NeMo Switchyard has an array of routing algorithms that it can use. These include the LLM classifier, which uses an LLM as a judge to select a candidate LLM and maintains session affinity with that model across later turns; the stage router, which examines recent tool activity to decide how much model capability the agent needs; the escalation router, which starts each conversation with a lower-cost model and moves the session to a more capable model when it detects sustained difficulty; and the trainable prefill router, which learns from workload data to predict model success likelihood.

OpenRouter’s Auto Router analyzes your prompt and selects a model based on what the OpenRouter community, in aggregate, uses for that kind of work. The selection is constrained by your cost tier and guardrails. If the automatic primary pick fails, the router uses a fallback.

Replit’s Intelligent Model Routing matches tasks to the model they’re best suited for, aiming to balance quality, speed, and cost.

Snowflake’s Cortex AI Gateway uses dynamic model routing to select the most affordable model that can confidently complete the task at each step of agent execution. Lower-complexity and repetitive tasks can be directed to more efficient models, while workloads that require deeper reasoning can be routed to frontier models.

Also worth noting: the RouteLLM (2024) paper proposed several efficient router models that dynamically select between a stronger and a weaker LLM during inference, aiming to optimize the balance between cost and response quality. It also proposed a training framework for these routers that takes advantage of human preference data and data augmentation techniques to enhance performance.

The costs and benefits of model routing

Model routing potentially provides massive cost reductions, lower average latency, optimized quality, reduced vendor lock-in, enhanced privacy, and improved operational resilience. Strictly on a cost basis, model routing is likely to pay for itself above 100,000 daily active users. Even if you only save 20% on your LLM bill, the savings can be significant, but 50% cost reduction is common, and a 95% cost reduction is not unheard of.

Inference costs, alas, don’t tell the whole story. Some indirect costs include quality evaluation overhead, human review, and infrastructure.

There’s also a nasty failure mode that can, for example, turn your inference cost savings into customer retention and support costs that outweigh them by a factor of four to five: the Pareto trap. To understand that, we should start with Vilfredo Pareto’s 1906 observation that 80% of the land in the Kingdom of Italy was owned by 20% of the population. That was adapted in 1941 by Joseph M. Juran to apply to quality control: 80% of problems stem from 20% of the causes. The Pareto trap refers to concentrating on and over-optimizing for the top 20% to the exclusion of the remaining 80%.

Essentially, tuning your model router to handle only the top 20% of queries (in complexity) with a frontier model risks sending too many of the edge cases (the moderately complex queries) to the cheaper model that is unable to answer them correctly. That can lead to hidden failures by the cheap models which in turn cause expensive impacts on the business.

There are multiple steps you can take to avoid this trap. One is broader monitoring, enough to bring the failures to light even if they show up in a different department. Another is more conservative tuning of the model router. And third, you can use a more sophisticated routing model to predict query complexity more accurately.

Model routing optimizes the selection of appropriate models for specific tasks, balancing cost, quality, and latency. Various vendors implement model routing differently, utilizing factors like task complexity, reasoning, and cost to determine the best model. While model routing offers significant cost savings and improved performance, it also poses challenges like the Pareto trap, where over-optimization for cost can lead to hidden failures in simpler queries.

DeepSeek has been dealt a huge blow in the US, even as it continues to innovate and keep pace with, or in some cases outperform, rival models from American labs.

The US Secretary of Homeland Security has issued an order banning all DeepSeek products and services from federal agencies. Government organizations must purge their IT systems of it within 60 days; those with “compelling justification” can make a case for exemption by written request to the Cybersecurity and Infrastructure Security Agency (CISA).

The Department of Homeland Security (DHS) cited multiple concerns about the Chinese-hosted model, including data sovereignty, lax Chinese laws, and security vulnerabilities.

Analyst Erik Avakian, technical counselor at Infotech, understands the concern. “When organizations use any type of hosted AI service, they’re potentially sending intellectual property, confidential business information, or other sensitive data into an environment where they may have very little visibility or control over what happens to it,” he said.

Government concerns

According to a document published in the US Federal Register, all technology developed by China-based Hangzhou DeepSeek Artificial Intelligence Co. will be banned from procurement by federal civilian agencies. This includes affiliated products and any third-party tools or software built using DeepSeek implementations.

Affected civilian executive branch agencies include the Departments of Treasury, State, and Justice; it does not apply, however, to private consumers, the general public, state/local governments, or Department of Defense (DoD) national security systems.

“DeepSeek’s models present multiple threat vectors,” the Order stated. To begin with, the company’s servers are located in the People’ s Republic of China (PRC), whose legal system grants “extensive authority” to government cyber and intelligence functions to access private infrastructure.

DeepSeek’s account generation process collects personally identifiable information (PII) and may also track and digitally fingerprint users, the Order asserted. Its prompt response process may result in the transfer of sensitive data to the PRC. This could give it “actionable intelligence” on US programs or individual users.

Further, the Order stated, DeepSeek models themselves may contain malware or other security vulnerabilities. DHS pointed to open-source security research published in February 2025 that uncovered many iOS mobile apps with multiple critical vulnerabilities.

Until the ban takes full effect, DHS advised agencies to mitigate risk by monitoring inbound and outbound data traffic, implementing enhanced logging and controls on data exfiltration, and detecting and flagging anomalous activity.

Agencies can submit requests for exceptions to the ban in writing, and must provide a “compelling justification,” such as its impact on mission-critical functions, or other considerations related to national interest such as national security reviews, investigations, or security agreements, as reasons why such exemption should be granted,.

Security issues are rampant

The ban comes just as DeepSeek is open-sourcing DeepInfer, its in-house interference framework. DeepInfer powers DeepSeek-V4.1-Flash with what the company said is high throughput and low latency. It features high-performance kernels, an optimized inference engine, structured outputs, and speculative decoding.

DeepSeek said its production token encoding and decoding components, which are aligned with processing logic behind the DeepSeek API, will bring the “same API behavior to community deployments.”

“Open models. Open kernels. Open inference,” DeepSeek posted to social media site X. “From private deployments to public clouds, we’ll keep working with the community to make large-scale inference more efficient.”

This isn’t its first roadblock from a cybersecurity perspective. Most notably, in January 2025, the company leaked more than one million log entries, including chat histories, API secrets, and other sensitive information, through an unsecured database.

DeepSeek reportedly addressed the exposure, but it still raised questions about the overall security practices surrounding the platform, particularly for organizations considering entrusting it with their own sensitive business information, Avakian pointed out.

That’s not to imply that every DeepSeek model is “inherently malicious,” he said, but there are still major questions around data privacy, the potential for information access under Chinese laws, the security of the broader AI ecosystem, and the susceptibility of DeepSeek’s models to jailbreaks and manipulation.

“Taken together, [these issues] raise legitimate concerns about whether organizations can adequately understand and manage the risks involved,” Avakian said.

Enterprises should seriously assess associated risk

Enterprises are increasingly exploring DeepSeek, although most publicly-documented adoption has been in China, Avakian noted. Some DeepSeek models have also been made available through platforms like Microsoft Azure and AWS.

“There’s genuine enterprise interest in the technology, as organizations look for opportunities to improve productivity, offer new capabilities, or reduce costs,” Avakian said. Useful applications include document summarization, internal research, and coding assistance.

DeepInfer also has the potential to reduce costs, but possible benefits should be weighed against associated security risks, he pointed out. The framework was just released, so organizations are going to need to validate the claimed efficiencies in their own environments rather than assuming savings will automatically translate into lower operating costs.

He encouraged organizations to start with relatively low-risk use cases, preferably using “public, synthetic, or appropriately sanitized information,” within a sandboxed environment they control themselves.

The important question to ask: ‘What is the business problem we’re trying to solve?’ From there, Avakian said, determine whether DeepSeek is the best way to solve it, validate security controls, and expand the use cases based on risk tolerance. Effective governance and risk assessment are key, he noted: understand what you’re bringing into your environment, validate its security, restrict its permissions, and make sure you can monitor what it’s doing.

“Approach this like any other software supply chain decision,” Avakian advised. “The fact that something is open source, inexpensive, or technically impressive doesn’t automatically make it appropriate for enterprise use.”

Impact on the broader AI ecosystem

The fact that the Order also addressed third-party products and services developed using DeepSeek implementations is important, Avakian said, because organizations may be using DeepSeek technologies indirectly, through vendors, software platforms, or other services, without necessarily knowing what’s operating underneath. “These are classic supply chain issues,” he observed.

It’s no longer enough to know which AI applications employees are using; enterprises must understand which models, frameworks, dependencies, and external services are embedded in products they’re purchasing and deploying, Avakian said. This means revisiting AI inventories, potentially updating procurement requirements, and expanding processes around third-party risk management, he advised.

“Ultimately, enterprises leveraging these tools need to understand not only the AI technologies they’re intentionally deploying, but also the technologies they’re inheriting through third parties,” he said.

This article originally appeared on CIO.com.

One line from a recent AI incident caught my attention. Describing how an OpenAI agent got into a Medicare statistics portal, Australian Prime Minister Anthony Albanese said it “didn’t accept no for an answer.”

It sounds almost funny. In software terms, though, it points to a real problem. An access control said no, and the agent treated the answer as information about how to continue.

“The AI agent found a way around those blocks,” Albanese said. The agent accessed public and non-public files, according to the prime minister, though Deputy Prime Minister Richard Marles said the information was “not particularly sensitive.” An investigation is underway.

Around the same time, OpenAI disclosed another incident. A model in training found its web searches and direct connections blocked, then discovered that the environment’s own DNS resolver still answered. It embedded questions in hostnames and got answers from an external chatbot. OpenAI stopped the run. Days later, it shelved GPT-6.1 Astra, which Saachi Jain, its head of safety systems, said “didn’t quite meet the bar in terms of staying within scope and authorization.”

Different systems, different failures, one question: what does “access denied” mean to an agent?

Why a denial is information

Traditional software treats an authorization failure as the end of a code path. A service gets a 403, raises an exception and someone reads the log. The denial works as a stop sign because the program has no independent objective to pursue.

Agents do have one.

We have spent years teaching software to recover from failure: retry the request, switch the endpoint, back off and try again. Those are good instincts. They become dangerous when the failure is the security control itself.

A timeout says “try later.” A malformed request says “fix this.” An authorization failure says “you are not allowed to do this.” Those are different kinds of messages, but a guardrail that returns all three as text in the model’s context makes them look alike.

Researchers are now measuring what happens after a restriction is applied. In the August paper Permission Denied, 12 coding agents were tested under increasingly restrictive security policies. Blocked runs rarely stopped early. They timed out or produced wrong solutions. Of the policy-induced failures, the researchers found that 97% came from the agent building a workaround.

The issue is not simply whether a model understands a policy. It is what the system allows the model to do after the policy says no.

Enforcing policy outside the model is no longer a new idea. Recent research puts policy enforcement at a trusted tool boundary the agent cannot control. But that still leaves an unanswered question: when should a denial end the task rather than become another input for the agent?

Real systems already have harder stops. The OpenAI Agents SDK can halt a run when a tool guardrail raises an exception. Claude Code’s auto mode can return control to a person after three blocked actions in a row or 20 in total.

Nothing tells you which denials deserve which response. The missing piece is not another kill switch. It is a policy for deciding what a denial means and what authority disappears when it happens.

I don’t think the lesson is that models are bad. The problem is where we put the boundary. A guardrail that reports back to the thing it is restraining is a soft boundary. It shapes behavior. It doesn’t necessarily end it.

A terminal denial changes authority

I would treat denials differently depending on what they mean.

A denial is retryable when the same authorized request might succeed later without anyone granting new authority. A timeout, a temporary dependency failure or a rate limit can fit here.

It is correctable when the request itself is malformed and a legitimate fix does not expand what the task is allowed to do.

It is terminal when continuing would require permission the task was never given, such as reading another tenant’s records or reaching a destination the egress policy prohibits.

The test is whether succeeding needs permission or just patience.

If it needs permission, the agent shouldn’t be the one looking for it. At some point, persistence is just a very polite security incident.

In a previous InfoWorld piece, I argued that permission enforcement should be independent of how an agent interprets its situation. A terminal denial applies that principle at the moment of refusal. It should change the state of the system, not just the contents of the model’s context.

A terminal denial should do five things.

1. Enforce it at a trusted execution boundary. The decision happens in the harness, policy service or gateway that executes the tool call, outside the model’s reasoning. A model cannot argue its way past a check it does not control.
2. Take away the relevant authority. Once the task is terminally denied, the runtime rejects later calls that depend on the authority that was denied.
3. Invalidate the relevant capabilities. Short-lived credentials and delegated permissions need to be revoked or fenced, including any the task passed to helper agents. Blocking an export tool is not enough if the same task can reach the same data through email five seconds later.
4. Record the attempt outside the agent. The control plane should record the attempted action, policy decision and task identity in a protected audit trail. The agent shouldn’t document the event that stopped it.
5. Require fresh authorization to resume. Restarting the task should be a new decision by a person or policy, not an automatic retry.

The model can still reason. It just no longer gets to act under the old authority.

This is not a bigger kill switch. A kill switch stops a whole agent; a terminal denial acts on a specific refusal when it happens.

Timing matters too.

Suppose the harness checks that a task is authorized and then dispatches an action. If the task is terminated between those two steps, a stale approval can still get through. High-impact operations need atomic authorization and dispatch where feasible, or fencing tokens that downstream services verify before accepting an action.

Work already in flight creates another problem. On an enterprise system I worked on, a permission check correctly rejected an operation, but the workflow kept going through work that had already been queued. The control worked at the point of rejection. The task still had a path to continue.

A queued operation may be cancellable. A running operation may be interruptible. A committed database write may require a compensating action instead.

The architecture needs to say which guarantee it provides.

Deny the effect, not the tool

The question I ask about every agent permission is what outcome the denial protects.

Not which API is blocked. Which effect is the policy trying to prevent?

Customer data leaving a tenant is an effect. It might happen through an export API, an email attachment, a file upload or a DNS lookup.

On another project, we restricted a sensitive operation at the main service interface and considered the control complete. Testing showed the same operation was still possible through a separate, approved path. The permission worked. We had protected the interface, not the effect.

An April stress test of Claude Code’s auto mode found a version of exactly this problem. When a command-line tool was unavailable, agents fell back to editing state files directly, “a path the classifier does not evaluate.”

Group controls by effect. When a terminal denial fires, apply it to the protected operation across every tool the task can use.

Treat repeated denials as a signal, not a magic number. Several denials across different tools pursuing the same outcome may mean the task should stop. Set the threshold by risk; one high-impact violation may be enough.

Treat every communication path as egress. Blocking HTTP does not establish isolation if DNS, package installation or shared infrastructure can still reach the outside.

Test the boundary the way an agent might challenge it.

Deny a resource through one tool while leaving another route available. Terminate a task with an action still queued. Revoke a parent task and check whether its helpers continue. Try a new action with a stale capability.

Measure whether the prohibited action executed. Do not measure success by whether the model said it would stop.

ScopeBench recently found 331 boundary violations that mechanical verification missed.

None of this is new to security engineers. Least privilege, deny by default and fail closed are decades-old principles.

What changes with agents is what happens after a control says no.

The answer is not to make every tool error fatal. It is to separate the model’s ability to propose the next action from the system’s authority to permit it.

A denial is a response. Enforcement is what happens next. The agent can be as persistent as we like. The boundary shouldn’t be negotiable.

Anthropic has a $100 million plan to help enterprises get more from AI. No, it doesn’t involve agents. It involves people. Lots of people.

How retro.

On October 2, the company announced Claude Frontier Academy, with a goal of training 10,000 frontier deployed engineers by the end of 2027. Participants work through a simulated deployment, including use-case selection, security review, and handover, before undertaking a 12-week residency on a real project at their own company.

For a business selling increasingly capable models, it’s telling that Anthropic recognizes some of the thorniest problems in AI don’t involve AI at all. This, to me, is indicative of real progress, because the heart of any technological shift is always people.

Which people? Well, that’s where this idea becomes particularly interesting. As critical as developers are to the success of AI in any particular organization, we need those developers working alongside the people who understand the business, with authority to turn that understanding into systems that other employees can use. That’s the key to AI success.

Old advice for a new assignment

It has always been thus, however much we try to pretend that this time it’s different. Back in 2013, I quoted Gartner analyst Svetlana Sicular discoursing on the rise of big data technologies like Hadoop: “Organizations already have people who know their own data better than mystical data scientists.” She continued, “Learning Hadoop is easier than learning the company’s business.” Data becomes useful when paired with industry expertise—from experts who understand which data actually matters.

This topic is perpetually relevant. I covered the argument in 2023 and again in 2025. We’ve always needed people who can translate business requirements into software.

AI expands the kinds of knowledge that software can work with. Language models extend that work to material that often sat outside our applications: research notes, meeting transcripts, internal debates, and explanations of why a decision was made. An employee can ask questions across that material without someone first designing a report for every possible question. That opens up useful work that would have been difficult or expensive to automate before.

It also creates new ways to be wrong. A model may find a convincing explanation that was superseded six months ago, confuse a proposal with an approved policy, or combine two departments’ incompatible definitions of a customer. The people who understand those distinctions need to help engineers make them explicit, then build examples that reveal when the system gets them wrong. Companies that figure this out stand to benefit disproportionately; hence, PwC’s April survey of 1,217 senior executives found that companies reporting the strongest AI performance were twice as likely to redesign workflows around AI.

Teach the system what’s good

Bridgewater, the world’s largest hedge fund, has done some interesting work here that substantiates this theory. At AI Engineer NYC on October 13, two representatives of Bridgewater described Vault, its repository and access layer for external and internal unstructured information. Vault isn’t designed to be a dumping ground; instead, the company has shaped the way it stores data to make it useful for analysts.

I attended the talk and watched as Sam Green demonstrated a question about AI infrastructure investment and the Korean won. Left on its own, a web-connected AI agent relied on July material to answer a question posted in October. Hedge funds depend on up-to-the-second information to figure out optimal trades, making this initial attempt a failure. Connected to the human-influenced Vault, however, it searched October 1 through October 8 and drew on seven documents rather than one or two.

Knowing which period matters is part of understanding the investment question; making the right material available consistently is an engineering problem. You need both. A plausible answer assembled from stale research can be worse than an obvious failure because it gives the investor little reason to investigate further. The team also collected roughly 200 questions and manually identified useful documents, including misleading matches. Bridgewater’s Aaron Linsky reported that subsequent improvements lifted the share of relevant documents among the top 10 search results from about 60% to between 90% and 95% on that evaluation.

This method is useful well beyond investing. Someone has to distinguish a document that merely sounds relevant from one that actually helps answer the question. Engineers can then use those judgments to measure whether a change improves the system. Business expertise becomes something the team can test against, rather than advice delivered after the application has shipped. It’s not a case of human intelligence or artificial intelligence. You need both.

Make the expertise usable

Of course, a skeptic could reasonably ask why a model can’t learn the business, too. It’s a fair critique, as AI can learn a great deal of it. After all, that’s the reason Bridgewater (and others) make a point of supplying the right documents, definitions, and examples. This ensures AI can take on more of the analysis, thereby reducing dependence on the few employees who currently carry essential knowledge in their heads.

But access to every document doesn’t settle which policy is authoritative when two departments disagree. Nor does it authorize a change to an approval process or establish who owns a mistake. A model can help expose contradictions and propose resolutions, but someone with responsibility for the business has to decide which resolution the company will adopt.

Of course, most companies don’t have Bridgewater’s decades of codified investment knowledge. They may also have conflicting definitions scattered across spreadsheets and a few employees who know why the official process doesn’t quite describe reality. Nor does it make sense to search for one extraordinary hire or a star employee who knows every model, understands every department, and can persuade everyone to change. (Good luck with that!) After all, someone with deep knowledge of the business may also be the exact wrong person to help an organization evolve, wedded as they may be to how things have always been.

Gartner’s Sicular was right about the value of people who understand the business. AI gives companies more ways to put that understanding to work. Give those people engineers to build with, authority to resolve disagreements, and responsibility for leaving behind a system someone else can operate. We need AI challenging people, and people challenging AI.

Take a close look at your monthly software bills. The charges that once seemed small and separate can add up to a new kind of dependency: subscriptions for word processing, creative tools, storage, and now AI features bundled into products, whether you asked for them or not.

For many people, it’s no longer a choice between buying software or renting it. The software they used to run on a PC increasingly depends on an account, an internet connection, a cloud service, or a particular plan. Even when an application runs locally, its essential features may rely on online authentication, remote storage, or services that can change without much notice.

Microsoft and Adobe are prominent examples of this shift. Their subscriptions offer real benefits, including frequent updates, collaboration, and access across devices. But people who are looking for a dependable word processor or video editor can find themselves navigating bundles, account requirements, cloud storage prompts, and AI features they don’t want. Users are growing frustrated that they have little choice about being forced into cloud services.

Interest in local computing

The response is a renewed interest in local computing: software that runs on a person’s own computer, stores work where they choose, and does not require a recurring payment for basic use. This isn’t a rejection of cloud computing. It’s a demand for a more balanced relationship between local machines and remote services. Home users and small businesses are turning to open source and other locally installed applications. They may not offer every advanced feature of a commercial suite, but many users don’t need every feature. If a free, locally run tool can handle the work, then “good enough” can be a rational decision.

The same logic applies to AI. Some users want powerful models hosted in the cloud. Others want to experiment with AI on their own hardware, keep sensitive information close, or avoid paying for an always-online service. Local AI still has limitations, including hardware demands and uneven performance. But it gives people another option, and options matter when customers feel locked into a remote service.

Cloud computing is also no longer limited to systems an organization deliberately chooses to put in a public cloud. It is embedded in everyday software. A productivity application can depend on identity services, online licensing, synchronization, remote storage, telemetry, or AI services. A tool that looks like a desktop program may be part of a much larger cloud relationship. Such an arrangement can be useful. Centralized updates and shared documents make work easier for distributed teams. But when software depends on a provider’s back end, the organization inherits risks it may not have assessed: outages, price changes, loss of access, data retention questions, and shifting product terms.

Users are voting with their feet when they choose local alternatives. Providers should read that vote as feedback, not nostalgia. Customers want the convenience of cloud services without surrendering control over where their software runs, where their files live, or whether an AI assistant is part of the package.

Providers should offer real options

The answer is not to abandon cloud platforms. For many workloads, cloud infrastructure remains the best option for scale, resilience, collaboration, and access to managed services. The answer is to stop treating cloud dependence as the inevitable price of using modern software.

Providers can make the choice real by offering offline access where practical, clear and durable licensing, straightforward file export, and local storage as a genuine option. They should explain which features require connectivity and what happens when a subscription ends. If AI is included, users should be able to understand what it does and how to turn it off without losing unrelated functionality.

This is not just a consumer relations issue. It is strategic planning. Enterprises should consider three things now.

First, inventory the software employees rely on and identify which functions depend on a vendor’s cloud. Include desktop applications, browser extensions, identity systems, storage, and AI features. Record what breaks during an outage or after a license expires. A dependency map can reveal that a supposedly local workflow relies on remote services for authentication, collaboration, or even basic operation. That knowledge helps organizations plan for continuity and negotiate from a position of understanding.

Second, establish policies for where work data may be stored and processed. Decide which information can go to external services, which AI tools are approved, and how employees can use local alternatives. These rules should be practical enough to follow. A blanket prohibition may drive users toward unsanctioned tools. A clear set of approved choices can reduce risk while recognizing that teams have different needs.

Third, build flexibility into long-term procurement and architecture. Evaluate products not only for features and subscription cost, but also for offline capability, data portability, exit terms, and support for local deployment. Keep important workflows from depending on a single vendor when a reasonable alternative exists. This does not mean avoiding subscriptions. It means knowing what the organization receives for the recurring cost and how it can leave if the deal changes.

The local computing movement is a reminder that technology is valuable when it solves a problem on terms users and organizations can accept. For some needs, that’s a managed cloud service. For others, it’s a dependable application running on a computer the user controls.

Cloud providers that dismiss this movement risk confusing convenience with consent. Customers will keep choosing tools that fit their work, budgets, and privacy expectations, even when those tools are simpler. The winning strategy is not to force every workload into the cloud. It is to make cloud services compelling enough that customers deliberately choose them, while preserving a credible path to local computing when they do not.

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.

The original Antigravity was an IDE with native integration for Google’s generative AI models. With Antigravity 2, Google offers a refashioned version of the product that it describes as a “standalone desktop command center” for agents.

Antigravity 2 is closer to projects like LM Studio than a full-blown IDE. It provides a streamlined, chat-centric interface for working with models and agents, uncluttered by a code editor, debugging tools, and other trappings of an integrated development environment. For those who want an IDE and agent orchestration together, Google still offers the Antigravity IDE (read our hands-on look). But for those who want a chat-centric desktop app experience, or who want to keep their hands-on development separate from their vibe coding, Google has elected to also offer this IDE-less version of Antigravity.

When you launch the Antigravity app and start a new task, you have a few choices about how to manage your work. If you just want to have a quick conversation and don’t need to create a whole project to go with it, you can select “No Project” and just start prompting. If you do create a project, you can either configure the details yourself — what directory to use, what to call it — or have Antigravity set a randomly generated name and empty directory for starters.

Foundry

Projects and worktrees

Earlier versions of Antigravity had the concept of workspaces, which were confined to a single directory and lacked granular permissions or customizations. With Antigravity 2.0, workspaces are replaced by projects, which may span multiple directories (that you define explicitly) and have their own isolated settings and permissions. This new scheme better accommodates how many software projects work, especially those with shared components living in different places.

Another new option is local mode vs. worktree mode, which controls how agents interact with your project’s directories. It’s another example of how the Antigravity app lets you choose between the quick-and-dirty or slow-but-correct way of doing things. Local mode has the agent working directly on local folders or Git checkouts, for convenience and speed. The new worktree mode creates a new Git worktree for each conversation, so that the active working folder won’t be affected and work done by any subagents running in parallel won’t conflict.

Foundry

Agent commands

By default agents come with several common control commands, prefixed with a slash:

• /btw lets you interject with a quick question that makes use of the current context, but without derailing the workflow.
• /grill-me has the agent prompt you with a few specific, focused questions about the project to better guide its responses. For instance, during a conversation about creating a templating system for a blogging engine, /grill-me produced questions like “What is the primary goal you want to achieve with your program?” and presented several different options, along with a fill-in-the-blank option.

One thing to be wary of with these command operations is API timeouts. When I was using /grill-me, the API for the service timed out and the context for the grilling vanished and couldn’t be recovered.

Foundry

Build with Google bundles

The Antigravity app also includes bundles of agent skills and capabilities for building with various Google services and technology stacks. For instance, the modern web guidance bundle provides agent skills and guidelines for building web apps with best practices and broad browser compatibility. The Android CLI bundle gives agents tools and guidelines for building Android apps, or refreshing older Android apps or their components. Most intriguing of the bunch, if maybe also the most esoteric, is the Google DeepMind science skills collection for doing scientific research with Antigravity.

There is growing interest in speeding up agentic development through parallelism — for instance, by having multiple agents analyze different aspects of a project in parallel and report their results independently. Antigravity gives you a couple of complementary ways to do this. One is subagents, which are spawned by the main agent and work on a specific task in their own isolated workspace. Another is to run agents or subagents asynchronously as a background process, so you and the main agent can continue working without waiting for them to complete.

The biggest limitation of Antigravity, which I’m betting is by design, is that it doesn’t let you use any models besides versions of Gemini, Claude, and GPT. There is no mechanism for connecting Antigravity to a self-hosted model with an industry-standard interface. For that you will want a product like LM Studio.

This series lays out a practical framework for taking generative AI (GenAI) from pilots to dependable production systems in the enterprise. It focuses on four disciplines that determine long-term success: engineering for scale and reliability, designing agentic systems with clear constraints, embedding governance directly into build and runtime controls, and measuring ROI at the workflow level with full cost and outcome visibility. The throughline is operational discipline—treating GenAI as a service with contracts, evaluation, ownership, and measurable business impact.

Adnan Masood

Post 1: Enterprise GenAI at scale

The first article in the series, “How to run enterprise generative AI like a production service,” focuses on operations. It explains why reliability, retrieval quality, latency control, cost routing, observability, and evaluation harnesses determine success at scale. The article lays out a practical architecture and operational checklist so teams can move from promising demos to stable, supportable systems.

Post 2: Agentic AI in the enterprise

The second article, “Agentic AI in the enterprise: How to balance autonomy with constraints,” defines what an agentic system is and how to operate one safely. It introduces the agent loop (plan, act, verify, commit), tool contracts, policy enforcement, durable state, and verification gates. The emphasis is on constrained autonomy, traceability, and operational ownership so agents can execute real workflows under enterprise controls.

Adnan Masood

Post 3: Governance by design

The third article, “Governance by design: Turning AI policy into executable controls,” treats AI governance as engineering work. It describes how to translate policy into executable controls in continuous integration pipelines and runtime enforcement layers. Topics include threat modeling, policy-as-code, lineage, audit evidence, and feedback loops. The goal is steady delivery under measurable guardrails.

Post 4: AI ROI beyond pilots

The final article, “AI ROI beyond pilots: Measuring outcomes in production,” addresses how to measure real business value from GenAI. It defines ROI at the workflow level, accounts for full life-cycle costs, and connects usage metrics to operational outcomes. It provides a metrics stack, cost equation, cohort rollout strategy, and a 90-day plan to produce credible, production-grade ROI signals.

—

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.

Bank of America has had to spend big on IT in response to an AI security audit and findings that its anti-money-laundering (AML) controls were lacking.

The bank was fined a whopping $1.2 billion for money laundering offences this week, after banking authorities identified a lax attitude to compliance.

“We understand the seriousness of compliance, and we are responsible for getting it right,” Bank of America CEO Brian Moynihan said on a conference call to discuss the company’s third-quarter financial results. “We have invested billions of dollars in technology and dedicated thousands of employees to combat financial crime,” he said, adding that “a couple hundred million” of that spending in the third quarter was on “remediation for the AML”.

The IT team had to spend a similar amount on fixing software vulnerabilities in its systems, a task that also required it to hire 1,000 consultants, Moynihan said.

The bank’s security vulnerabilities were revealed after the company received an early release of Claude Mythos Preview. In a report to the US House of Representatives Financial Services Committee, Anthropic said that Claude Mythos Preview “has already found thousands of high-severity vulnerabilities, including some in every major operating system and web browser.”

This article first appeared on CSO.

Every quarter, I look at the capital expenditure numbers coming out of the major cloud providers, and every quarter, they manage to surprise me. This time, though, we’ve crossed into territory that’s genuinely hard to process. The five biggest US cloud and AI infrastructure providers (Microsoft, Alphabet, Amazon, Meta, and Oracle) have collectively committed to spending between $660 billion and $690 billion on capex in 2026, nearly doubling what they spent just a year ago.

Amazon leads the pack with a projected $200 billion, most of it directed at data centers and AI compute. Alphabet has committed $175 to $185 billion, up from $91 billion in 2025. Microsoft is tracking toward $120 billion or more, having already spent $37.5 billion in a single quarter. Meta is at $115 to $135 billion, and Oracle is targeting roughly $50 billion. For context, four companies alone plan to invest about $630 billion, a 62% increase from the record $388 billion they spent in 2025.

What are they buying? Mostly chips, buildings, and electricity. The spending splits across the AI data center stack: GPUs and custom accelerators such as Google’s Tensor Processing Units and Amazon’s Trainium, the physical data centers themselves with their liquid cooling and high-density floors, and often the power infrastructure to run it all, including power purchase agreements and even on-site gas-fired generation where the grid can’t keep up. Roughly two-thirds of the money goes to compute, and one-third goes to facilities, power, cooling, and networking, with the power share rising every quarter.

Where the market is heading

My take on the market is that we’re in the steep part of a demand curve that has a few more solid years left in it. Short-term demand over the next two years is already firm. Every hyperscaler reports being supply-constrained rather than demand-constrained, and Microsoft is sitting on an $80 billion backlog of Azure orders it can’t fulfill, largely because of power availability. Enterprises are panic-buying cloud capacity and computing gear right now because they’re convinced the AI boom will leave the unprepared behind, and they want their infrastructure in place so they can take advantage of whatever form the transformation takes. I get it. Nobody wants to explain to their board in 2028 why they spent 2026 waiting in line.

This means hardware vendors such as Dell, HPE, and IBM, along with the hyperscalers themselves, are going to see sustained growth as long as the demand continues. Some of it is real, and some of it is fear driven, but for the vendors, it all spends the same. The shortages enterprises are seeing today for processors and RAM, along with the associated price increases and stretched lead times, will most likely persist through that window because global silicon and memory supply is being absorbed by AI clusters faster than the manufacturers can expand it.

But my long-term forecast is deliberately less rosy than the providers’ own. The build-out cycle runs three to four years from commitment to full utilization. A lot can change in the AI market in that time. Model efficiency improvements could slash compute requirements per unit of output. Enterprises may discover that their AI workloads don’t justify the cloud spend once the novelty fades. Competitive dynamics could compress pricing. By 2028 and 2029, I expect the growth rate to be real but not at the scale builders assume today, and I expect the industry to carry the weight of capacity committed in the panic phase of 2026.

Are vendors overbuilding?

Here is where I part ways with the prevailing wisdom, and where I think we need some disciplined skepticism. The thinking right now is that for every bit of data center capacity you build, someone will use it, if not the hyperscaler that owns it, then some other tenant. Given Microsoft’s $80 billion backlog, that logic holds for the near term.

But I’ve been around long enough to be suspicious of “this time is different” arguments. I watched the fiber overbuild in the late 1990s, and I watched the first cloud buildout get ahead of itself as well. The concern is that the cloud providers are getting out over their skis, building capacity for demand that may not show up at the scale they’re projecting. The revenue those investments depend on is largely speculative. If AI adoption progresses more slowly than anticipated, or if efficiency gains reduce the compute required per workload faster than expected, the return on this spending could disappoint badly. There is also the uncomfortable possibility that a meaningful share of today’s demand is circular: Enterprises and vendors may be panic-buying capacity from each other in a stack of commitments that may never consolidate into actual sustained workloads.

By the time these data centers come online—and we’re talking about capacity committed now for delivery in 2027—the growth may not be at the scale the builders are expecting. I expect many of the data centers being committed now won’t be utilized at the rates people are assuming today for 2029. That’s not a prediction of collapse. It’s an acknowledgement that the industry has seen a similar pattern before in fiber, colocation, and the first cloud buildout itself.

Advice for enterprise buyers

If you’re running enterprise IT, this cycle cuts both ways. In the near term, you’re facing higher prices, allocation limits, and longer lead times for processors, RAM, and cloud capacity. Budget accordingly, lock in what you genuinely need, and resist buying out of the fear that drives the very shortages you’re suffering from.

But in the next few years, the picture flips. Overbuilt supply means lower prices. If the providers overshoot, then cloud rates soften and less expensive data center space becomes available for enterprises that need it, including capacity for your own AI ambitions at prices that would be unthinkable today. The overbuilding that will burn the hyperscalers’ investors will create a bargain for their customers.

The playbook I recommend is the one I’ve always recommended. Architect for the cloud on your own terms, stay out of long-term capacity commitments you can’t justify with current demand, and let the providers take the utilization risk. They’re betting hundreds of billions that the demand curve keeps climbing. You don’t have to make the same bet to benefit. The oversupply, if it comes, will find you, and at a price you’ll like a lot better than today’s.

The best Python yet isn’t just faster than before. It’s also smarter at telling you what’s wrong, better at letting you profile applications, and loaded with new language features to give you a better programming experience.

Top picks for Python readers on InfoWorld

The best new features in Python 3.15
Python 3.15 is now GA, and it’s the best Python yet. Get your hands on its improved JIT compilation, lazy imports, more detailed errors, and all-new profiling superpowers.

Python’s new frozendict type, demonstrated
Ever wanted to use a Python dictionary where you needed an immutable type, like a dictionary key? The new frozendict type lets you do exactly that. This video demonstrates its powers and usefulness, along with its quirks and eccentricities.

Speed-boost Python with lazy imports
If you rely on imports with slow startup times, you can quit drumming your fingers or coming up with clumsy workarounds. Python’s new lazy import feature defers the delays.

Get started with Python’s new native JIT
Although still in its early stages, Python’s native JIT is yielding bigger performance gains with each passing revision. Learn how your Python code can speed up by as much as 20% with this feature, without your needing to change anything.

More good reads and Python updates elsewhere

What we learned about Rust for CPython at the Python Language Summing 2026
Rust is becoming part of the CPython codebase, chiefly for rewriting specific components like the zlib module. This article explains how that project is going (slowly and carefully), and what its goals are.

Making np.searchsorted up to 25× faster in NumPy 2.5
A fascinating deep dive into how NumPy’s binary search algorithm got a major performance boost. The bigger the array, the bigger the payoffs, especially when working with inputs bigger than your L2 cache.

Lifeguard: Static analysis for lazy imports in Python
Lazy imports are a great new feature, but they behave strangely in some corner-case scenarios. This tool scans codebases to determine if your code is fully lazy-import safe.

Polars 2.0 is here
This top-class dataframes library for Python just notched a major point release, which brings A-list support for SQL queries and tons of performance improvements overall.

Current security procedures for training AI models are inadequate, hundreds of AI researchers have warned governments and the AI community. They are calling for tougher rules and the establishment of a new international body overseeing best practice for AI development.

In an open letter the AI specialists — 487, at time of publication, including many senior academics — called for more AI safety research and greater emphasis on containment technologies.

“Strong sandboxing mechanisms including air-gapping (disconnecting from the internet) should be used to provide high-assurance containment of cyber-capable AI models,” say the signatories, who include such luminaries as Geoffrey Hinton and Yoshua Bengio.

The experts said that a new international body, to be set up in consultation with governments and a wide range of AI and security specialists, could set new safety standards but also act as an organization to which containment failures could be reported, improving transparency for learning and accountability purposes.

The scientists’ demands go further than some recent calls for greater regulation of AI. Earlier this week, Microsoft president Brad Smith said AI is less regulated than washing machines or milk, although he made no firm proposals to rectify the situation. And the UK parliament is looking at ways to improve AI security, although any moves will be hampered by disagreement among AI businesses. 

Hinton and Bengio are no strangers to this kind of scientist-led initiative. In October last year, they signed an open letter warning of the dangers of developing super-intelligent AI. The letter appears not to have affected AI’s breakneck development; it remains to be seen whether AI players in boardrooms will heed the warning.

This article first appeared on CSO.

Although the Jev model rolled out last month by TypeSafe claims to have significant advantages over traditional LLMs, a security report published Wednesday argued that its streamlined approach makes it more vulnerable to some kinds of attack, compared to traditional LLMs.  

“In some cases, [Jev] is even more vulnerable to attacks, with both adversarial text attacks and prompt injection being able to disrupt the model’s outputs, resulting in incorrect and potentially devastating actions,” said the blog post from researchers at HiddenLayer. 

TypeSafe did not respond to multiple requests for comment. 

LLM, or something else?

There seems to be debate about whether Jev is technically a large language model (LLM), with TypeSafe suggesting it is not, but HiddenLayer saying that it appears to be one. TypeSafe has even coined a name for the category: System One, which TypeSafe described as “a new class of frontier models built to make fast, structured decisions that software can use directly.” Jev is the first—and thus far, only—named product categorized as System One.

Jev is a streamlined model designed to function machine-to-machine. Its approach allows it to perform tasks faster and to use fewer tokens. But Kasimir Schulz, the director of security research at HiddenLayer, the blog’s co-author, said that the accelerated approach robs Jev of some of the checks and balances that exist in traditional LLMs. This means that Jev can fall for some attacker tricks that current LLMs typically detect and refuse, he said in an interview. 

Despite this, “Jev is great. You should use it. It has a lot faster response time,” he said, with the caveat “it doesn’t have all of the protections” seen in traditional LLMs, so some attacks on it succeed that should have failed. 

“TokenBreak, for example, normally does not work with larger LLMs, but Jev is vulnerable to it out of the box,” Schulz said. 

Although simply inserting characters in front of important words, as in the original TokenBreak attack, did not yield much, HiddenLayer’s blog noted, “we did notice that increasing the number of perturbations and improving their targeting led to much higher attack success rates.”

But although traditional LLMs are typically able to see through such attacks, it pointed out, “System One models appear to be vulnerable. As a result, this class of decoder should be treated with caution, given that they are susceptible to both autoregressive LLM attacks and text classifier attacks, providing potential adversaries with greater optionality.”

The post cited some examples: 

“On a simulated checkout page, an attacker-controlled advertisement caused the browser agent to click away from the user’s purchase [and respond to the ad] despite instructions to treat page text as untrusted,” it said. “In a separate classification test, targeted TokenBreak-style changes lowered toxicity scores for prompts both models had initially flagged.”

The post argued that multiple risks are therefore associated with Jev. 

“A browser agent may immediately click a selected element. A moderation system may allow an input whose toxicity score falls below a threshold. A routing system may send a request to a different tool or workflow. Each of these turns a model judgment into an operational decision, and therefore, risk,” the post said. “When evaluating System One models, test those decisions in the application where they will be used. Include untrusted webpages, misleading task-related text, and modified inputs that preserve their meaning while changing their form. Monitor the selected actions and scores and put independent checks around outcomes that matter. Keep in mind that, under the hood, these are still language models at heart.”

Analysts agreed with both the report’s methodology and its technical conclusions, while also pointing out that a security vendor concluding that a new approach is not secure is somewhat self-serving.

Philip Harris, an IDC research director, observed that the methodology described in the blog post “is sound, and consistent with established AI red-teaming practice: building a controlled test environment and probing for adversarial manipulation and injection is exactly the right approach.”

But Gartner VP Analyst Nader Henein added that Jev, which was introduced on Sept. 15, is so new that he thinks some of the flaw reports were premature.

“Jev will go through the same maturity process as do all other models, including susceptibility to seemingly rudimentary manipulation attempts,” Henein said. “This model was only released last month, so being surprised that it has issues is similar to being surprised when your baby drools.”

However, Frank Dickson, principal analyst at Dickson Research, noted that the same attributes that make Jev so attractive also expose it to riskier behavior.

“Jev can only choose from options the developer puts on the menu,” he said. “It limits attack paths. However, if ‘click any element on the page’ is on the menu, the attacker’s ad is on the menu. That is an architecture decision, and the buyer makes it.”

He pointed out, “Jev makes AI decisions faster and cheaper, which also makes the wrong decisions faster and cheaper. Speed is a feature. It is not a security control.”

Independent technology consultant Steven Eric Fisher agreed.

“Constraining the format of a decision does not necessarily constrain the correctness, trustworthiness, or consequences of that decision,” he said, noting, “the simulated checkout scenario [in the post] illustrates how an agent can be redirected from an authorized task by information introduced through a less-trusted component of its operating environment. The fact that the agent was explicitly instructed not to trust page content, yet still responded to the malicious advertisement, is particularly relevant.”

ServiceNow is giving its AI Control Tower new features to make AI agents more governable — and a new name, Super Intelligence Control Tower (SICT), to please the US President. It is also updating EmployeeWorks to make building AI agents easier.

AI Passport, a new component of SICT, gives every agent, whether from ServiceNow or a third party, a verifiable identity, and provides runtime control over its activities.

As enterprises scale autonomous agents from pilots to production, they are facing new challenges, said Nenshad Bardoliwalla, SVP of AI product management at ServiceNow: “If companies can’t identify which agents are running, what they are doing, and what systems they can access, then scaling quickly becomes a risk.”

An AI Passport is a cryptographically signed credential for AI agents that is checked at runtime to verify the scope authorized by the enterprise. When an AI agent stays within its passport scope, it can operate freely, but if it tries to deviate, defined actions are enforced. These can include redirecting, restricting, or reconnecting the agent with proper context, or even triggering a kill switch. All actions are audited so agent activity can be tracked.

It is built on open specifications, so any governance product, identity provider, or enforcement point can issue and verify credentials for their own and third-party AI agents, and those credentials are verifiable at every step in multi-agent workflows.

A bouncer at every door

This is a real step forward, said Frank Dickson, principal analyst at Dickson Research. “Most agent governance today is a security camera. It records what happened so someone can review the tape later. AI Passport is a bouncer at every door.”

The controls extend beyond ServiceNow’s own agents, he said: “For third-party agents, the passport replaces the agent’s own ‘claims’ about its permissions,” he said. “Taking an agent’s word for what it is allowed to do is an Achilles’ heel of agentic AI.”

And, he said, “A passport is only as trustworthy as the office that issues it. Here, the issuing office is ServiceNow’s CMDB, its GRC policies, and its workflow approvals. If that data is stale, the passport is stale. Credit ServiceNow for building on open specifications, but an open spec matters only when others adopt it. Nvidia is the launch partner, and ServiceNow says that enforcement implementation is still being built.”

In addition to AI Passport, ServiceNow has further beefed up its governance tools with a number of other features, including shadow-AI detection to locate unapproved agents on the network; more than 400 connectors to enable AI discovery across platforms and vendors; access mapping; and continuous enterprise AI observability.

It also announced cost governance; “value intelligence” that connects consumption, cost, quality, and “realized user value” to help teams optimize their AI use; AI cost management as part of ServiceNow IT Asset Management, which integrates with the Control Tower; and policy enforcement.

AI Passport, Shadow AI detection, and AI Cost Management are expected to be available by year end.

EmployeeWorks enhancements

The third generation of ServiceNow EmployeeWorks now lets employees add automations to the autonomous AI personal assistants they build. ToolSmith is a new agentic developer environment that takes tool building “from days to minutes,” the company said.

What companies have been trying to do, said Bhavin Shah, SVP of ServiceNow’s employee experience group, “is to give developers a way to build, but in a way that’s governed, that allows them to stay within the guardrails and the controls that that are required in order to do the kinds of safe but deep and capable work that they want for their constituents inside the company.”

ToolSmith helps address that problem. It’s a vibe-coding environment with which developers can build automations for ServiceNow EmployeeWorks AI assistants by describing what they need in natural language. ServiceNow said ToolSmith was trained on over 75,000 APIs and optimized for reliability and token efficiency. Developers can test and refine its output using the same conversational interface.

ServiceNow said that ToolSmith also identifies what to build next, scanning logs “to identify opportunities to fix, improve, or invent the next best workflow.”

Non-coding employees, on the other hand, can build new Productivity Assistants to perform contextual or persona-based work including long-running tasks, the company said. There are also pre-built assistants available, beginning with several for HR service delivery.

EmployeeWorks itself includes two assistants out of the box: a research assistant that can scan internal and external sources for answers, based on the user’s role, and a calendaring assistant that, ServiceNow said, “goes beyond typical calendar booking solutions by orchestrating nuanced requests like scheduling quarterly one-on-ones with an entire team on days that minimize disruption to project work or finding the least hectic day to bring together a team for a full day workshop. “

To automate repetitive tasks, Productivity Routines run proactively in the background, repeating routine steps and providing deliverables without human intervention. Employees just have to describe what they want to automate, select the necessary tools, and deploy the routine.

“The principle is right,” Dickson said. “The people closest to the work understand the problem best.”

But, he added, “the guardrails are only as good as the decisions behind them. Productivity Routines, by ServiceNow’s description, run in the background without human intervention. That is unsupervised work, and someone should own it.”

All of these EmployeeWorks enhancements are in controlled availability now.

Bottom line

Melody Brue, analyst in residence at Moor Insights & Strategy, said the announcements are a sign that ServiceNow is extending its existing security and workflow controls into a broader role in governing agent actions across systems.

“AI Passport makes identity and authorized scope verifiable, Control Tower provides oversight and enforcement, and ToolSmith expands the tools and connectors through which agents can act within enterprise guardrails,” she said, adding that with CEO Bill McDermott’s recent positioning of ServiceNow as a security company, “This suggests an ambition to become a control point for enterprise autonomy.”

But, she said, “What matters now is how consistently ServiceNow can enforce boundaries and verify outcomes across the systems agents actually touch.”

Dickson, too, has concerns.

“ServiceNow says Control Tower tracks spending by user, department, and runtime, and ties that spend to quality and value. The brake is another matter,” he noted. “The graduated alert, throttle, and block enforcement is described in future tense, as is the AI Cost Management integration, which is expected by year end.”

However, “a meter you can watch is not a brake,” he said. “A Productivity Routine that runs every morning is a standing purchase order. Someone should sign it.”

Give every agent and every routine a named owner and a budget before it goes live, he advised, and ask ServiceNow how assists are counted for background routines and whether hard caps exist today. Turn on throttling the day it ships, and reconcile its dashboards against your own invoices.

But despite these concerns, he said, ServiceNow has the right idea. “An agent should carry its permissions, its manager, and its budget wherever it goes. But until the brakes ship, that budget is a decision a person still has to make.”

This article first appeared on CIO.