AI coding agents play a major role in software development and delivery, and for good reason. They can investigate bugs, trace dependencies, refactor services, and propose patches without developers needing to assemble all of the relevant context manually. That capability comes courtesy of agents’ appetite for context. To make informed decisions, agents read source code, configuration files, terminal output, error messages, environment information, and more…much, much more.

“Secure, agentic development depends on a security control many teams still lack: preventing secrets from leaking to AI coding agents and becoming model context.”

From a security standpoint, this becomes problematic when agents, in the search for context, inadvertently reach for secrets.

For years, developers have been taught not to commit API keys, database credentials, and tokens to Git. But agentic workflows have created another route for secrets to escape development environments before a commit, code review, or CI job. Depending on its permissions, configuration, and provider architecture, an AI coding agent may read local files or receive pasted content that is then included in data sent to an AI service, and, in the process, developers may never see their credentials leak.

The quiet path from local files to external systems

Some forms of secrets leakage are obvious. A developer troubleshooting an authentication failure may paste, for example, a failing API call into a chat window, including the token. However serious, this sort of leak is characteristically human.

The more consequential escape pathway is quieter. An agent tasked with understanding a project may inspect files in its working directory, including an overlooked .env file, a cloud credential profile, an SSH configuration, or sensitive application logs. In such instances, nothing has necessarily gone wrong from the agent’s perspective; it is doing exactly what it was designed to do: collect context to solve the task at hand.

“Agentic workflows have created another route for secrets to escape development environments before a commit, code review, or CI job.”

But once a secret becomes part of that context, it may pass through systems outside an organization’s direct control. Depending on the workflow, it can appear in model provider logs, gateway telemetry, prompt histories, or debugging records. Rotating the credential is essential, but it does not erase copies that may already exist in those systems.

This changes the practical definition of a secret leak. The problem is no longer limited to what lands in a repository, but also includes what an autonomous tool reads and forwards while operating on a developer’s machine.

Why traditional security gates no longer suffice

Most application security programs are built around durable checkpoints: the commit, pull request, build, and deployment. In the agentic era, these checkpoints remain important as they can detect secrets that reach version control and prevent a bad change from merging and deploying.

They cannot, on their own, prevent a secret from being included in an agent prompt before the code ever reaches a repository.

This highlights an important timing gap. The 2025 Verizon Data Breach Investigations Report reports a median of 94 days to remediate leaked secrets discovered in GitHub repositories. In an agent-driven workflow, detection and response need to happen much earlier, and not after a credential is exposed. Still, at the moment it’s about to cross the boundary from local context to an external model.

Bad actors already understand the value of that porous boundary. Recent supply-chain attack campaigns, including Mini Shai-Hulud, have searched developer and CI environments for credentials and configuration data, including AI coding-tool configuration files. These campaigns show that agent configurations and the local context accessible to an agent are valuable targets. AI coding agents can broaden the local data reachable during a session, making even the agent’s context-collection mechanisms an attractive target.

Treat agent context as an egress surface.

The secure mental model doesn’t frame AI agents as mere code editors, but rather, automated data-movement systems. Its inputs can include far more than the source files a developer is actively editing, and its outputs may involve external services.

That calls for a zero-trust approach to agent context. Before sending a prompt or adding a file to an agent’s working set, organizations should evaluate it for sensitive material. Controls should be deterministic: identify a likely secret, block or redact it, and provide the developer with a clear path to remediate it.

“Asking an LLM to decide whether to transmit a credential does not create a reliable security boundary.”

Critically, the control should be independent of the model. Asking an LLM to decide whether to transmit a credential does not create a reliable security boundary. Purpose-built secrets detection can inspect prompts and files against known credential patterns and policies, applying a deterministic policy, such as blocking a prompt or file read when it detects a credential-shaped value. For example, Sonar’s secrets detection ships alongside dedicated agent plugins to bring that local check into tools such as Claude Code, GitHub Copilot, Codex, and Cursor, so it can flag a credential before a prompt or file read is transmitted to a model provider.

Build defense in layers, without disrupting your agentic workflow

A legitimate workflow does not involve forcing developers to choose between secure development and useful automation, but instead places fast controls at several points where secrets can escape:

• In the editor: Use IDE-integrated secrets detection to flag credentials while they are being written.
• Before model submission or agent file access: Where the agent supports it, scan prompt submissions and file reads locally, and block risky operations according to policy.
• At the command line: Check generated snippets and local changes in terminal-driven workflows.
• In pull requests and CI: Detect secrets that reach the repository and use review, quality gate, and deployment controls to prevent unsafe changes from progressing.
• In incident response: Rotate exposed credentials quickly, investigate downstream logs and access, and reduce recurrence through policy and training.

Building defense at the pre-submission layer is an emerging requirement and requires both security and usability. Secrets detection must be fast enough to run in developer workflows; a scanner that introduces lengthy pauses may be bypassed or disabled by developers, and it must also have a manageable false-positive rate, or developers may stop trusting it.

Teams should also make their agent permissions and context rules explicit, as broad agent permissions can increase the amount of sensitive local context reachable during a coding session. Consider the following: which directories can an agent read? Are .env files, credential stores, home-directory configurations, and production logs excluded by default? Does the organization route prompts through an approved gateway? What retention, training, and audit settings apply at the provider level? Document and enforce the answers rather than leaving them to individual developer preference.

Secrets security must shift left.

Prevent secret leakage without hindering AI-assisted development, ensuring the productivity promise of agentic development doesn’t carry significant security implications.

As agents become more autonomous, security standards must follow agents upstream. It’s critical to stop a secret before it becomes context, while it is still local, visible, and easier to control. In the agentic era, code review and CI-level checks will remain essential safety nets. Still, for agent-centric development, the first line of defense must shift left: to the instant an AI coding tool determines what to read and what to transmit. That is the control modern development teams need to implement now.

The post AI coding agents need a secrets-safe context boundary appeared first on The New Stack.

The early rapid expansion of AI capabilities that focused on frontier models was largely ushered into the world by a few powerful, US-based AI labs. Open-weight models released from labs in China, early on from DeepSeek, and later from Moonshot, Z.ai, and others, have in part disrupted that dominance. But growing concerns about the concentration of power have led to discussions about the need for at least some level of AI sovereignty.

AI sovereignty doesn’t necessarily imply total control of your AI stack. It holds the promise of having more localized security and privacy, better adherence to local jurisprudence (for example EU AI and data laws), more dependable service, and potentially more culturally specific outputs from the AI technologies used within a specified border or region. Negotiating interdependence is not necessarily a problem, but having an array of tools beyond just open-weight models and options in those negotiations beyond just commercial offerings is imperative.

Unsurprisingly, the same AI labs that gave rise to the need for AI sovereignty are also pushing their own solutions to the problem. While local institutions consider and even adopt some of these initial “sovereignty” offerings from these labs, open source AI technologies may offer a more promising horizon, more flexibility, and a means to manage dependencies. Tim O’Reilly argues open source AI is a potential opening for greater participation in the future of AI’s development.

From the underlying chip technology that is necessary for model training and inference to the cloud and data infrastructure that enables model development, companies such as NVIDIA, OpenAI, Google, Microsoft, and AWS have begun to stake out their own territory to maintain relevance within the global push toward AI sovereignty. Stanford University’s Human-Centered Artificial Intelligence Lab (HAI) lays out the different approaches and offerings these labs have developed in its report The Commercial Landscape of AI Sovereignty Offerings. It argues that while these labs “promise that countries will own their AI stack, [they also] deepen dependencies on U.S. Big Tech.”

There are some non-US-based commercial alternatives that offer their own “full stack” solutions or AI sovereignty for specific layers of the stack. Companies in Europe, the Gulf region, Asia, and elsewhere are positioning themselves as local alternatives to US tech oligarchs. According to the HAI report, “Many of the most mature and advanced companies are actively backed by their governments. In these cases, sovereignty is not just a marketing claim but a stated policy objective, with governments directing funding, structuring procurement, and, in some cases, selecting specific companies to build out domestic AI capacity on their behalf.”

These types of collaboration can both enable independence from US labs but may also create openings for political intervention. Claims about censorship and control of Chinese models emerged quickly after DeepSeek’s initial 2025 release. More recently, there have been probes into how US models may limit certain types of discourse. Moreover, the HAI report points out that often the offerings of these alternative providers still rely on the underlying technologies, specifically chips and cloud infra, of the US labs.

The proliferation of commercial offerings provides the space for diversification or potential leverage to negotiate better terms for collaboration, even with the dominant players. Open source AI technologies also play an important role in creating opportunities for even more diversification and greater sovereignty. As HAI argues, “Sovereignty strategies that do not consider the role of open-source AI risk normalizing fragmentation and political overreach.”

In order for open source AI to counter the diversification of commercial sovereignty offerings, these technologies must also proliferate beyond open-weight models. Arguing for a “federated system” of open source AI that enables sovereignty based on an “architecture of participation,” Tim O’Reilly writes that “the right infrastructure to let us satisfy both goals [of being everywhere and allowing everyone to have a say] will be a federation of models, a federation of protocols and code, and a federation of capacity. We need an architecture of participation all the way down the stack, and all the way up.” A key technology in the expansion of the open source AI stack these days are agent harnesses.

In a recent article, Mozilla CTO Raffi Krikorian argues that “the orchestration layer above the [model] weights is where capability is concentrating, and closed labs are already welding it shut”; therefore, it’s imperative to build on open harnesses, not just models. Commercial offerings that have dominated thus far include Claude Code and Codex. OpenClaw offered an initial disruption and promise for open source in late 2025, though the creator was quickly absorbed into OpenAI’s organization. While big tech labs continue to absorb when, who, and what they can, NousResearch’s self-improving Hermes agent harness has also garnered substantial attention now with over 230,000 stars on GitHub. More recently harnesses such as Pi and DeepSeek Harness are expanding that open source offering, heeding Krikorian’s call.

Beyond agent harnesses, some of the strongest open source projects are developing in the less visible layers. Inference engines such as vLLM, SGLang, llama.cpp, and ONNX Runtime make it possible to serve a range of models efficiently across data centers, regional clouds, personal computers, and edge devices. Ray, which was developed by researchers at UC Berkeley, distributes demanding AI workloads. Ollama lowers the barrier to running models locally. Together, these projects give institutions more freedom to change models, hardware, and hosting providers without rebuilding an entire system around another company’s proprietary platform.

Other fast-growing projects are filling out the data, interoperability, and accountability layers of the stack. The Model Context Protocol and Agent2Agent Protocol offer open standards through which agents can connect to tools and to one another. Qdrant, Chroma, Milvus, and LanceDB provide open infrastructure for storing and retrieving institutional knowledge. MLflow, Opik, and OpenLLMetry allow developers to evaluate, trace, and monitor AI applications without surrendering operational data to a closed dashboard. The AI Potluck Gap Map classifies inference, deployment, and agent protocols as mature open ecosystems but identifies resiliency gaps in storage and observability, where fewer fully open projects occupy the leading tier. These gaps point toward an important investment agenda. Sovereignty will depend not on finding a single open replacement for Big Tech but on sustaining interoperable public alternatives across every consequential layer of the stack.

Even still, the looming threat of acquisitions and absorption of open source is persistent. The fintech company Stripe recently bought OpenRouter, a platform that allows developers to access various models and has become a primary hub for accessing and routing open-weight models in particular. NVIDIA has acquired Hugging Face, one of the key players for the open source AI ecosystem, and it has also just settled a licensing deal with Poolside, which develops open-weight coding models, purportedly to avoid the oversight of complete acquisition.

AI sovereignty may mean the necessity of “calibrating interdependence” with US Big Tech solutions or replacing a foreign dependency with a domestic one for the time being. But it must also entail building the technical capacity, open infrastructure, and participatory institutions needed to preserve genuine choice across the entire AI stack. Open source will continue to be vulnerable to commercial absorption, and efforts to counter that must become more robust.

---

Is cybersecurity part of your job in any way? If so, we’d like to know what you think for a report we’re writing. Just answer these quick 11 questions. Thanks in advance! Take the survey >

AI can produce code. Organizations still have to produce software. Agentic development is changing how software gets made, but it hasn’t changed what it costs to be wrong.

Six months ago, we began publicly experimenting with agentic development environments. Around the same time, we introduced JetBrains Central as an open control and execution system for agent-driven development. We subsequently began rolling out JetBrains Central CLI, shared context, cloud agents, automations, governance, and AI cost controls for teams and organizations.

Today, we are bringing this work together as JetBrains Air: an open, coherent system of products for developers, teams, and organizations, inside and beyond JetBrains IDEs. It is multi-surface and multi-service. Each product solves a distinct problem, but the products work better together.

JetBrains Air marks a significant expansion in what JetBrains is building for. For 26 years, we have focused primarily on the individual developer workbench. Now, we are building for the wider system through which agentic work is initiated, executed, coordinated, reviewed, and governed.

The IDE remains important to JetBrains’ future. The era in which the whole software development system can be contained in one window is ending. As part of our continued investment, we are now bringing the foundational agentic experience into JetBrains IDEs, giving professional developers an environment where they can work effectively with agents while understanding, changing, and verifying the resulting code. JetBrains Air connects the wider system developing around it.

That system is based on a core belief that the future of agentic development will be multi-vendor. No single model, agent, or service will be right for every developer, team, or task.

From one product to an open system of products

This strategic shift has a practical consequence: JetBrains Air cannot be just another agent or development environment. It must connect products for individual work, team coordination, organizational control, context, and process automation – and remain open to the tools and agents developers choose, including those JetBrains does not build.

JetBrains Air includes products that are available today alongside others that will be introduced as the system develops:

• Air in JetBrains IDEs – a complete agentic development experience for directing and orchestrating agents and verifying their work inside JetBrains IDEs. 
• Air Teams – a new way to coordinate and automate software-delivery workflows involving developers and autonomous agents. 
• Air Governance (formerly JetBrains Central) – organizational policy, visibility, auditability, cost management, and accountability for AI-assisted and agent-driven development. 

Junie is JetBrains’ coding agent for professional software development. It will be supported across all Air surfaces.

Air in JetBrains IDEs gives developers the environment to direct agents and verify their output using JetBrains’ code intelligence. Air Teams turns individual agent activity into coordinated team workflows. Air Governance makes that activity visible, governable, and accountable across the organization.

But an open system cannot stop at JetBrains’ own products. The Agent Client Protocol (ACP) standardizes the connection between an IDE and an agent’s full harness, including its planning, logic, tools, model routing, and observability. Through the ACP Registry, developers can discover and run a growing range of compatible agents while continuing to work inside JetBrains IDEs.

Air Governance is designed to extend visibility and cost governance across providers and the different tools through which agentic work takes place. This means developers can choose the agent, model, or service suited to the task without forcing the organization to give up context, visibility, or control.

Together, the Air products allow work to move between developers, agents, tools, and environments without losing the context and controls surrounding it.

Individual adoption has moved faster than organizational infrastructure

Since March, our products have progressed significantly, but so has our understanding of what agentic development requires.

Developers have been adopting agents faster than organizations can build the infrastructure around them. Agent capabilities have advanced, and different models and agents have proven useful for different tasks. However, the context, coordination, governance, and cost management surrounding them have not kept pace.

For many developers, agents are already delivering practical value. At the organizational level, the economics are much harder to prove. The costs surface elsewhere – in review, rework, security, infrastructure, and spend. 

Which agents can access company code? Where can data go? Which output requires human review? What happened while an agent was working remotely? Who approved the resulting change, and how was it verified?

Fragmentation at this level isn’t just irritating. It makes software development harder to understand, measure, and govern at exactly the point when more of the work is being delegated.

The bottleneck is shifting with the work

Code that’s obviously wrong gets caught quickly. That part of the system still works. The harder problem is code that’s almost right: plausible, capable of passing a superficial check, but quietly carrying a bad assumption or architectural inconsistency that won’t surface until it’s expensive.

As agents take on more of the execution, the bottleneck shifts from producing change to understanding, verifying, and owning it. Code becomes cheaper to generate but more expensive to verify. Agent activity becomes easier to start but harder to coordinate, audit, and explain.

And while the work can be delegated, accountability cannot. An agent will not get the call at 3:00 am when something breaks. The responsibility for what ships still belongs to the people and organizations that ship it. 

This is why control becomes harder, not easier, as AI improves. A more capable model may produce better output. It does not establish organizational policy, preserve provenance, provide cost visibility, or decide who accepts responsibility for the resulting change.

The future is multi-vendor

Multi-vendor support is a foundational design principle of JetBrains Air, shaping how the system is being built from the outset.  

We don’t believe this market will consolidate any time soon. Models vary in what they’re good at, and rankings change every few months. Teams inside the same company already make different choices, and they are often right to do so. Standardizing on one AI vendor today means making a multi-year commitment in a market that won’t look the same next quarter.

Keeping the options open is the reasonable thing to do. The problem is what openness currently costs. Every new model, agent, or service an organization adds takes away a little more visibility into its own development work. Context doesn’t carry over between tools. Spend can’t be attributed. Policies have to be rebuilt for each service. 

Organizations should not have to choose between using the best available tools and understanding what is happening inside their own engineering. That trade-off exists because nothing in the current stack was built to sit above several vendors at once.

This is the work JetBrains has taken on. We build our own agent, and we intend to make it excellent. But JetBrains Air does not require customers to use ours, and our strategy does not depend on which model provider leads the rankings this quarter. We have no reason to make the ecosystem smaller than it is.

What we can offer instead is one place to run, see, govern, and account for agentic development across every model, agent, and service – for the developer, the team, and the organization.

Supporting multiple models and agents is the floor, not the ceiling. The part that matters is what sits above them: shared context, one set of policies, a single cost view, and a record of what happened, regardless of which vendor produced the change.

Why JetBrains?

Multi-vendor choice solves only part of the problem. Agents also need reliable software intelligence.

JetBrains brings 26 years of engineering intelligence to the problem, helping developers understand the structure and behavior of complex software, not simply generate more of it. That deterministic code intelligence provides a foundation for making agentic work more reliable, efficient, and understandable across different models and agents. We are seeing promising results from giving AI agents access to deterministic code intelligence. 

This is an economic advantage as well as a technical one. Agents spend time and money rediscovering information the codebase already contains. An agent that can retrieve that knowledge is cheaper and more accurate than one that has to reconstruct it. Because intelligence does not belong to one model, the benefit can extend across supported agents and services. 

We are also going through the same transition as the organizations we build for, adopting agents internally, redesigning workflows, and learning where individual productivity gains translate into better software delivery and where they simply move work elsewhere.

What comes next

JetBrains Air will develop through a rolling series of releases. We will be explicit about what customers can use now, what is entering preview, and what remains part of our longer-term direction.

Over time, JetBrains Air will extend further into mobile and remote experiences, allowing people to initiate, monitor, review, and continue agentic work as it moves between environments. The goal is not to reproduce the IDE on every surface. We are making the right context and controls available wherever decisions need to be made. 

We will also bring JetBrains’ intelligence into more agentic workflows. This includes richer context drawn from code, architecture, repositories, runtime behavior, and organizational knowledge, as well as better ways to route work between developers, models, agents, and services.

More work will be triggered by repository events, schedules, and delivery processes rather than by a developer opening an editor and issuing a prompt. JetBrains Air will provide the intelligence, oversight, and human control these workflows require across surfaces and services.

We will not name future products before their scope and availability are ready to be confirmed. With each release, we will explain what works, how it connects, and what’s still in progress.

Where JetBrains Air is going

The companies that succeed in adopting AI will not necessarily be those that generate the most code or deploy the most agents. They will be those that can expand experimentation without losing quality, context, cost discipline, or human understanding.

JetBrains Air is our commitment to building for that reality. It expands JetBrains from the developer workbench into a system of products connecting developers, agents, teams, and organizations.

The goal is not more code. It is software that developers, teams, and organizations can understand, verify, and stand behind.

BONUS: From AI Curiosity to Practical Project Tools With William Davis

AI becomes useful when it moves from generic answers into the daily work of solving real problems. In this BONUS episode, William Davis shares how he started building his own AI-assisted project management tools, what went wrong when the code grew too fast, and how Scrum Masters can use AI more carefully at individual, team, and project levels.

When AI Stops Being a Curiosity

"I really need to get a handle on how to productively use AI in my job."

 

William's shift started with a familiar problem: release plans are full of uncertainty, but stakeholders still need to understand what might happen and when. Instead of handcrafting uncertain delivery ranges in Excel, William used AI to build a desktop application that created probabilistic Gantt charts. In his work, these were not traditional command-and-control schedules. They were release plans that showed stakeholders a realistic range of possible delivery dates, making uncertainty visible instead of hiding it behind a false promise.

The Euphoria and the Crash

"Anybody can prompt an app into existence, but if you want an app that is actually enterprise-worthy, it does take a little bit of software engineering knowledge to know what questions to ask."

 

The first experience felt almost magical: ask questions, get code, assemble the pieces, and see a working application appear. But the magic faded when William kept extending the tool and the code started breaking in familiar ways. The AI forgot previous decisions, repeated mistakes, and produced a growing mass of tangled code. The lesson was direct: AI can move fast, but it still needs architecture, tests, and software engineering judgment. Without that, teams can build quickly and still end up with something hard to use, hard to maintain, and hard to trust.

AI as a Partner Inside the Tool

"The collaboration has a third partner, the AI."

 

William's work expanded from one application to several tools for forecasting, story mapping, release planning, and budgeting. The more interesting change was not only using AI to build tools, but building tools that could connect to AI while people used them. Through Model Context Protocol, William's tools can work with an LLM partner to help teams turn rough product ideas, emails, and scattered artifacts into structured story maps. The team still edits, challenges, moves, splits, and reframes the result. AI helps create a first model faster, but the team keeps responsibility for meaning and decisions.

Security Starts With Where the Data Lives

"Start with the easy sell: I'm building a tool, and the data that I'm creating is stored locally on your employer-managed device."

 

William is clear that AI adoption in organizations cannot ignore infrastructure and cybersecurity concerns. His first approval path came from designing tools that default to local storage in the browser, on an employer-owned and managed device. That made experimentation easier because sensitive project data did not need to leave the company environment. For teams using MCP or company AI platforms, the same question matters: where is the data going, who governs it, and what agreements protect it from being used for model training? Scrum Masters and software leaders need to treat security as part of the coaching conversation, not as an afterthought.

Better Questions, Earlier in the Work

"My goal is to solve the problems that I have at the moment that I'm having them."

 

For William, AI changed the work by removing delays between seeing a problem and trying a solution. A release forecast that once took 30 minutes to handcraft can now be updated in a few minutes during the team conversation. In a cloud ERP evaluation, AI allowed him to ask vendor-specific timeline questions much earlier than before. Instead of waiting deep into an RFP process to discover how different solutions would change the implementation plan, he could compare likely timelines upfront and make the trade-offs visible sooner.

Go Slow to Go Fast With AI

"Ask three different sessions the same question."

 

One of William's strongest warnings is that a single LLM answer can feel more certain than it really is. LLMs are probabilistic, and the same prompt can produce different answers across models or sessions. His workaround is to slow down the design step: ask multiple sessions or models to analyze the same problem, then use an orchestrator session to compare the answers and improve the design. For architecture questions, he may use Claude, ChatGPT, Grok, and Gemini. For smaller product improvements, he uses multiple sessions inside one LLM ecosystem. This is not a return to big upfront design. It is short-cycle research, planning, and implementation, repeated in small increments.

A Practical First Step for Scrum Masters

"Rather than just read about how to use AI, just start using it."

 

William's practical advice is to choose one real problem and ask your LLM how to approach it. If you are not familiar with MCP, start there: ask your preferred model how to connect to a tool through MCP, and experiment with a low-risk use case. William also invites listeners to try the free tools at SPERT Suite, where the default local mode keeps data on your own device. His broader point is simple: AI becomes useful when it is connected to a specific work problem, a clear feedback loop, and a human who still owns the judgment.

About William Davis

William Davis is a seasoned IT professional with four decades of experience as a software developer, project manager, and agile advocate. A certified Scrum expert and PMP, he promotes personal and organizational agility, delivers customized training, and mentors agile practitioners. Creator of Statistical PERT® and SPERT® Suite, William innovates with free, AI-powered project management tools for today's agile teams.

 

You can link with William Davis on LinkedIn and explore William's free tools at SPERT Suite.

Download audio: https://traffic.libsyn.com/secure/scrummastertoolbox/20260922_William_Davis_Tue.mp3?dest-id=246429

This release is about making everyday database workloads more predictable. It fixes a collection of issues that could appear under connection failures, retries, transactions, pooling, streaming, encryption, and newer SQL Server data types.

If your application uses Microsoft.Data.SqlClient, upgrading to 7.1.0 gives you a provider with fewer sharp edges in the paths your application already depends on.

Connections and transactions behave more reliably

Connection pooling is one of those features that should disappear into the background. Your application opens a connection, does its work, returns the connection, and moves on.

SqlClient 7.1.0 fixes several cases where that process could go wrong:

• A connection could return to the pool in a broken state after a TransactionScope rollback.
• Pool performance counters could become negative or drift upward after failed or broken connections.
• A connection factory timer could keep waking the process even when there were no pools to maintain.
• A race during connection opening could produce an InvalidCastException.
• Failover login paths could encounter invalid parser state.
• Several cancellation token sources could remain allocated longer than necessary.

These fixes matter most in long-running services, applications that reconnect frequently, and workloads that depend heavily on pooling and transactions.

Better behavior for modern SQL Server data

SqlClient 7.1.0 also fixes issues that affect newer .NET and SQL Server scenarios.

Applications using DateOnly with variants or table-valued parameters now send the correct SQL type. This avoids converting valid date values into datetime and prevents failures for dates outside the datetime range.

Large decimal parameters with explicit precision and scale no longer cause an OverflowException. This is especially important for Always Encrypted applications, where precision and scale are commonly specified explicitly.

Azure SQL applications using schema discovery can now see the json data type through:

connection.GetSchema("DataTypes");

The release also corrects Always Encrypted metadata reads and fixes a SqlDataReader streaming issue where calling IsDBNull() before reading a streamed value could skip data.

Easier diagnosis for libraries and tools

SqlClient 7.1.0 adds an application identity to the TDS USERAGENT payload.

Most application developers do not need to configure this. The feature is intended for libraries and tools built on top of SqlClient. For example, Entity Framework Core, SQL Server Management Studio, SqlPackage, and other tools can identify themselves to SQL Server.

That gives database and service operators a clearer picture when investigating a workload. Instead of seeing only that many connections came from SqlClient, telemetry can show which client stack created them.

A library or tool can register its identity before opening a connection:

using Microsoft.Data.SqlClient; await using var connection = new SqlConnection(connectionString); connection.RegisteredApplication = RegisteredApplication.EntityFrameworkCore; await connection.OpenAsync();

This value is telemetry only. It must not be used for authorization or other security decisions.

Moving away from Transparent Network IP Resolution

TransparentNetworkIPResolution is now marked obsolete.

There is no runtime behavior change in 7.1.0. Applications that use the property will receive a compile-time warning and can migrate when convenient. For new code, use MultiSubnetFailover, which works across supported target frameworks and is the recommended approach for availability group listeners.

Upgrade to 7.1.0

Install the provider with NuGet:

dotnet add package Microsoft.Data.SqlClient --version 7.1.0

The SqlClient extension packages continue to use aligned versions. If your application references them, update them to 7.1.0 too:

• Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider
• Microsoft.Data.SqlClient.Extensions.Azure
• Microsoft.Data.SqlClient.Extensions.Abstractions
• Microsoft.Data.SqlClient.Internal.Logging

Applications upgrading from 7.0.2, 7.0.3, or a 7.1 preview do not need new .NET Framework strong-name binding redirects.

Read the complete 7.1.0 release notes and get the package from NuGet.