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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Using vibe coding to scratch an itch has many of the same issues as using low-code and no-code development tools. That’s not surprising. Putting together something quickly to solve a specific problem lacks the level of discipline of software engineering, introducing inefficiencies that come from not following architectural guidelines and policies.

I recently reviewed the AI-generated code I used to quickly build a PDF archive of some HTML-formatted content. The program used common libraries in unusual ways, often combining three or more libraries when all the necessary calls were in one, with a program flow that was hard to understand in places. The result was at best unmaintainable. The only way it was acceptable was that I’d thrown it together in an hour to solve a specific problem, and once I’d built that local PDF archive I could simply throw the program away.

But what if your sloppy AI-generated code was needed by an entire department, or had become part of an essential business process? The risk is that something, somewhere, would inevitably change, and that essential business process would fail, with no practical way of fixing the code. The risk only compounds when the author has left their role and there is no one left who remembers or understands the initial prompts that produced the code.

Adding AI-powered coding tools to products and platforms is risky. But they are too useful to ignore. Like low-code tools, AI tools put coding in the hands of the people who understand the business problems and helps them automate processes on their own schedule.

What’s needed is a way to improve the harnesses used by the coding agents, taking concepts from specification-driven development and using them to build guardrails and standards into the code they produce, with the aim of building code that’s maintainable.

Introducing Rayfin Fabric Apps

Microsoft Fabric is intended to be where all your businesses operational data lives, offering a way to query and explore data at scale. It builds on a mix of big data and data warehousing concepts, using open formats for storage and data mirroring tools to bring data from existing applications into its data lakehouses, as well as supporting streamed data.

Microsoft Fabric allows you to build and deploy your own agents inside the platform to work with your data. However, in many cases, you will need a more focused approach to exploring and using defined subsets of data. The recent addition of Fabric Apps to the platform allows business analysts to deliver applications that use data in Microsoft Fabric to provide essential business insights.

Fabric Apps are built on top of Rayfin, a new TypeScript-based SDK that is designed to work with both humans, via CLI, and AI agents. A partnership with Replit allows Microsoft Fabric users to build apps using Rayfin and AI assistance in Replit and deploy them directly into Microsoft Fabric. Here Replit support is best thought of as a tool for business users, whereas developers can use tools like the GitHub Copilot CLI and Visual Studio Code, which let you mix traditional and AI-supported development processes.

The intent is to provide the tooling that business users need to create data-powered applications inside Fabric, making application development part of the process of exploring data. Rayfin apps can be connected to raw data or draw on semantic models built with tools like Power BI, using DAX for analytics rather than SQL or KQL queries.

Data app development tools for coders and non-coders

The key to this approach is the open-source Rayfin SDK, which offers a way to build out the necessary definitions for data models that can then be used by agent-based tooling. The SDK allows you to set up access to specific models, along with the necessary permissions, before users begin to build on them. Rayfin turns those models into GraphQL endpoints, with TypeScript clients sitting between them and the data stored in Microsoft Fabric — adding an extra layer of protection as the APIs are automatically type safe.

Building a Rayfin-powered Fabric App starts with using Rayfin to define a data structure with decorators that apply types to the data you want to use in your application and defining each table as a class. For example, a table of employee names and contact details would be exposed as an entity that contains an employee class, with decorators that create ID number, name, and address strings, all using structures held in the @microsoft/rayfin-core definitions. Other options allow you to begin to define access controls around the data, so that it can be used only by authenticated users with the correct group privileges.

This is the most important part of any Rayfin-based application development, as it’s here that you’re setting up the guardrails for ongoing user-led development. You’re not limited to one basic application scaffold, either, as there are a series of different templates available to help you get started, from a ready-to-use “to-do” application that illustrates the structure of a complete Rayfin application, to applications that use Microsoft Fabric’s authentication framework to control access to data.

Using Rayfin from the command line

Microsoft provides a process for getting Rayfin scaffolding in place, starting with setting up an application template, then logging in to Microsoft Fabric via Entra ID. Once you’ve completed these steps you can run Rayfin’s development loop to create a runtime and configure the Microsoft Fabric back end, before deploying the base application scaffolding. You don’t need to do this manually; Microsoft’s documentation includes a ready-to-run prompt for your coding agents.

You can now define your data entities. These are placed in a specific directory within the application scaffolding, with separate TypeScript definitions for each class. While you can put all your definitions in a single file, having separate files for each entity makes more sense, as it keeps applications maintainable. Once you’ve added the entities you plan to use, you can rebuild the scaffolding and redeploy, ready for testing.

Usefully this technique lets you separate the back end and front end, ensuring that back-end services and entity definitions run in Microsoft Fabric using its authentication and security framework, with application code running on development hardware (and eventually on separate servers or as part of a local application). This is where you will develop Rayfin functions, TypeScript applications that access and process the defined entities, with predefined typed connectors to work with data already stored in Microsoft Fabric. Rayfin functions can call any HTTPS API, allowing you to mix Microsoft Fabric data with information from any other line-of-business application or service. They’re also where you put the business logic for any Fabric application.

Structuring apps to be coded by machines and managed by humans

Building with the Rayfin SDK produces a predictable application structure with YAML configurations and TypeScript code. That code can be tested locally against a Microsoft Fabric back end. When ready to be deployed and shared, it can be uploaded to Microsoft Fabric, which hosts both the Rayfin function code and any front-end assets. Apps will require Microsoft Fabric capacity to work, and can be accessed from inside the Microsoft Fabric portal, though users can access apps via published endpoints through their browsers.

Rayfin is one of the first examples of a new generation of SDKs and development tools that support both humans and agents. The human-readable Rayfin documentation is paired with an identical set of markdown files, ready for use by any agent working on Rayfin code. Microsoft’s partnership with Replit provides a coding agent to build Rayfin applications and a rendering canvas with familiar Power BI features, providing a place for non-coding business users to experiment with Fabric Apps using AI.

The strict structure Rayfin imposes on Fabric Apps aims to bridge the gap between AI-powered coding and traditional enterprise application development. By putting all the components of an application in a rigidly-defined environment, Rayfin helps ensure that AI-generated code remains secure, compliant, human readable, and human maintainable. Business users can quickly put together Fabric Apps with Rayfin and Replit. Then, if a Fabric App proves to have utility outside a narrow group of users, it can be transferred to the enterprise’s development team for further refinement and long-term operations.

Career paths for software developers have always been a touch problematic. 

Early on, you started out as a junior developer, and maybe there were ladder rungs that got you raises until you became a senior developer. But there was typically a ceiling to that, leaving you with little choice but to move into a management position if you wanted to continue to advance and make more money.

On top of that, promoting developers to be managers is often less than optimal for the company or the developer in the long run. Many of the qualities that make a good developer don’t always translate into being a good people manager. And certainly, many software developers want to continue to write code and not have to worry about the bureaucracy and paperwork that often comes with management. Plus, it hardly seems optimal to take your best coders and tell them to stop coding. 

The industry dealt with this by creating technical positions such as “Architect” and “Staff Developer” and “Chief Scientist.” That works well, but then these positions often lead to doing less programming and attending more meetings.

No matter what the title or role, the simple fact of the matter is that the more senior you get, the more you’ll be dealing with other people. “Tech Leads” have to supervise the work of other developers. Maybe you aren’t responsible for managing their careers or writing their performance evaluations, but you are responsible for making sure their code is up to snuff.

You’re the boss

It will come as no surprise that agentic coding changes this entire dynamic.

We don’t write much code anymore. And we are all too aware that coding agents aren’t perfect. Like humans, they make bad decisions, write bugs, and do things they weren’t asked to do. They need clear instructions, wise guidance, and the right working environment. You need to keep an eye on your agents to make sure they are on track and headed in the right direction. 

One might even say that you need to, ahem, “manage” your coding agents. 

And in that sense, we are all managers now. “A coding agent is most useful when you treat it more like an employee than an autocomplete tool,” says Jim Bourke, founder and CEO of Zide Software, producer of a development tool that treats developers more like managers than coders. “It needs a clear assignment, the right context, a safe place to work, checkpoints, and a way to evaluate the result.”

How you deal with coding agents isn’t all that different from how you would deal with a real live developer. You have an array of choices to make about who/what will write the code, what they will be building, and when their work can be called finished. You have to guide them, give them clear instructions, review their code, and decide when that code is ready to be checked in. 

Career twists and turns

All of that should sound pretty familiar to managers and individual contributors alike. In fact, one might argue that this is the job now — managing coding agents. Even the most junior of developers will be managing a “developer” in the future.

What does that mean for the career path of a person who manages coding agents all day? I hate to say it, but I don’t know and I don’t think anyone can say for sure. The set of skills required to successfully lead a “team of coding agents” compared to those needed to manage a team of real live people overlap, but they are not congruent. 

It may be that managing coding agents is an innate talent, leading to some junior developers suddenly outproducing seniors. Or maybe it will be a skill that needs to be carefully nurtured and grown under the mentorship of an experienced manager. It’s hard to say. And how the career ladder will look going forward, and exactly what skills will be rewarded, are questions I don’t think we can answer right now.

Everything is so new and changing so fast that it’s all a blur at this point. 

Wherever we may be headed, I don’t envy the person who will have to rewrite all those job descriptions.

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

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

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

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

Document like a construction specification

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

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

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

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

Encode non-functional requirements as automated tests

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

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

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

Requirements for stakeholders and AI

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

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

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

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

Build governance into the specs

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

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

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

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

Observability and testing first

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

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

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

Package and evolve the standards

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

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

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

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

A swarm of hundreds of OpenAI agents uploaded “malicious packages” to RubyGems and tried to steal API keys, the Ruby community gem hosting service revealed Friday.

OpenAI confirmed part of the disclosure, saying, “our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. We’ll continue to investigate as part of our broader review of agent activity during training and evaluation.”

The agents’ goals were unclear, as was whether they engaged in the swarming activity for research, and even whether they were explicitly sent by OpenAI staffers, but an analysis published by RubyGems strongly suggests malicious intent. 

“Once the AIs got arbitrary RCE on the build environment, they would sometimes use the build environment to attempt to steal other users’ API keys, though we are unsure if they succeeded or not,” the RubyGems post said. “The agents clearly regarded what they were doing as hacking. Agents used file names like hack[.]rb, evil[.]rb, inject[.]rb, exploit[.]rb, and ssrf[.]rb. SSRF stands for ‘Server-Side Request Forgery,’ a type of security vulnerability. They also dubbed packages conspicuous titles like pwnp999, exfiltestwand3, hacksvn1778554764 and lambproxyhackabcxyz. Comments such as “# malicious probe” or “#hack” are littered across the campaign.”

The post also said that the agents attempted to trick defensive systems.

“At some points, the agents attempted to be covert. We found multiple packages that would disarm themselves to hide their payload in the next version,” the post said. “They uploaded one package with the comment ‘# disable evil in the next version and bump version,’ which after execution would modify the package to remove the malicious code initially inserted.”

OpenAI should be accountable

Analysts and consultants said the attack was concerning because if such efforts happen often enough, it could slow down security operations center (SOC) responses.

Nader Henein, a Gartner VP analyst, said he was highly concerned about an upcoming bot swarm trend. 

“What we know is that this is the kind of standard attack, now AI-augmented, that will become commonplace over the coming months,” Henein said. “It’s less so a rogue agent, more so an attacker, potentially using compromised credentials, weaponizing an agent swarm, in the same way that attackers used compromised endpoints to mount DDoS attacks for the better part of the last decade. The difference here is the fact that these are not individually compromised bots. OpenAI’s guardrails should have not allowed this to happen.”

Frank Dickson, principal analyst at Dickson Research, added, “OpenAI needs to be held accountable. They seem to want to create ‘Dr. Frankenstein’s monster,’ but don’t seem to want to accept blame for the outcomes. OpenAI hasn’t denied its agents used RubyGems. It has disputed the word ‘malicious’ and called the activity ‘benign,’ while separately acknowledging that, in that same stretch of weeks, its agents escalated to cluster-admin access at Hugging Face and compromised accounts at four other third-party services. Those two characterizations are hard to square. The behavior is still unacceptable.”

However Erik Avakian, technical counselor at Info-Tech Research Group, stressed that it’s not necessarily the case that OpenAI launched these agents with explicit instructions. The agents might have easily charted this destructive path all on their own.

The OpenAI agents “absolutely could have acted autonomously. We’ve already seen that capable agents can pursue various unexpected paths to accomplish a task when they have enough autonomy and access,” he said. “A human may have authorized the evaluation or given the agents access to tools, but that doesn’t mean a human approved every action they subsequently took.”

Could delay SOC responses

Dickson added that he fears the ultimate cybersecurity risk is that SOC staffers see so many of these attacks that they start to experience alert fatigue.

“If the vendor whose agents did this is the one downgrading the language, a SOC analyst reading headlines instead of the underlying report has every reason to underreact,” Dickson said. “Security operations aren’t fit for purpose if they run on the assumption that an AI agent label makes an intrusion less real. A stolen API key or a remote code execution path behaves identically whether the actor is a ransomware crew or an unsupervised model chasing a reward signal.”

Mike Wilkes, enterprise CISO at Aikido Security, also noted that the fact that the agents self-identified as OpenAI should mean nothing, as all agents can persuasively pretend to be representing anyone, especially if they think it will slow down a response, even for a brief period. 

“A User-Agent string is a nametag written by the visitor, not a passport,” he said. “If SOC tooling begins suppressing alerts because traffic claims to be an OpenAI, Anthropic, Google or other AI agent, attackers will adopt those identities immediately if they haven’t already.”

Thus, he said, “if a human researcher or employee delegates authority to an autonomous agent, there should be a verifiable chain showing who delegated that authority, which organization they represent, what agent was authorized, what scope it was given, and for what period of time.”

Plan for similar attacks

Consultant Brian Levine, executive director of FormerGov, encouraged CISOs to anticipate more such attacks and plan accordingly.

“Organizations that depend on open source, which is nearly all of them, should assume registries are an active battleground [and should] rotate and scope API keys tightly, monitor for anomalous package publishing and credential access, and pin and verify dependencies rather than trusting a name,” he said. “The economics have shifted. Automation lets an attacker try thousands of variations cheaply, so defenders have to make the payoff of any single success as small as possible.”

Justin Greis, CEO of consulting firm Acceligence, agreed. 

“If legitimate AI research activity increasingly generates behavior that looks like hostile scanning, exploitation, credential access or persistence, SOC teams can become conditioned to treat those signals as noise,” Greis said. “Attackers will understand that very quickly. The dangerous phrase becomes ‘that is probably just an AI agent.’”

This article originally appeared on CSOonline.

Attackers have opened a new front in their war on software developers: Vite servers, which they are probing for sensitive data including cloud credentials, infrastructure configuration and environment files.

Vite was created as a build tool for Vue, a JavaScript framework for building user interfaces and web applications, but has now become a widely used development server and build tool across the JavaScript ecosystem.

F5 Labs reported that attackers sent more than 32,000 attempts to scan exposed Vite servers on its honeypot network, grouped into 807 attacks (or sessions), during August, a sharp increase from just 1,732 attempts over the previous three months.

“Rather than target a single file, the scanning fleet systematically cycled through extensive wordlists of environment files, AWS keys, Azure tokens, and Infrastructure-as-Code state files,” F5 threat researcher, Adam Metcalfe-Pearce, wrote in a blog post on F5’s blog.

F5 noted that Vite normally binds to localhost, but developers can expose it through the “–host” option, server configuration, container port mappings or other deployment mistakes.

Scans targeted a file-access bypass

The activity targeted a recently disclosed vulnerability that allows unauthenticated attackers to bypass Vite’s file-access restriction and retrieve files from the host system. Tracked as CVE-2026-39364, the flaw allows attackers to bypass the “server.fs.deny” deny-list protection used to prevent access to sensitive files.

“When specific parameters such as ?raw, ?import&raw, or ?import&url&inline are appended to a request, the server fails to enforce deny-list filtering and serves the target file with an HTTP 200 response,” Metcalfe-Pearce wrote.

Some requests also used double-encoded path traversal, which F5 said indicated an attempt to evade security controls such as reverse proxies and web application firewalls (WAFs).

Assigned a severity rating of CVSS 8.2 ,the flaw affects Vite 7.1.0 through versions before 7.3.2 and Vite 8 versions before 8.0.5.

F5 recommended updating Vite to a patched version, rotating potentially exposed secrets, ensuring development servers do not bind to external interfaces, and auditing Docker, Kubernetes and cloud configurations so development ports are not exposed to the public internet.

The blog also shared the curated directory and credential wordlists the attackers used during these attacks.

Vite was part of a broader scanning pattern

F5 also observed attackers combining CVE-2026-39364 with older Vite file access vulnerabilities, including CVE-2025-30208, CVE-2025-31125 and CVE-2024-45811. The same scanning infrastructure also probed for a Next.js middleware bypass, indicating that the activity is not confined to a single framework.

In its blog post the company also noted that, apart from CVE-2025-31125, none of these CVEs are yet listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog.

While F5 saw a sharp increase in August in attacks on recently uncovered flaws in Vite, it didn’t make the top three CVEs attacked on the company’s honeypots, all of them much older. CVE-2017-9841, an almost decade-old critical remote code execution flaw in PHPUnit, remained top of the table with 4,201 recorded attacks, followed by CVE-2018-14028, a failure to verify WordPress plugins as valid ZIP files (4,102), and CVE-2018-20062, a ThinkPHP remote code execution in NoneCms (3,482).

Java Development Kit 27, an Oracle-driven, planned update to standard Java, is now generally available. This latest update to standard Java has features ranging from making the Garbage-First (G1) garbage collector the default collector and adding structured concurrency to simplify concurrent programming.

Overall, there are nine features listed on what is described as a reference implementation of JDK 27. The first five features include making G1 the default garbage collector, post-quantum hybrid key exchange for TLS 1.3, lazy constants, structured concurrency, and primitive types in patterns, instanceof, and switch. The next four include compact object headers, JFR (JDK Flight Recorder) in-process data redaction, a vector API, and PEM (Privacy-Enhanced Mail) encodings for cryptographic objects.

JDK 27 can be downloaded at jdk.java.net.

With JDK 27, G1 becomes the default garbage collector in all environments, rather than just in server environments. Goals are to ensure that the HotSpot JVM will always select G1 and that performance including throughput, latency, memory footprint, and startup time does not degrade significantly.

With post-quantum hybrid key exchange for TLS 1.3, the goal is to enhance the security of Java applications that require secure network communication by implementing hybrid key exchange algorithms. Such algorithms defend against future quantum computing attacks by combining a quantum-resistant algorithm with a traditional algorithm.

Lazy constants introduces an API for objects that hold unmodifiable data. Lazy constants are treated as true constants by the JVM, enabling the same performance optimizations that are enabled by declaring a field final. Compared to final fields, however, lazy constants offer greater flexibility in the timing of their initialization. This feature is in a third preview.

The goal of primitive types in patterns, instanceof, and switch is to enhance pattern matching by allowing primitive types in all pattern contexts, and to extend instanceof and switch to work with all primitive types. This feature is in a fifth preview.

Structured concurrency simplifies concurrent programming by introducing an API that treats groups of related tasks running in different threads as single units of work. Goals include streamlining error handling and cancellation, improving reliability, and enhancing observability. Structured concurrency is in its seventh preview.

JDK 27 makes compact object headers the default object header layout in the HotSpot JVM. Compact object headers reduce object headers from 96 bits down to 64 bits on 64-bit architectures, reducing heap size, improving deployment density, and increasing data locality.

JFR data in-process redaction allows users to redact command-line arguments and the initial values of environment variables and system properties in JFR recordings. JFR recording files may contain events that include sensitive data, such as secrets in command-line arguments, access tokens in environment variables, and passwords in system properties. This data is (optionally) redacted before it leaves the process, so that sensitive information does not leak.

The vector API introduces an API to express vector computations that reliably compile at run time to optimal vector instructions on supported CPUs, thus achieving better performance than equivalent scalar computations. This is an incubating API in its 12th incubation.

PEM encodings of cryptographic objects introduces an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists in the PEM transport format, and for decoding from PEM back into objects. This is a preview API.

JDK 27 is a short-term feature release (non-LTS) that will receive six months of support from Oracle. Its predecessor, JDK 26, also a short-term release, became generally available on March 17.

Steve Yegge is not the shy and retiring type, so when he wants recommendations on how others are managing 10 to 20 (or more) coding agents, he posts the question on X. Specifically, he’s looking for an IDE because “I use Emacs, and I wouldn’t wish it on you.”

The replies (600 and counting) offer plenty of alternatives: Herdr, cmux, Conductor, the Claude and Codex desktop apps, and an impressive assortment of homemade software. For anyone hoping the industry had settled on a sensible way to work with agents, clearly we haven’t. Hence, Yegge’s question.

The most interesting data hidden in the replies, however, isn’t which IDE or IDE stand-in developers are using. Rather, it’s what developers have added to these tools to accommodate the technology’s shortcomings. These include shortcuts to find the agent that needs a decision, ways to recover an earlier conversation, and groupings that explain how a task fits into a project. In other words, despite the incredible intelligence we now have to help us write code, developers are still struggling with the simple task of automating their remembrance of what they asked AI to do.

We seem to have made it easier to generate work without making it easier to absorb and finish work.

Everyone’s building a workspace switcher

Mark Jaquith uses Herdr with a custom interface to jump to an agent needing his attention. Kai Backman has been working on a keyboard shortcut to take him to the “next most relevant place to take action.” Jacob Voytko built a workspace switcher that groups tasks within milestones and lets him jump to the corresponding tickets and pull requests. He wanted a visual sense of where the work stood, rather than an unstructured list. Another respondent, Basil, built a manager that helps him “find the session where we did x.”

Of course, developers have always customized their tools. Emacs users alone could supply scads of evidence. But, again, it’s not really about the fact that developers are tweaking their tools, but why. So much of the tweaking is intended to help cohere the developer’s intentions with the work that’s happening in several places at once. They’re not asking for better AI: They’re asking for AI to help them express their humanity, as it were.

The work comes back

Consider a developer who asks one agent to fix a bug, another to investigate a performance problem, and a third to update a dependency. While the agents work, she can do something else, which is what makes LLM-driven development so appealing—at least, until the agents return.

None of those agents does work that is fully isolated from the rest of the system. Think about it: The bug fix changes behavior someone may depend on. OK … we can address that! But wait, now we have the performance investigation offering three options, each with different costs. Hmm. Hold on a minute while I tackle this … except the dependency update isn’t waiting. It passes its tests, but the agent has also rewritten a configuration file. Better check that!

As this simple example shows, before the developer can move forward on any decision, she first needs to recover what she asked for, what the agent discovered, and what remains uncertain. And, no, adding more agents doesn’t solve the problem. It could instead compound the problem.

The agents may have saved hours. Hurray! But a list of completed sessions doesn’t tell the developer where to begin. Nor does a green test result answer the question of whether the change belongs in the application.

This is why the number of agents running tells us so little, even if it makes us feel cool. I mean, what are those agents doing, anyway? Yegge’s commenters provide some clues. For example, Anton describes using 30 terminal tabs with one active agent per project, so as to keep their work from overlapping. Jerry Combs says he generally keeps no more than three conversations going, with agents managing their own subagents as needed. Even those three conversations are difficult enough to follow.

Both approaches can make sense. The demands depend on how independently the work can proceed and how much human judgment it requires along the way. A developer with 20 agents may have fewer decisions to make than someone with three.

Gergely Orosz recently listed several observations worth considering together: developers spending less time in IDEs, code reviews becoming theater, and people working more despite AI’s productivity promises. His observations don’t establish that agent tools cause overwork or superficial review. They do make it worth asking whether we’re shifting effort into places our productivity stories neglect. Watching an agent produce a change is satisfying, but spending the afternoon reconstructing why six changes were made is less so.

But that work, however unsatisfying, is necessary if those changes are going to be understood and maintained.

Teach the tools to wait

Some of the plumbing already exists to alleviate these issues. For example, Herdr tracks agents as working, blocked, or idle and carries those states into its tabs and workspaces; cmux offers notifications and a shortcut to the workspace with the most recent unread notification. These are useful starts, but they do highlight just how much remains to be done. After all, the most recent notification may concern the least important task, and an agent asking a question may be perfectly capable of waiting while the developer finishes something else.

The next improvement should help developers make those distinctions. A task should retain its original purpose, the relevant decisions, and the evidence supporting its result. When it needs a person, it should explain the decision required and what happens if that decision waits. A summary can help, but it must lead back to the actual changes and test results. Otherwise, we’ve made it easier to approve work without understanding it.

Again, the best tools for agentic AI will be the ones that bring the human back into the loop and provide the information necessary to make decisions.

I’d like a tool that can tell me a task is ready for review because the requested behavior has been demonstrated, while keeping a separate, less urgent question out of my way. I’d also like it to remember that I rejected an approach yesterday, so I don’t have to discover it again in today’s proposed fix. Whether that tool calls itself an IDE seems secondary. Google introduced Antigravity 2.0 as a standalone agent application without an IDE, while recommending that developers use it alongside their IDE of choice. In other words, the editor still has a job, even when it is no longer where every task begins.

In 2022, I wrote about cloud convenience and the tendency to misunderstand what developers want from their tools. They have work to do and want fewer obstacles to doing it. We should apply that same standard to agentic development across the whole task, including the effort of returning to it.

Not that we can put all the onus on AI and its tools. Teams have a part to play here. If every task is urgent, the tool has nothing useful to prioritize. If nobody defines what counts as finished, the tool can only report that an agent stopped. Agreeing on those things and limiting the work that needs simultaneous human decisions will do more than adding another status badge.

Yegge’s readers are already building pieces of this future, one shortcut and homemade workspace at a time. The vendor opportunity is to make that convenience available without requiring everyone to maintain a side project. Give developers more work they can confidently put behind them and fewer conversations they need to keep alive in their heads.

Yet another security vulnerability has been discovered in GitLab infrastructure, this one a perfect 10 in severity.

CVE-2026-85706, the second flaw GitLab has disclosed in just a month, is a maximum-severity vulnerability that allows attackers to read arbitrary files in a single HTTP request. The path traversal flaw results from improper confinement and lack of authentication enforcement in GitLab’s repository commits API, the company reported.

Threat actors could exploit it “under certain conditions” and read arbitrary files (credentials, secrets, and other sensitive data) on vulnerable GitLab servers.

The company has fixed the vulnerability, which impacts GitLab Community Edition (CE) and Enterprise Edition (EE), and has advised customers with public-facing self-hosted GitLab instances to patch their servers immediately, or remove public access.

Experts say the flaw is alarming because GitLab’s DevSecOps platform is used by roughly 50% of the Fortune 100 and has more than 50 million estimated registered users.

“GitLab is not simply a source-code repository,” noted Safayat Moahamad, advisory director at Info-Tech Research Group. In many enterprises, it is connected to build pipelines, deployment processes, application security workflows, and other trusted systems.

As a result, unauthorized access to configuration files, secrets, or credentials on the GitLab server could “create consequences well beyond the affected instance,” he said.

Don’t wait for the normal patch cycle

GitLab has been a favorite hacker target of late: In January, it patched a high-severity flaw that allowed attackers possessing a target’s account ID to bypass two-factor authentication, and in August, it fixed a critical vulnerability that could give unauthenticated users the ability to make modifications inside code repositories or even completely delete them with a single HTTP request.

The current maximum severity bug, CVE-2026-85706, was reported through GitLab’s HackerOne bug bounty program. It affected CE and EE versions 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2.

The US Cybersecurity and Infrastructure Security Agency (CISA) has added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog, noting that this type of vulnerability is a frequent attack vector for malicious cyber actors, and particularly poses significant risks to the federal enterprise; watchTowr Intel has reported that it is already observing “in-the-wild probes.” “Based on recent GitLab vulnerabilities, we know the time until indiscriminate exploitation is likely not far away,” it warned.

This is not a vulnerability that organizations should leave for the normal patch cycle, Moahamad emphasized. “It offers an unauthenticated path to arbitrary files on a platform that frequently sits at the center of source code, build, and deployment workflows,” he said.

Enterprises should patch immediately, hunt for suspicious repository-commits API activity, and investigate whether exposed files contained credentials or secrets that may now require rotation, he advised.

Beyond patching, the watchTowr Intel team said defenders should try to identify exploitation attempts by hunting through log files for HTTP POST requests to “/api/v4/projects/{id}/repository/commits/” URIs containing “file.path” parameters.

CI/CD platforms are critical trust infrastructure 

Organizations running affected self-managed GitLab CE or EE instances should be most concerned, Moahamad noted. Risk increases where GitLab is connected to sensitive repositories, CI/CD pipelines, cloud environments, or production-deployment processes.

The information and/or access that attackers could obtain depends on what the GitLab service can read and what organizations store on the server, he explained. It could include configuration files, secrets, credentials, and other sensitive server-side data. If those files happen to contain usable tokens, keys, or credentials, an attacker could attempt to access connected infrastructure

“The flaw directly creates an unauthorized file access risk,” he said. Credential theft, lateral movement, source code exposure, and supply chain compromise are possible follow-on scenarios.

Source code and CI/CD platforms must be governed as “critical trust infrastructure,” he said. While patching remains essential, resilience will depend on knowing where platforms can be exposed, limiting what they can access, detecting abnormal API behavior, and having a tested process for investigating and rotating credentials.

David Shipley of Beauceron Security described two factors colliding to generate “maximum pain” for GitLab users.

First is the vulnerability. “It’s a 10 for a reason: Unauthenticated read access to GitLab client source code,” he said.

Second, this especially hurts because developers still have bad habits: way too much code continues to ship or is in production with embedded SSH keys, cloud secrets, tokens, and other valuable data that attackers can use to get into infrastructure, Shipley said.

“So for attackers, you’ve got the classics,” he noted: Data exfiltration and extortion, ransomware, cloud infrastructure hijacking for crypto mining, and the stealing of AI tokens and infrastructure to enable other criminal activity.

“This level of vulnerability is the code and cloud equivalent of being able to get the credit card number, expiry and security number,” Shipley said. “It opens up a world of criminal data shopping.”

The bottom line: “Get those secrets out of production code and adopt modern coding authentication best practices,” he advised.

This article originally appeared on CSOonline.

Before the rise of all-in-one frontier models, artificial intelligence and machine learning libraries tended to focus on highly specialized jobs. Even today this is still a powerful and useful approach: the more specialized the tool, the better the job it will do for its narrowly defined purpose.

One category for such tooling is computer vision: real-time analysis of video or still images. Facial recognition, OCR, motion tracking, object detection, augmented reality, and gesture detection are all common examples of computer vision jobs.

The OpenCV library is easily the most commonly used and long-lived toolkit for computer vision work. OpenCV saves you the trouble of writing from scratch the software needed for any of the above-mentioned tasks. It also gives you a handy bundle of image and video processing tools that can be used in most any project that might need them. It’s also powerful way to take existing or newly trained machine learning models for vision tasks and put them to work for you.

The basics of OpenCV

OpenCV’s original release dates back to the year 2000, when it was originally an Intel Research project. Today the project is under the stewardship of a non-profit foundation, and has gone through several major point revisions. The most recent, OpenCV 5.0, is a significant cleanup and reorganization of the toolkit, with a modernized API structure and better compatibility with the kinds of models and workflows used in machine learning today.

OpenCV is at core a collection of Apache 2-licensed C++ libraries. You can link against those libraries in your own C++ application, or work a different language and use OpenCV through an interface. Python, Java, and JavaScript are all supported, and a separate wasmCV project provides a WebAssembly interface.

OpenCV is designed to run across a broad range of architectures. It also uses a separate hardware acceleration layer, so every platform OpenCV runs on can use the acceleration techniques available for it (e.g., AVX-512). Programs written with OpenCV need not be aware of any hardware acceleration techniques; OpenCV automatically selects the best option on the current system. It’s also possible to build your own acceleration layer if you want to deploy OpenCV on custom silicon or tweak an existing deployment.

OpenCV modules and task sets

OpenCV’s modules are organized by major tasks in the general field of computer vision. Most of them are self-explanatory. For example, the objdetect module is the best place to start if you’re putting together a straightforward object-detection system.

Some high-level OpenCV modules might appear to overlap, but they are meant for different tasks. For instance, the video I/O module gives you a convenient interface for reading and writing video files or image sequences. But there’s also a video analysis module, which handles a different high-level use case: performing motion analysis or object tracking on video or image sets. If you want to generate video (with or without a large language model), use the video I/O module; if you want to analyze video (i.e., track the movement of objects), use the video analysis module.

Many of OpenCV’s functions can be hooked into and customized. For instance, object detection is a high-level module that includes barcode detection. Support for common barcodes (EAN-8, EAN-13, UPC-A, and UPC-E) is already available. But the barcode detector can optionally use an ONNX-format model for detection, so you could have it detect a bespoke variety of barcode, or attempt to decipher damaged or distorted barcodes based on a model.

OpenCV, pretrained models, and inference

OpenCV can work with external models for many other tasks, too, and without having to set up extra software to do it. The DNN module lets you load third-party, pretrained models for tasks like object detection and use them to serve predictions from still-image or video input. You can use models created with TensorFlow or PyTorch, or any other framework that can export a model in the common ONNX format.

OpenCV also curates its own collection of useful models, called the OpenCV zoo, on Hugging Face. The zoo is another good source for models and examples for common tasks, such as deblurring images, pose estimation, and object detection.

One major advantage of OpenCV for serving inferences from these models is that you don’t need anything except the model and what OpenCV itself provides. You do not have to set up a separate runtime for the model to serve inferences from it. This makes it easier to stand up a focused pipeline for a particular task. This pipeline could in turn later be attached to, or built out into, a larger and more complex pipeline if needed. But for basic inference, you can start with OpenCV.

OpenCV extras

OpenCV also comes with a large catalog of extra modules for other, highly specific tasks: direct access to encoding/decoding of video, adding text to images, video stabilization, text detection in scenes, and many more. One of these modules, datasets, provides a way to load well-known, pretrained datasets for common tasks (face recognition or gesture recognition, pedestrian detection, etc.) that can be used to make predictions or to generate performance benchmarks for those tasks.

Another convenient OpenCV feature is the high-level GUI module, which lets you create simple GUIs—windowing, buttons, images, mouse operations—with nothing but OpenCV. This is handy not only for quick prototypes, but even for creating a simple application without having to reach for an entire UI framework like GTK to create the front end. High-level GUI is no substitute for GTK or app frameworks like Electron, but it isn’t meant to be.

Fast and flexible computer vision

OpenCV’s big benefits go beyond giving you a prepackaged set of algorithms to perform computer-vision work. You can use OpenCV also to serve predictions from models for related tasks, like object recognition, without having to spin up extra infrastructure. And you can use it to build basic GUIs for those tasks with no extra libraries—quite handy to have when working with images or video. Finally, OpenCV’s decades of development and ongoing advancement make it a solid base to build on going forward.

OpenAI on Wednesday introduced a new Agents API that brings the agent harness and infrastructure behind Codex to developers, potentially giving enterprises a way to build custom AI agents while removing much of the orchestration and infrastructure management traditionally required to make such agents work.

That reduction in engineering complexity is possible because the Agents API is a managed service, with OpenAI hosting and maintaining the underlying harness and infrastructure.

Previously, developers building a custom agent typically had to assemble the components needed to support its work, including an agent runtime, context and session management, tools and external data connections, execution environments, and associated infrastructure.

OpenAI itself already offers several of those building blocks through products such as its Responses API, which developers could use to combine models with built-in capabilities including web search, file search and computer use, and its Agents SDK for defining and orchestrating agent workflows.

Agents API, which is currently in public beta, in contrast, can help developers design a custom agent in a single API call after they specify the task, model, tools, and the environment, the model provider wrote in a blog post.

For that execution environment, developers can choose to run agents in an OpenAI-managed sandbox, on their own infrastructure, or through supported sandbox providers, including Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel, it added.

These options give enterprises flexibility to choose between fully managed environments and deployments within their own VPCs, as well as different approaches to file and secret storage and compute configurations based on their workloads, it further explained.

The API could reduce time to production

The Agents API “significantly reduces” engineering work, helping developers spend more time building the actual business application instead of the agent infrastructure, said Pareekh Jain, principal analyst at Pareekh Consulting.  

“The main advantage with the Agents API is fewer moving parts. A long-running agent built by hand needs a job queue, a state database, a sandbox fleet, a compaction routine and a retry policy, and someone has to own and page for each of them,” echoed Amit Kumar Jena, AI development head at IT consulting firm Kanerika.

That reduction in engineering work, in turn, could help CIOs reduce the time required to roll out an agent in production and subsequently scale it.

“Enterprises may need fewer engineers to build the infrastructure around each agent, which should reduce development time,” said Phil Fersht, CEO of HFS Research.

That time advantage, Jena said, could be critical for most enterprises as agent development usually stalls between a working demo and a system capable of running unattended for hours, with infrastructure-related issues often becoming the key bottleneck to moving an agent into production.

Convenience at the cost of lock-in?

The reduction in engineering effort and potentially faster path to production, however, does not eliminate the tradeoffs CIOs must consider, including greater reliance on OpenAI for both the underlying agent infrastructure and the models powering it.

“Lock-in is the biggest concern. If OpenAI provides the model, context management, tools, orchestration, and execution environment, moving to another platform becomes harder,” Jain pointed out.

That dependency could also weaken an enterprise’s negotiating position on pricing and terms, Jena said.

There are also issues around data privacy and governance as the new API “doesn’t support Zero Data Retention” even when enterprises use their own sandbox, Jena pointed out.

That, in turn, could limit its adoption, especially in industries in the regulated sectors, such as healthcare and BFSI, Fersht said.

Rather, Startups, SaaS companies, and enterprises already using OpenAI are more likely to adopt the new API more readily as it reduces development effort, Jain said.

“Enterprises pursuing multi-model strategies may also prefer their own independent harness or are likely to take a hybrid approach,” Jain added.

Agents API’s adoption could be further limited due to the competition it faces from hyperscalers and rivals, analysts pointed out.

“This is a crowded category. Anthropic’s Claude Managed Agents has been in public beta since April. AWS also offers Amazon Bedrock AgentCore, whose managed harness became generally available in June and does the same category of work, meaning the loop, tool execution, context, state, and recovery, while letting you use any model and switch providers mid-session without losing context,” Jena pointed out.

Other competing offerings include Microsoft’s Foundry Agent Service and LangGraph, Jena added.

When I talk to people about agents interacting with websites, the conversation almost always starts with perception: how does an agent “see” a page? Is it screenshots or the DOM or the accessibility tree? In my previous InfoWorld article, “Accessibility is the first-class interface for AI agents”, I argued that the accessibility tree is becoming an increasingly important interface between websites and AI agents. From there the conversation shifts to actuation, and to ways of making it less brittle, which let a site expose its own actions as callable tools instead of forcing an agent to guess at buttons and forms.

That conversation matters. But it leaves out a more consequential architectural question, one that determines who is accountable when an agent gets something wrong: where does the agent live?

There are three plausible homes for an agent that interacts with your business: on-site, in-browser and off-browser. Each one trades control for reach differently. Right now, much of the industry’s attention is focused on the two homes furthest from the business: browser extensions that co-browse alongside a user, and autonomous agents running in the cloud that talk to your APIs or drive a browser on their own.

I think that is the wrong place for most enterprises to start.

If you run a business with real compliance exposure, or a brand you cannot afford to have misrepresented, the pragmatic move is to build the agent that lives on your own site first and treat reach as a problem you solve later, on your own terms.

Reach without governance is a liability

The appeal of in-browser and off-browser agents is obvious. They promise discovery, scale and automation you do not have to build or maintain yourself. An off-browser agent can compare your prices against every competitor and keep working after your support team has gone home. A co-browsing extension can act inside a user’s already authenticated session without requiring any special integration on your side.

But an agent you do not control is still speaking for your business.

An off-browser agent talking to your APIs or scraping your DOM runs on a model you did not choose, follows guardrails you did not write and represents your brand in a conversation you cannot see. If it misquotes a price, misstates a policy or initiates a transaction that creates a customer dispute, the fact that the agent belonged to somebody else may not make the resulting problem disappear.

There is also a deeper security problem. Computer-use agents interact with untrusted content by design. Anthropic’s guidance for browser and computer-use agents notes that webpages and application interfaces can contain adversarial instructions and recommends scoped permissions, human confirmation for high-stakes actions, and monitoring of agent behavior. OWASP’s AI Agent Security Cheat Sheet goes further, identifying agent-specific risks including prompt injection, tool abuse and privilege escalation, data exfiltration and memory poisoning.

In-browser agents are a better deal, because a human is watching the same screen and can catch a mistake before it lands. But the model, the tone and the decision logic are still outside your hands. For  or any other regulated industry, that is not a risk to take lightly just to pursue reach you have not yet learned how to govern.

What you actually gain by building at home

An on-site agent is less glamorous than the idea of your product being discovered by roaming agents across the open web. But it is the only home where the business keeps full governance.

You choose the model. You define the guardrails. You decide the tone, the escalation paths and exactly what the agent is and is not allowed to promise a customer. Because the agent has direct access to your systems, it does not need to reverse-engineer your checkout flow as an outside agent would. It can be given your actual domain knowledge and your actual APIs.

That matters because enterprises have solved this problem before. They did not expose databases directly to the internet; they introduced APIs. APIs were not just about integration. They created contracts, authentication, auditing and policy enforcement. On-site agents represent a similar evolution. Rather than forcing an external agent to infer behavior from a user interface, a business can expose governed capabilities through tools with explicit contracts.

WebMCP is a promising step in that direction. It makes it easier for a site to publish actions an agent can invoke, instead of forcing the agent to guess at the page. The important shift is not that the agent can click a button. It is that every action becomes observable, policy-governed and replayable.

The Chrome team’s WebMCP Sports demo is a good preview of what this can look like done well: an on-site assistant calling the site’s own WebMCP tools, with every call visible in the chat log. That is not a black box you are hoping behaves. It is an auditable interaction, with named tools and defined contracts.

The three homes

The cleanest way to think about this is as a spectrum.

• On-site. The agent lives on your website. You ship it. You own the model, the tools, the tone, the policies and the telemetry. It has first-party access to your systems and your workflows. The trade-off is reach: it is coupled to your site, and it is not meant to carry the user’s journey across the web.
• In-browser. The agent lives inside the user’s browser session, usually as a co-browsing extension or a browser-integrated assistant. It benefits from the user’s logged-in state and can act with the user present. That gives it real reach and a strong human safety net. But the business does not control the model or the guardrails, and the agent can still misrepresent the brand.
• Off-browser. The agent runs elsewhere — in the cloud, on a server or on a user’s local machine and reaches your business by talking to APIs or driving a browser remotely. This is the widest-reach model, but also the least governed from the business’s point of view. It may compare competitors, cross workflows and act at scale, but you do not control the experience.

None of these homes is inherently bad. They solve different problems. But if your first priority is governance, accountability and brand integrity, on-site is the right starting point.

Start with the governed interface

For teams deciding where to put their first investment, three moves make the difference between a real interface and a chatbot glued to a homepage.

First, ship the on-site agent as the authoritative interface, not a fallback. It should have first-class access to your own APIs and domain knowledge — the same systems your support team and checkout flow already use — rather than being handed a scraped version of your own page.

Second, instrument every tool call it makes. If your agent calls a WebMCP tool to check inventory or apply a discount, log it the way you would log an API call from any other client. That log is your audit trail, your debugging tool and eventually your evidence when a regulator or customer asks what happened.

Third, design for human escalation from day one. Even a well-governed agent should not make every decision autonomously. Build explicit handoff paths to human operators for ambiguous or high-risk situations.

Taken together, those choices turn an on-site agent into a governed interface rather than a novelty feature. That distinction matters. The first is something an enterprise can safely operate; the second is something it will eventually have to defend.

When agents start talking to agents

There is another reason to build the on-site agent first: the three homes are unlikely to remain isolated.

Imagine that a user’s browser agent arrives at an airline website. It already knows the traveler’s preferences, calendar constraints, loyalty programs and perhaps their budget. The airline’s on-site agent knows something completely different: routes, seat availability, fare rules, upgrade eligibility and the airline’s operational policies.

Why should the visiting agent reverse-engineer all of that from a website?

A more natural architecture may be for the two agents to communicate.

This is no longer purely hypothetical. The Agent2Agent (A2A) protocol is explicitly designed to allow independent agents built by different vendors and frameworks to discover capabilities, exchange information, delegate work and coordinate tasks.

In that world, the user’s agent brings intent and user context. The site’s agent brings domain knowledge and governed execution.

And suddenly the on-site agent’s limited reach does not look quite so limiting. It does not need to travel across the web if other agents can come to it.

The incentive problem nobody is pricing in yet

There is a harder question underneath the technical one: who does the on-site agent actually work for?

A visiting agent, co-browsing or otherwise, is acting on the user’s behalf. An on-site agent, however well-built, is the business’s employee. And the moment the two negotiate a discount, an upgrade or a substitution, that exchange stops looking like a neutral handoff and starts looking like a sales conversation with an AI on each side of the table.

That tension is going to matter.

Businesses building on-site agents now should design their guardrails with that scrutiny in mind, rather than treating “the agent decided” as a shield. Control is worth having. It is also a responsibility. And building the agent that answers to you is the only way to exercise it.

The first agent should be the one you can govern

The history of enterprise software suggests a familiar pattern. Organizations adopt new interaction models by first bringing them under their own governance. Internal systems become APIs. APIs become platforms. Platforms become ecosystems.

AI agents will likely follow the same path.

That is why I think the first agent your business builds should not be the one that can reach the entire web. It should be the one whose behavior you can understand, measure and improve. Once that foundation exists, expanding outward becomes an architectural choice instead of a leap of faith.

Reach is tempting. But for regulated and brand-sensitive businesses, control has to come first.

Every AI feature you’re building is based on a price that isn’t real. Current AI services are heavily subsidized as model providers seek to expand their market share, and subsidies inevitably end. Just think back to the early days of Lyft and Uber, when a single ride often cost less than taking public transit. As the costs associated with building on cheap AI infrastructure slowly start to reflect reality, the architecture decisions you made to get to market quickly may be the ones hemming you in.

This isn’t unique to AI. IT leaders have always had to weigh speed-to-value against the cost of dependency. What’s different now is how fast those dependencies are being built, and how little visibility most teams have into them.

Across IT, scalability is contingent on portability. And architecting with portability in mind is the best way to minimize lock-in as AI pricing models evolve, giving you leverage in future contract negotiations, and a fighting chance of switching platforms if the costs of one vendor get too high.

The challenge is that AI providers are incentivized to make leaving as painful as possible, which they achieve through deep integrations and proprietary features. You can control some of this through architectural decisions. Other parts are structural dependencies you should at least be aware of going in.

Swapping platforms will never be painless, but it’s less painful than being locked in when your vendor decides it’s time to recoup its losses, as every AI provider eventually will.

The part you control

The foundation for portability is the abstraction layer, an internal service your applications call instead of hitting Claude, GPT, or Gemini directly. It uses a request format defined by you, and translates that to whatever the vendor behind it expects. If you need to change vendors later, it’s closer to a configuration change than a code rewrite.

You don’t need to build this from scratch; open-source gateways like LiteLLM or Portkey already handle the routing and interface. Scoped to what you actually need, it’s a small project that one or two engineers can complete in a few weeks.

From there, audit the parts of your codebase that call a vendor’s API directly and route them through your proxy layer one at a time (have fun with that). Skip the features you’re not using yet, like fine-tuning or batch APIs, and focus on the 80% case. Think: text in, text out, and maybe tool calls.

The parts you don’t control

The API call is the easy part to abstract. Other dependencies may be tougher to account for given the pressure to deploy quickly, but you should at least be aware of them.

Prompts get tuned to a specific model’s characteristics, and those instructions won’t necessarily make sense to another model. If you do switch vendors, expect to re-tune each prompt. Fine-tuning a model will box you in, unless you use an open-weight model that you operate internally.

Vectors generated by one provider’s model won’t be compatible with another’s, so switching means re-embedding your knowledge base. Tool calling and structured output conventions differ by vendor, so code written around one model’s schema will need rewriting for another. Caching and batching mechanics carry their own vendor-specific rules and cost implications that don’t map across providers.

In short, code portability is cheap. Behavioral portability is the real cost, and no gateway tool solves that for you.

Build with your eyes open

Most teams don’t realize how locked into a model they’re becoming until they’re forced to move, which is the worst time to find out. How many parts of your codebase import a vendor SDK directly, versus calling a shared internal function?

If you want a real answer instead of a guess, pick one workflow that isn’t business-critical and try porting it to a different vendor. See what breaks and how long it takes to fix. That will uncover your dependencies better than a checklist.

The bottom line is that you should treat AI providers like any other infrastructure vendor where concentration risk matters. Hold AI providers to the same standard you would apply to any IT or technology vendor. There will likely always be some level of dependency, but you should know where the hooks are and choose them deliberately. That way, you’re prepared when AI price hikes inevitably arrive.

—

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.

Frontend teams have become pretty good at monitoring what happens after an application reaches production. We track JavaScript errors, API failures, latency and Core Web Vitals. When something changes after a release, these signals help us determine whether the application is healthy.

But there is one gap I think frontend teams often overlook. An application can look completely healthy in those dashboards while an important workflow is unusable for someone navigating with a keyboard or assistive technology.

Imagine a checkout flow where a recent UI change makes the final button unreachable by keyboard. The page still loads. The API responds successfully. There are no new JavaScript exceptions, and performance metrics look normal. Every traditional signal says the application is working, yet some users can no longer complete the purchase.

That is why I have started thinking about accessibility as more than a compliance or pre-release testing concern. If an accessibility regression prevents someone from completing a critical workflow, that is also a production reliability problem.

Where traditional frontend observability falls short

Most frontend observability focuses on technical health. We want to know whether pages load quickly, requests succeed and deployments introduce errors. These are useful signals, but they mainly tell us whether the software is functioning as the system expects.

Accessibility failures are different because they often do not produce obvious technical errors. Removing an accessible name from an icon button will not necessarily throw a JavaScript exception. Replacing a semantic button with a clickable div might leave mouse interaction working normally. A focus-management regression inside a modal can make the interface extremely difficult to navigate while having no effect on page performance.

This creates a blind spot. Our monitoring can tell us that the button rendered and that clicking it successfully triggered an API request. It may not tell us that a keyboard user cannot reach that same button.

Automated accessibility checks in CI are an important first line of defense, and I use them as an early guardrail. But I would not treat a passing CI check as proof that the production experience is accessible. Production applications contain changing data, feature flags, third-party scripts and combinations of components that may not be represented in isolated tests.

Automated tools also have limits. They can identify many structural problems, but they cannot detect every accessibility or WCAG conformance failure. CI should therefore be an important checkpoint, not the end of accessibility verification.

Monitor accessible journeys, not just healthy pages

One way I think frontend teams can close this gap is by applying the same idea behind synthetic monitoring to accessibility.

Instead of checking only whether a page loads, we can test whether important user journeys remain usable. Can someone navigate the primary controls using only a keyboard? When a dialog opens, does focus move somewhere sensible? Can a form be completed without relying on a mouse? Do important controls still expose useful names and roles?

Consider the checkout example again. Traditional synthetic monitoring might verify that the page loads, products appear and the checkout API responds. An accessibility-aware journey could go further by navigating through the same flow with keyboard interactions and verifying that focus reaches the controls required to complete the purchase.

I would not try to automate every accessibility requirement this way. The goal is to identify a small number of critical workflows and ask a simple question: Can a user still complete the task?

For applications with a design system, I would extend the same thinking to shared components. A regression in a button, dialog, form field or navigation component can spread across many screens at once. Testing keyboard behavior, semantics, accessible names and focus expectations at the component level can catch problems closer to their source instead of discovering the same regression page by page.

This creates two useful layers of protection. Design-system checks help protect the building blocks, while synthetic journeys help verify that those building blocks still work together in real application flows.

Make accessibility part of release health

Frontend teams already look at signals after deployment to decide whether a release is healthy. We watch error rates, latency, failed requests and performance changes. I think accessibility signals can become part of that same conversation.

That does not mean creating another huge dashboard or turning every automated accessibility warning into a production incident. The useful approach is to focus on impact.

If a release introduces a minor issue in secondary content, the team may address it through the normal development process. If the same release prevents keyboard users from completing checkout, submitting a form or navigating a primary workflow, that deserves a different level of attention.

This is where accessibility-aware release health becomes valuable. Teams can define a small set of expectations around critical journeys and shared components, then watch for regressions just as they would watch other frontend reliability signals.

The need for this approach is becoming harder to ignore. The 2026 WebAIM Million analysis found an average of 56.1 detected accessibility errors per home page, a 10.1% increase from 2025. It also found that the average home page contained 1,437 elements, a 22.5% increase in a single year. As interfaces become larger and more dynamic, relying only on occasional accessibility audits becomes increasingly difficult to scale.

If users can’t complete the workflow, the system isn’t healthy

Frontend observability has given us increasingly sophisticated ways to understand what applications are doing in production. But our definition of application health should not stop at whether JavaScript executed, APIs responded or pages rendered quickly.

A system can pass every one of those checks and still fail the person trying to use it.

Accessibility testing during development remains essential, but production-oriented signals can help close the gap. Synthetic user journeys can tell us whether critical interactions still work. Design-system regression tests can protect shared components. Accessibility-aware release checks can help teams recognize when a deployment has affected a critical workflow.

For me, the principle is simple. If users cannot complete an important task because of an accessibility regression, I do not think we should describe the application as healthy just because the traditional dashboards are green.

That is not only an accessibility problem. It is a frontend reliability failure.