When you ask a coding agent to build a data pipeline, it may not use the best structure. But what if the agent got a second opinion before it executed the plan?

Today, in GitHub Copilot CLI, we’re introducing Rubber Duck in experimental mode. Rubber Duck leverages a second model from a different AI family to act as an independent reviewer, assessing the agent’s plans and work at the moments where feedback matters most.

To catch different kinds of errors, a different perspective matters. Our evaluations show that Claude Sonnet + Rubber Duck makes up 74.7% of the performance gap between Sonnet and Opus alone, achieving better results for tackling difficult multi-file and long-running tasks. Use /experimental in Copilot CLI to access Rubber Duck alongside our other experimental features.

The problem: Confident mistakes can compound

Today’s coding agents follow a clear loop. First, the agent assesses the task, then drafts a plan, implements, tests, and iterates if necessary. It’s a powerful flow that works well, but it has blind spots. Any decision an agent makes early on, especially in the planning stage, is the foundation you’re building upon. Assumptions and inefficiencies become dependencies, and by the time you notice, you may have to fix more than just the small mistake at the start.

Using self-reflection and having the agent review its own output before moving forward is a proven technique. However, a model reviewing its own work is still bounded by its own training biases: the same training data and techniques, the same blind spots.

Rubber Duck adds a second perspective

Rubber Duck is a focused review agent, powered by a model from a complementary family to your primary Copilot session. When you’ve selected a Claude model from the model picker to use as your orchestrator, Rubber Duck will be GPT-5.4. As we experiment with Rubber Duck, we are exploring other model families for the orchestrator and for the Rubber Duck. The job of Rubber Duck is to check the agent’s work and surface a short, focused list of high-value concerns: details that the primary agent may have missed, assumptions worth questioning, and edge cases to consider.

When does the cross-family review help?

We evaluated Rubber Duck on SWE-Bench Pro, a benchmark of large, difficult, real-world coding problems drawn from open-source repositories. Here’s what we found:

Claude Sonnet 4.6 paired with Rubber Duck running GPT-5.4 achieved a resolution rate approaching Claude Opus 4.6 running alone, closing 74.7% of the performance gap between Sonnet and Opus.

We noticed that Rubber Duck tends to help more with difficult problems, ones that span 3+ files and would normally take 70+ steps. On these problems, Sonnet + Rubber Duck scores 3.8% higher than the Sonnet baseline, and 4.8% higher on the hardest problems identified across three trials. Here are a few examples of what Rubber Duck finds:

• Architectural catch (OpenLibrary/async scheduler): Rubber Duck caught that the proposed scheduler would start and immediately exit, running zero jobs—and that even if fixed, one of the scheduled tasks was itself an infinite loop.
• One-liner bug, big impact (OpenLibrary/Solr): Rubber Duck caught a loop that silently overwrote the same dict key on every iteration. Three of four Solr facet categories were being dropped from every search query, with no error thrown.
• Cross-file conflict (NodeBB/email confirmation): Rubber Duck caught three files that all read from a Redis key which the new code stopped writing. The confirmation UI and cleanup paths would have been silently broken on deploy.

When does Rubber Duck activate?

GitHub Copilot can call Rubber Duck automatically, both proactively and reactively, and it can be triggered by a user at any time to critique and revise its work.

For complex work, GitHub Copilot may seek a critique automatically at the checkpoints where feedback has the highest return:

1. After drafting a plan: This is where we expect developers will see the biggest wins, because catching a suboptimal decision early avoids compounding errors downstream.
2. After a complex implementation: This is when a second set of eyes on complex code can help catch edge cases.
3. After writing tests, before executing them: This is a chance to catch gaps in test coverage or flawed assertions, before self-reinforcing that “everything passes.”

The agent can also seek a critique reactively if it gets stuck in a loop or can’t make progress. Consulting Rubber Duck can break the logjam.

As a user, you can request a critique at any point. Copilot will query Rubber Duck, reason over the feedback, and show you what changed and why.

We made a key design choice: the agent invokes Rubber Duck sparingly, targeting the moments where the signal is highest, without getting in the way. For the technically curious: Rubber Duck is invoked through Copilot’s existing task tool—the same infrastructure used for other subagents.

For now, we are enabling Rubber Duck for all Claude family models (Opus, Sonnet, and Haiku) used as orchestrators in the model picker. We are already exploring other model families for the Rubber Duck to pair with GPT-5.4 as the orchestrator.

Getting started

Rubber Duck is available today in experimental mode.

To start using it, install GitHub Copilot CLI, and run the /experimental slash command. Rubber Duck will be available when you select any Claude model from the model picker and have access enabled to GPT-5.4. You’ll see critiques surface in two ways:

• Automatically, when Copilot decides a checkpoint warrants a second opinion: after planning, after complex implementations, or after writing tests.
• On demand, whenever you ask. Just tell Copilot to critique its work, and it will invoke Rubber Duck, incorporate the feedback, and show you exactly what changed.

Where Rubber Duck helps most:

• Complex refactors and architectural changes
• High-stakes tasks where a miss is costly
• Ensuring comprehensive test coverage
• Any time you want a second opinion on a plan before committing to it

The post GitHub Copilot CLI combines model families for a second opinion appeared first on The GitHub Blog.

Resiliency in the cloud reflects different priorities from consistent performance, to withstanding failures, to predictable recovery. These map to reliability, resiliency, and recoverability, which together guide how workloads should be designed on Azure. This post extends foundational guidance with practical multi‑region design decisions, including when to use availability zones, paired regions, and non‑paired regions to meet business continuity goals.  

Reliability in Azure isn’t defined by a single recommendation, but by a set of architectural patterns designed to balance cost, complexity, recovery speed, and operational effort—because no single approach fits every workload. While disaster recovery is a common driver for multi‑region designs, long‑term scale planning also matters.  Azure regions operate within defined physical and latency boundaries, and large-scale workloads may eventually approach the practical capacity limits of a single region. 

This post introduces four resilience patterns, outlining when and why to use each so you can assess options based on your non‑functional requirements. It also explains how availability zone–based designs can often provide an alternative to paired regions as a default choice. 

The main resiliency patterns Here are a few common reliability and availability architecture patterns: 

1. In-region High Availability (HA) with Availability Zones (AZ): Maximize availability within a single Azure region by deploying across multiple availability zones. 
2. Regional Business Continuity and Disaster Recovery (BCDR): A primary/secondary region strategy implemented across separate Azure regions, selected based on geographic risk boundaries, regulatory requirements, and service availability. Recovery sequencing and failover behaviors are defined by workload dependencies and organizational requirements. 
3. Non-paired region BCDR: A primary/secondary region strategy where the secondary region is chosen based on requirements such as capacity, service availability, data residency, and network latency. This approach also supports long‑term scale planning, since Azure regions operate within physical datacenter footprints and latency boundaries and can reach practical capacity limits as workloads grow. See multi‑region solutions in non‑paired regions. 
4. Multi-region active/active: Deploy workloads across multiple regions simultaneously so that each region can serve production traffic. This approach can provide both high availability and disaster resilience while improving global performance, but it introduces additional architectural complexity and operational overhead. 

The rest of this post helps you understand the tradeoffs across these patterns, enabling you to select the right approach per workload while avoiding unnecessary cost and operational complexity. 

First post in this series: Achieve agility and scale in a dynamic cloud world 

Why did Azure launch with paired regions? 

Launched in 2010, but rebranded to Microsoft Azure in 2014, the regions were introduced in pairs (West US & East US, West Europe & North Europe, Southeast Asia & East Asia) to align with common enterprise business continuity practices at the time. Many organizations operated multiple datacenters within the same geographic boundary, separated by sufficient distance to reduce shared risk while maintaining regulatory and operational alignment. This design mirrored familiar enterprise BCDR practices at the time and offered: 

• A familiar primary/secondary failover pattern consistent with enterprise BCDR strategies 

• Support for regulatory or data residency requirements that required disaster recovery within a defined geographic boundary 

• Turnkey replication capabilities for services such as Geo-Redundant Storage (GRS) 

• Platform-level sequencing of updates to reduce the likelihood of simultaneous regional impact 

• A defined regional recovery prioritization model for rare geography-wide incidents 

This model provided assurance that Azure could meet or exceed the resilience of legacy enterprise environments while simplifying early cloud adoption through predefined recovery patterns.  

However, Azure’s engineering strategy has evolved. Many services now support replication to a region of choice rather than being limited to predefined pairs. This provides architects with greater flexibility to select regions based on workload requirements, risk boundaries, compliance constraints, capacity considerations, and cost models. 

It’s important to recognize that regional parity is never guaranteed even between paired regions. Differences in service availability, supported SKUs, scale limits, capacity, cost and operational maturity must be explicitly accounted for in the workload design. 

How has cloud resilience evolved since launch? 

The introduction of Availability Zones in 2018 provides a significant advancement in Azure resilience. Availability Zones are physically isolated groups of data centers within a region; each zone has independent power, cooling and networking. Many Azure services (App Service, Storage, Azure SQL etc.) use zones to provide platform-managed resilience. In addition, customers can deploy zonal resources, such as virtual machines, into specific zones or distribute them across zones to design for higher availability. 

Where previously Azure regions were launched in pairs, since 2020, regions have been typically designed with multiple availability zones, without a paired region. This design enables: 

• High availability within a single region 

• Platform-managed resilience for most failure scenarios 

• Reduced need for multi-region deployments for standard high-availability requirements 

How should customers design for resilience when using both paired and non-paired regions? 

To decide which resiliency model makes sense, customers should start by defining clear expectations including uptime targets, recovery time objectives (RTO), recovery point objectives (RPO), latency tolerance, and data residency. These non-functional requirements should directly influence architectural decisions. 

In practice, High Availability (HA) and Disaster Recovery (DR) are differentiated by recovery objectives rather than geography. HA architectures target near-zero downtime and minimal data loss, while DR solutions allow for defined recovery time and acceptable data loss. 

While HA is commonly established within a region using availability zones, it can also be achieved across regions through active-active designs. Similarly, DR is typically implemented across regions using replication and failover strategies. 

HA: Availability Zones 

When designing high availability within a region, Azure builds on AZs with 2 models: 

Zone-redundant resources are replicated across multiple availability zones to ensure data remains accessible even if one zone fails. Some services provide built-in zone redundancy, while others require manual configuration. Typically, Microsoft chooses the zones used for your resources, though some services allow you to select them. 

Zonal resources are deployed in a single availability zone and do not provide automatic resiliency against zone outages. While faults in other zones do not affect them, ensuring resiliency requires deploying separate resources across multiple zones. Microsoft does not handle this process; you are responsible for managing failover if an outage occurs. 

The decision to design a zone-resilient architecture is critical for balancing availability requirements with cost and regional capacity constraints. Designing workloads to be resilient across availability zones is generally the preferred approach for improving availability and protecting against zone-level failures. Deploying workloads across availability zones can enhance fault tolerance and reduce downtime when supported by the Azure service being used. However, architects should still consider workload characteristics, cost implications, and potential latency impacts, which may vary depending on the services and architecture patterns involved. 

Ultimately, zone resiliency is an architectural decision that should be strategically aligned with business priorities and risk tolerance, not simply treated as a checkbox to be ticked during deployment. 

DR: Paired and Non-Paired Regions 

Region pairs should be viewed as an architectural choice rather than a rule. Historically, paired regions played a key role in minimizing correlated failures and streamlining platform updates and recovery processes. However, as the Azure Safe Deployment Practices (SDP) have matured, the advantages of region pairs have become more nuanced. Over time, SDP has evolved to support safer and more flexible change management through longer and more adaptable bake times, richer operational signal integration, and an expanded understanding of regional deployment boundaries. These improvements enable Azure to release changes more safely across a growing and increasingly diverse regional footprint, while still balancing reliability with time‑to‑market. As a result, regional pairs are no longer the sole mechanism for managing correlated change risk, but one of several architectural tools customers can apply based on their resiliency and compliance needs. 

Using non-paired regions or a mix of paired and non-paired regions allows customers to design high availability and disaster recovery architectures that are driven by business, compliance, and application requirements rather than fixed regional relationships. This enables customers to optimize data residency, regulatory boundaries, latency to specific user populations, and provide differentiated recovery objectives across their workloads. This approach can also reduce exposure to rare but high-impact platform-level events by avoiding tightly coupled regional behaviors. 

While some Azure services natively simplify replication and recovery within paired regions, and others support replication across arbitrary regions (such as Azure SQL, Cosmos DB, and Azure Blob Storage with object replication), non-paired designs encourage explicit, workload-aware resiliency strategies such as application-level replication, asynchronous data sync, and failover orchestration. Although this introduces more architectural responsibility and may require compensating for paired region features, it delivers greater transparency, predictable recovery behavior, and alignment with business-driven RTO/RPO requirements rather than platform defaults. Regional failover is a customer‑orchestrated decision; customers should design, test, and operate their own failover and failback processes rather than assuming platform‑initiated regional failover. 

Designing for regional resilience requires distinguishing between workload mobility and data protection. Azure provides two complementary capabilities that address these needs differently: Azure Site Recovery (ASR) and Azure Backup. 

Azure Site Recovery (ASR) enables near‑continuous replication and orchestrated failover of virtual machine–based workloads to a region of choice, not limited to paired regions. ASR is the primary mechanism for customers who need low RPO, controlled failover, and workload restart in a secondary region. This is especially relevant for regions without a paired region or where the paired region does not meet capacity, service availability, or compliance needs. 

Azure Backup provides durable, policy‑based data protection, independent of compute availability. While Azure Backup is not a high‑availability or infrastructure failover solution, it plays a critical role when services do not support region‑of‑choice replication natively. In these scenarios, backup and restore become the recovery mechanism. 

These two services are often used together: ASR for VM‑level workload continuity, and Azure Backup for protecting and restoring data across regions, including to non‑paired regions. 

I am using paired regions today – does this mean I need to change my architecture? 

If your current architecture is built around paired regions for compliance, data residency, or strict disaster recovery objectives, that model stays valid and supported. Azure continues to support paired regions providing prioritized recovery sequencing, staggered platform updates, and geo-aligned data residency, all backed by Microsoft’s global infrastructure strategy. 

What has changed is that paired regions are no longer the only way to achieve enterprise-grade resilience. For many workloads that adopted a paired region (1+1) model primarily to protect against local datacenter failure, Availability Zones combined with geo-redundant services now provide equivalent or better protection with far less architectural complexity and cost. The shift to nonpaired regions is therefore not a forced migration, but an opportunity to simplify. Customers can continue using paired regions where business requirements demand it, while selectively modernizing other workloads to take advantage of platform-managed zone resilience. 

What’s coming up next for resilience in Azure? 

Resilience is evolving from static guidance to continuous, workload-aware execution. A multi-region strategy isn’t only about recovery; it’s also a practical hedge against regional capacity constraints (regions have physical limits within a latency boundary, so growth can eventually hit caps). 

• Resiliency agent in Azure Copilot (preview) helps you spot missing resiliency coverage—such as zone alignment gaps or missing backup/DR—and provides automated guidance (including scripts) to remediate issues, configure Azure Backup and Azure Site Recovery, and define recovery drills.  

• Resiliency in Azure brings zone resiliency, high availability, backup, DR, and ransomware protection together into a unified experience within Azure Copilot, enabling teams to set resiliency goals, receive proactive recommendations, and view service‑group insights via Azure portal.  

If you’re looking for service-specific BCDR and replication guidance, use these authoritative starting points: 

• Cloud Adoption Framework (CAF) – Landing zone design area (BCDR): guidance to define platform DR requirements (RTO/RPO), data residency considerations, and operational readiness as part of landing zone design.  

• Azure Well-Architected Framework (WAF) – Disaster recovery strategies: guidance for structuring, testing, and operating DR plans aligned to recovery targets, with links to companion DR planning resources.  

• WAF design guide – Regions & Availability Zones: how to choose between zone- vs region-based approaches and understand reliability/cost/performance tradeoffs.  

• Azure service reliability guides: service-by-service reliability/replication behavior and customer responsibilities.  

• Non‑paired multi‑region configurations: examples of supported multi-region approaches when regions aren’t paired.  

• Validate feasibility before you design: confirm service/SKU/zone availability in both regions. 

Next step: Explore Azure Essentials for guidance and tools to build secure, resilient, cost-efficient Azure projects. To see how shared responsibility and Azure Essentials come together in practice, read Resiliency in the cloud—empowered by shared responsibility and Azure Essentials  and How to design reliable, resilient, and recoverable workloads on Azure on the Microsoft Azure Blog. 

For expert-led, outcome-based engagements to strengthen resiliency and operational readiness, Microsoft Unified provides end-to-end support across the Microsoft cloud. To move from guidance to execution, start your project with experts and investments through Azure Accelerate. 

Related Resources 

• • Architecture strategies for using Availability Zones and Regions 

High Availability 

• • Architecture strategies for highly available multi-region design 

• • Disaster Recovery 

• • Architecture strategies for designing a Disaster Recovery strategy 

• • Multi-Region solutions in nonpaired Regions 

• • Develop a disaster recovery plan for multi-region deployments 

Azure Regions and Services 

• • Azure region pairs and nonpaired regions 

• • Reliability guides for Azure services 

Hello all!

Last September, we shared a preview of new information literacy features coming to Search Progress — designed to help students pause, think critically, and show their reasoning as they research online. Today, we’re excited to share that these features are generally available for all educators using Search Progress through Assignments in Teams for Education and the Microsoft 365 LTI®.

A special thank you to the educators who participated in the preview and shared feedback along the way; your insights helped shape these features into what they are today.

See it in action

Want a walkthrough before reading the details? Watch our Elevate Signature Series session, “Show Me Your Thinking,” where Dr. Geri Gillespy and I discuss future ready skills along with Search Progress setup, the full educator-to-student workflow, and how these skills connect to global assessment frameworks like PISA 2029.

Why process matters more than ever

Information literacy skills like verifying sources, understanding context, and thinking critically are foundational for responsible and effective navigation of online information. These skills become even more critical as AI becomes an integral part of learning and daily life, where students don’t just need access to information, they need to know how to evaluate it.

To ensure these features were developed in alignment with the latest in online reasoning research, we consulted with experts from the Digital Inquiry Group — a team with decades of experience as curriculum designers, classroom educators, researchers, and teacher educators — recognized with awards from UNESCO, the American Educational Research Association, and the School Library Association, to name a few.

What’s now available

The enhanced Search Progress features introduce structured activities and checkpoints — cognitive forcing functions that encourage students to pause, consider, and articulate their reasoning as they navigate the complex world of online information. Here’s what you can now enable for your assignments:

• Evaluating source reputability: Instead of relying solely on what a source says about itself, students investigate the individuals or organizations behind the information by looking into what other sources say about them, like how employers use references in a job interview.
• Cross-checking and lateral reading: “Using the internet to check the internet”, students compare information and perspectives across multiple sources to reveal patterns, differences, and possible inaccuracies.
• Impact awareness: Students consider what could be at risk if the information is inaccurate or fabricated with the new "factual importance" checkpoint. For instance, health advice carries different consequences than an AI-generated image of a cat dancing at the disco.
• Identifying source purpose: Information is created for a reason. Students consider who created a source, and whether it’s trying to inform, persuade, sell, or entertain.
• Metacognitive reflection: Students reflect on the research process itself including why certain sources stood out, which strategies worked best, and how to apply those learnings in the future.

Not just for research projects

These features aren’t only for formal research assignments. They’re designed for class activities that involve online research, whether students are exploring a new topic, gathering sources for a presentation, or verifying information for a discussion. The goal is to build habits that transfer throughout the digital information ecosystem, from navigating social media to evaluating AI-generated content. For example:

• A science educator assigns a pre-lab research task on chemical reactions. By enabling Source Reputation and Factual Importance, students learn to prioritize safety data sheets and academic sources over unverified blogs and to think about why accuracy matters when the stakes are high.
• A social studies educator uses Cross-check for an assignment focusing on current events. Students discover that a viral statistic has been reported differently across sources, and they practice tracing claims back to their origin — building lateral reading habits they’ll carry into their media consumption outside of school.

What educators are saying

Teacher librarians, in particular, have told us that the “process over product” approach gives them something they’ve been missing — visibility into the process of student inquiry, not just what they turn in. These features give them a window into the journey, not just the destination. With new scaffolds that support cross-checking and the investigation of source reputation, Search Progress now covers more of the skills they’ve been trying to teach.

We’ve heard from educators that the explanation prompts reveal a side of student thinking that traditional assignments don't often capture. During an early pilot, students pushed back on a text field that didn’t scroll to expand, not because they wanted less writing, but because they had more to say about why they chose their sources and wanted more space to explain their thinking. Students who described themselves as not being strong essay writers found a different way to show their thinking, and when they knew that their reasoning mattered as much as the final product, it changed how they engaged with the assignment.

Preparing students with future-ready skills for the age of AI

As educators worldwide work to build students’ information literacy skills, global frameworks are evolving to match. The OECD recently published a first draft of the PISA 2029 Media and Artificial Intelligence Literacy (MAIL) assessment framework — a new assessment that will measure 15-year-olds’ ability to critically evaluate digital and AI-generated content across all participating countries.

We were interested to see how closely the skills that Search Progress helps build align with the competences this framework describes. The MAIL assessment places significant emphasis on evaluating source credibility, assessing purpose and bias, and cross-checking information across multiple sources — all skills that Search Progress is designed to support through structured activities and checkpoints in the flow of research.

Educators have also shared that these features help address a tension many are navigating right now: how to maintain academic integrity when AI-generated work is increasingly difficult to distinguish from student work. Rather than relying on detection tools at the end of the pipeline, Search Progress makes the research process itself the artifact, which gives educators evidence of student thinking throughout. Of course, information literacy is broader than any single tool. The MAIL framework also includes competences around content creation and collaborative digital participation that go beyond what Search Progress currently addresses. But for the core skill of analysing and evaluating online information — which the framework highlights as one of its most heavily weighted competences — Search Progress can help you give your students meaningful practice right now.

By integrating these research habits into everyday assignments, you’re helping students build skills that will serve them well beyond any single assessment — from navigating social media to evaluating AI-generated content in their daily lives.

Getting started

1. Open Assignments in Teams for Education (or your LMS via the Microsoft 365 LTI).
2. Create a new assignment and select Search Progress as a Learning Accelerator.
3. Choose which information literacy features to enable for this assignment; you can mix and match based on the lesson.
4. Customize the checkpoint card prompts to fit your subject area and grade level.
5. Assign it to your class and watch the research process unfold.

Requirements

• Available to all Microsoft 365 Education customers
• Classes set up in Teams for Education or the Microsoft 365 LTI

Helpful links

• 📘 Take the MS Learn course — Intro course for educators
• 📘 Microsoft 365 LTI app overview — Bring Search Progress into your LMS
• 💬 Join the Education Insiders Program — Share feedback directly with our product team

We’re committed to helping you foster information and AI literacy, and your feedback continues to shape how these tools evolve. Join the Search Progress channel in the Education Insiders Program to connect with other educators, attend community calls, and share your experience directly with the product team. If you’re not yet an EIP member, sign up here: aka.ms/JoinEIP.

Have questions or ideas? Drop them in the comments below. I’d love to hear how you’re using these features in your classroom!

Until next time,

Emma Gray
Product Manager II
Microsoft Education

Learning Tools Interoperability® (LTI®) is a trademark of the 1EdTech Consortium, Inc. (1edtech.org)

Why guardrails are essential for AI apps and agents

AI apps and agents introduce capabilities that go beyond traditional software. They reason over natural language, interact with data across boundaries, and—in the case of agents—can take autonomous actions using tools and APIs. Without clearly defined guardrails, these capabilities can unintentionally compromise confidentiality, integrity, and availability, the foundational pillars of information security. 

From a confidentiality perspective, AI systems often process sensitive prompts, contextual data, and outputs that may span customer tenants, subscriptions, or external systems. Guardrails ensure that data access is explicit, scoped, and enforced—rather than inferred through prompts or emergent model behavior. 

From an availability perspective, AI apps and agents can fail in ways traditional software does not — such as runaway executions, uncontrolled chains of tool calls, or usage spikes that drive up cost and degrade service. Guardrails address this by setting limits on how the system executes, how often it calls tools, and how it behaves when something goes wrong. 

For Marketplace-ready AI apps and agents, guardrails are foundational design elements that balance innovation with security, reliability, and responsible AI practices. By making behavioral boundaries explicit and enforceable, guardrails enable AI systems to operate safely at scale—meeting enterprise customer expectations and Marketplace requirements from day one. 

This post is part of a series on building and publishing well-architected AI apps and agents on Microsoft Marketplace. 

Using Open Worldwide Application Security Project (OWASP) GenAI Top 10 as a guardrail design lens

The OWASP GenAI Top 10 provides a practical framework for reasoning about AI‑specific risks that are not fully addressed by traditional application security models. It helps teams identify where assumptions about trust, input handling, autonomy, and data access are most likely to break down in AI‑driven systems. 

However, not all OWASP risks apply equally to every AI app or agent. Their relevance depends on factors such as: 

• Agent autonomy, including whether the system can take actions without human approval
• Data access patterns, especially cross‑tenant, cross‑subscription, or external data retrieval
• Integration surface area, meaning the number and type of tools, APIs, and external systems the agent connects to 

Because of this variability, OWASP should not be treated as a checklist to implement wholesale. Doing so can lead teams to over‑engineer controls in low‑risk areas while leaving critical gaps in places where autonomy, data movement, or tool execution create real exposure. Instead, OWASP is most effective when used as a design lens — to inform where guardrails are needed and what behaviors require explicit boundaries. 

Understanding risks and enforcing boundaries are two different things. OWASP tells you where to look; guardrails are what you actually build. The goal is not to eliminate all risk, but to use OWASP insights to design selective, intentional guardrails that align with the system's architecture, autonomy, and operating context. 

Translating AI risks into architectural guardrails

OWASP GenAI Top 10 helps identify where AI systems are vulnerable, but guardrails are what make those risks enforceable in practice. Guardrails are most effective when they are implemented as architectural constraints—designed into the system—rather than as runtime patches added after risky behavior appears. 

In AI apps and agents, many risks emerge not from a single component, but from how prompts, tools, data, and actions interact. Architectural guardrails establish clear boundaries around these interactions, ensuring that risky behavior is prevented by design rather than detected too late. 

Common guardrail categories map naturally to the types of risks highlighted in OWASP: 

• Input and prompt constraints 
  Address risks such as prompt injection, system prompt leakage, and unintended instruction override by controlling how inputs are structured, validated, and combined with system context. 

• Action and tool‑use boundaries 
  Mitigate risks related to excessive agency and unintended actions by explicitly defining which tools an AI app or agent can invoke, under what conditions, and with what scope. 

• Data access restrictions 
  Reduce exposure to sensitive information disclosure and cross‑boundary leakage by enforcing identity‑aware, context‑aware access to data sources rather than relying on prompts to imply intent. 

• Output validation and moderation 
  Help contain risks such as misinformation, improper output handling, or policy violations by treating AI output as untrusted and subject to validation before it is acted on or returned to users. 

What matters most is where these guardrails live in the architecture. Effective guardrails sit at trust boundaries—between users and models, models and tools, agents and data sources, and control planes and data planes. When guardrails are embedded at these boundaries, they can be applied consistently across environments, updates, and evolving AI capabilities. 

By translating identified risks into architectural guardrails, teams move from risk awareness to behavioral enforcement. This shift is foundational for building AI apps and agents that can operate safely, predictably, and at scale in Marketplace environments. 

Design‑time guardrails: shaping allowed behavior before deployment

The OWASP GenAI Top 10 provides a practical framework for reasoning about AI specific risks that are not fully addressed by traditional application security models. It helps teams identify where assumptions about trust, input handling, autonomy, and data access are most likely to break down in AI driven systems. 

However, not all OWASP risks apply equally to every AI app or agent. Their relevance depends on factors such as: 

• Agent autonomy, including whether the system can take actions without human approval 
• Data access patterns, especially cross-tenant, cross subscription, or external data retrieval
• Integration surface area, meaning the number and type of tools, APIs, and external systems the agent connects to 

Because of this variability, OWASP should not be treated as a checklist to implement wholesale. Doing so can lead teams to over engineer controls in low risk areas while leaving critical gaps in places where autonomy, data movement, or tool execution create real exposure. Instead, OWASP is most effective when used as a design lens — to inform where guardrails are needed and what behaviors require explicit boundaries. 

Understanding risks and enforcing boundaries are two different things. OWASP tells you where to look; guardrails are what you actually build. The goal is not to eliminate all risk, but to use OWASP insights to design selective, intentional guardrails that align with the system's architecture, autonomy, and operating context. 

Runtime guardrails: enforcing boundaries as systems operate

For Marketplace publishers, the key distinction between monitoring and runtime guardrails is simple: 

• Monitoring tells you what happened after the fact.
• Runtime guardrails are inline controls that can block, pause, throttle, or require approval before an action completes. 

If you want prevention, the control has to sit in the execution path. At runtime, guardrails should constrain three areas: 

1. Agent decision paths (prevent runaway autonomy)
   • Cap planning and execution. Limit the agent to a maximum number of steps per request, enforce a maximum wall‑clock time, and stop repeated loops.
   • Apply circuit breakers. Terminate execution after a specified number of tool failures or when downstream services return repeated throttling errors.
   • Require explicit escalation. When the agent’s plan shifts from “read” to “write,” pause and require approval before continuing.
2. Tool invocation patterns (control what gets called, how, and with what inputs)
   • Enforce allowlists. Allow only approved tools and operations, and block any attempt to call unregistered endpoints.
   • Validate parameters. Reject tool calls that include unexpected tenant identifiers, subscription scopes, or resource paths.
   • Throttle and quota. Rate‑limit tool calls per tenant and per user, and cap token/tool usage to prevent cost spikes and degraded service.
3. Cross‑system actions (constrain outbound impact at the boundary you control) Runtime guardrails cannot “reach into” external systems and stop independent agents operating elsewhere. What publishers can do is enforce policy at your solution’s outbound boundary: the tool adapter, connector, API gateway, or orchestration layer that your app or agent controls. Concrete examples include:
   • Block high‑risk operations by default (delete, approve, transfer, send) unless a human approves.
   • Restrict write operations to specific resources (only this resource group, only this SharePoint site, only these CRM entities).
   • Require idempotency keys and safe retries so repeated calls do not duplicate side effects.
   • Log every attempted cross‑system write with identity, scope, and outcome, and fail closed when policy checks cannot run. 

Done well, runtime guardrails produce evidence, not just intent. They show reviewers that your AI app or agent enforces least privilege, prevents runaway execution, and limits blast radius—even when the model output is unpredictable. 

Guardrails across data, identity, and autonomy boundaries

Guardrails don't work in silos. They are only effective when they align across the three core boundaries that shape how an AI app or agent operates — identity, data, and autonomy.  

Guardrails must align across: 

• Identity boundaries (who the agent acts for) — represent the credentials the agent uses, the roles it assumes, and the permissions that flow from those identities. Without clear identity boundaries, agent actions can appear legitimate while quietly exceeding the authority that was actually intended.
• Data boundaries (what the agent can see or retrieve) — ensuring access is governed by explicit authorization and context, not by what the model infers or assumes. A poorly scoped data boundary doesn't just create exposure — it creates exposure that is hard to detect until something goes wrong.
• Autonomy boundaries (what the agent can decide or execute) — defining which actions require human approval, which can proceed automatically, and which are never permitted regardless of context. Autonomy without defined limits is one of the fastest ways for behavior to drift beyond what was ever intended. 

When these boundaries are misaligned, the consequences are subtle but serious. An agent may act under the authority of one identity, access data scoped to another, and execute with broader autonomy than was ever granted — not because a single control failed, but because the boundaries were never reconciled with each other. This is how unintended privilege escalation happens in well-intentioned systems.  

Balancing safety, usefulness, and customer trust

Getting guardrails right is less about adding controls and more about placing them well. Too restrictive, and legitimate workflows break down, safe autonomy shrinks, and the system becomes more burden than benefit. Too permissive, and the risks accumulate quietly — surfacing later as incidents, audit findings, or eroded customer trust. 

Effective guardrails share three characteristics that help strike that balance: 

• Transparent — customers and operators understand what the system can and cannot do, and why those limits exist 
• Context-aware — boundaries tighten or relax based on identity, environment, and risk, without blocking safe use
• Adjustable — guardrails evolve as models and integrations change, without compromising the protections that matter most 

When these characteristics are present, guardrails naturally reinforce the foundational principles of information security — protecting confidentiality through scoped data access, preserving integrity by constraining actions to authorized paths, and supporting availability by preventing runaway execution and cascading failures. 

How guardrails support Marketplace readiness

For AI apps and agents in Microsoft Marketplace, guardrails are a practical enabler — not just of security, but of the entire Marketplace journey. They make complex AI systems easier to evaluate, certify, and operate at scale. 

Guardrails simplify three critical aspects of that journey: 

• Security and compliance review — explicit, architectural guardrails give reviewers something concrete to assess. Rather than relying on documentation or promises, behavior is observable and boundaries are enforceable from day one.
• Customer onboarding and trust — when customers can see what an AI system can and cannot do, and how those limits are enforced, adoption decisions become easier and time to value shortens. Clarity is a competitive advantage.
• Long-term operation and scale — as AI apps evolve and integrate with more systems, guardrails keep the blast radius contained and prevent hidden privilege escalation paths from forming. They are what makes growth manageable. 

Marketplace-ready AI systems don't describe their guardrails — they demonstrate them. That shift, from assurance to evidence, is what accelerates approvals, builds lasting customer trust, and positions an AI app or agent to scale with confidence. 

What’s next in the journey

Guardrails establish the foundation for safe, predictable AI behavior — but they are only the beginning. The next phase extends these boundaries into governance, compliance, and day‑to‑day operations through policy definition, auditing, and lifecycle controls. Together, these mechanisms ensure that guardrails remain effective as AI apps and agents evolve, scale, and operate within enterprise environments. 

Key resources 

See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor, 

Quick-Start Development Toolkit can connect you with code templates for AI solution patterns 

Microsoft AI Envisioning Day Events  

How to build and publish AI apps and agents for Microsoft Marketplace 

Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV Success 

• Migrating from mypy to ty: Lessons from FastAPI
• Oxyde ORM
• Typeshedded CPython docs
• Raw+DC Database Pattern: A Retrospective
• Extras
• Joke

About the show

Sponsored by us! Support our work through:

• Our courses at Talk Python Training
• The Complete pytest Course
• Patreon Supporters

Connect with the hosts

• Michael: @mkennedy@fosstodon.org / @mkennedy.codes (bsky)
• Brian: @brianokken@fosstodon.org / @brianokken.bsky.social
• Show: @pythonbytes@fosstodon.org / @pythonbytes.fm (bsky)

Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Monday at 11am PT. Older video versions available there too.

Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it.

Brian #1: Migrating from mypy to ty: Lessons from FastAPI

• Tim Hopper
• I saw this post by Sebastián Ramírez about all of his projects switching to ty
  • FastAPI, Typer, SQLModel, Asyncer, FastAPI CLI
• SqlModel is already ty only - mypy removed
• This signals that ty is ready to use
• Tim lists some steps to apply ty to your own projects
  • Add ty alongside mypy
  • Set error-on-warning = true
  • Accept the double-ignore comments
  • Pick a smaller project to cut over first
  • Drop mypy when the noise exceeds the signalAdd ty alongside mypy
• Related anecdote:
  • I had tried out ty with pytest-check in the past with difficulty
  • Tried it again this morning, only a few areas where mypy was happy but ty reported issues
  • At least one ty warning was a potential problem for people running pre-releases of pytest,
  • Not really related: packaging.version.parse is awesome

Michael #2: Oxyde ORM

• Oxyde ORM is a type-safe, Pydantic-centric asynchronous ORM with a high-performance Rust core.
• Note: Oxyde is a young project under active development. The API may evolve between minor versions.
• No sync wrappers or thread pools. Oxyde is async from the ground up
• Includes oxyde-admin
• Features
  • Django-style API - Familiar Model.objects.filter() syntax
  • Pydantic v2 models - Full validation, type hints, serialization
  • Async-first - Built for modern async Python with asyncio
  • Rust performance - SQL generation and execution in native Rust
  • Multi-database - PostgreSQL, SQLite, MySQL support
  • Transactions - transaction.atomic() context manager with savepoints
  • Migrations - Django-style makemigrations and migrate CLI

Brian #3: Typeshedded CPython docs

• Thanks emmatyping for the suggestion
• Documentation for Python with typeshed types
• Source: typeshedding_cpython_docs

Michael #4: Raw+DC Database Pattern: A Retrospective

• A new design pattern I’m seeing gain traction in the software space: Raw+DC: The ORM pattern of 2026
• I’ve had a chance to migrate three of my most important web app.
• Thrilled to report that yes, the web app is much faster using Raw+DC
• Plus, this was part of the journey to move from 1.3 GB memory usage to 0.45 GB (more on this next week)

Extras

Brian:

• Lean TDD 0.5 update
  • Significant rewrite and focus

Michael:

• pytest-just (for just command file testing), by Michael Booth
• Something going on with Encode
  • httpx: Anyone know what's up with HTTPX? And forked
  • starlette and uvicorn: Transfer of Uvicorn & Starlette
  • mkdocs: The Slow Collapse of MkDocs
  • django-rest-framework: Move to django commons?
• Certificates at Talk Python Training

Joke:

• Neue Rich

After July 9, 2026, the Azure SDK for JavaScript will no longer support Node.js 20.x, which reaches end-of-life on April 30, 2026. We encourage you to upgrade to an Active Node.js Long Term Support (LTS) version.

Why are we doing it?

Node.js has a well-defined release schedule, with each even-numbered version enjoying an Active LTS period followed by a Maintenance LTS period before eventually reaching end-of-life. Once a Node.js version moves out of Maintenance, it no longer receives bug fixes or security updates. To ensure we’re providing up-to-date and secure libraries, we routinely drop support for Node.js versions that reached end-of-life.

As a reminder of the Azure SDK for JavaScript support policy, dropping support for such Node.js versions may be done without increasing the major version of the Azure SDK libraries.

What happens on July 9, 2026?

On July 9, 2026, the Azure SDK for JavaScript will specify Node.js 22.x as the minimum supported version in its engines field. If you’re using Node.js 20.x, installing the later versions of the SDK causes an engine deprecation warning to appear. If you set engine-strict=true, an npm installation error occurs.

The Azure SDK for JavaScript library versions released without Node.js 20.x support may continue to work on Node.js 20.x. This doesn’t imply a continuation of support. You can continue to use older versions of the libraries with Node.js 20.x, but we strongly recommend upgrading to a supported Node.js version to receive the latest features and security updates.

Azure SDK support policies

For more information on maintenance and support policies, see the Azure SDK support policy and the Azure SDK for JavaScript support policy.

What should you do?

To ensure you’re using a supported version of Node.js, we recommend upgrading to the latest Active LTS version. You can find the latest LTS version of Node.js on the Node.js website.

The post Announcing the end of support for Node.js 20.x in the Azure SDK for JavaScript appeared first on Azure SDK Blog.