Azure/GPT-RAG: an IaC accelerator for agentic RAG on Microsoft Foundry
Enterprise-grade accelerator for agentic RAG on Azure. Built on Microsoft Foundry with Foundry IQ as the default retrieval backend, Microsoft Agent Framework orchestration, Zero-Trust architecture and IaC.
At a glance
- What is it?
- GPT-RAG ships Bicep and azd templates that stand up an agentic RAG stack on Microsoft Foundry, with Foundry IQ as the default retrieval backend and Azure AI Search direct kept as a rollback path. The interesting part is not the retrieval chain but the identity contract that decides whether hosted conversation continuity runs at all.
- Who is it for?
- Adopt GPT-RAG if you are standardising on Microsoft Foundry, want Foundry IQ as the retrieval plane, and can staff the Zero-Trust or network-isolated deployment path including the jumpbox workflow. Do not adopt it if you need a retrieval stack that runs outside Azure or a small single-service deployment you can read end to end in an afternoon.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem GPT-RAG is aimed at: assembling an agentic RAG stack on Azure without hand-wiring every service
Most teams building retrieval-augmented generation on Azure do not fail at the prompt. They fail at the seam between the retrieval index, the agent runtime, the identity model, and the network boundary. GPT-RAG is a solution accelerator, which in Microsoft's vocabulary means architecture templates plus deployment assets rather than a library you import. The repository describes itself as providing architecture templates and deployment assets to help organizations build agentic RAG solutions on Microsoft Foundry, with orchestration on the Microsoft Agent Framework and Foundry IQ as the default retrieval backend. The intended audience is platform and application teams inside organisations that already have an Azure footprint and a compliance surface to satisfy. The README lists customer support and decision automation as example scenarios, and names NL2SQL query generation, multi-source grounding, and MCP tool integration as supported agent capabilities. If you are a solo developer prototyping a chatbot over three PDFs, this is a large amount of scaffolding for the job.
Foundry IQ as the retrieval plane, with Azure AI Search direct as the escape hatch
The retrieval design is the part worth reading closely. Foundry IQ is the default backend, and the README says it blends Blob, Azure AI Search, Work IQ, Fabric, SharePoint, OneLake, Web and MCP sources with permission trimming. That list is the actual value proposition: one retrieval surface over sources that would otherwise each need their own connector, chunking strategy, and ACL mapping. Permission trimming is the mechanism that matters for enterprise adoption, because a retrieval layer that ignores source permissions is unusable in most regulated environments. The documentation also states that Azure AI Search direct remains fully supported as a rollback path. Treat that sentence as a design admission rather than a marketing line. It means the accelerator's authors expect some teams to conclude that the Foundry IQ abstraction does not fit their index topology, their ranking requirements, or their latency budget, and to drop back to querying Azure AI Search themselves. The grounding sources overview page is where the choice between these paths is documented, and it is the first thing to read before deploying anything.
Two identity planes: the hosted continuity contract and the Zero-Trust role model
The most specific technical content in the README is the hosted conversation continuity section, and it is unusually blunt. Hosted continuity uses Responses protocol 2.0.0 with delegated x-ms-user-identity ownership from the trusted UI BFF. Activation fails closed until the UI identity has the exact Foundry Agent Consumer role and GPT-RAG user-identity impersonation role directly at the individual agent scope. The word directly is doing real work here: role inheritance from a resource group or subscription is not enough. The same section states that the hosted container receives neither role, no ownership key, and no Cosmos DB in the no-panel topology. So the trust boundary is drawn between the UI backend-for-frontend and the agent, with the container deliberately holding nothing that would let it impersonate a user. The contracts/README.md file is cited as the source for role IDs, validation rules, and the disabled capability fallback. This is the kind of detail that determines whether a deployment works on the first attempt, and it is buried one level down in a contracts directory rather than in the deployment guide's main flow.
Deployment paths: Basic, Zero Trust, and network-isolated
The deployment guide covers three modes: Basic, Zero Trust, and network-isolated, along with preflight checks, a jumpbox workflow, and container image builds. The README does not reproduce the azd commands or the Bicep parameter names, so the exact invocation has to come from the documentation site rather than from this article. What the repository metadata does tell you is the toolchain: the front matter declares azdeveloper, powershell, and bicep as the languages, and the topics list includes azd-templates. That combination means the expected entry point is the Azure Developer CLI against a template, with PowerShell and Bicep doing the provisioning work. The jumpbox workflow exists because the network-isolated mode puts the services somewhere you cannot reach from a laptop. Plan for that: a network-isolated deployment is not a one-command experience, and the jumpbox step is where teams without an existing operations pattern will spend their time. The preflight checks are the mitigation the project offers, and running them before provisioning is cheaper than debugging a partially applied deployment.
Where GPT-RAG stops being the right tool
The accelerator assumes Azure and assumes Microsoft Foundry. The orchestration layer is the Microsoft Agent Framework and the retrieval default is Foundry IQ, so a team running inference on another cloud or on self-hosted models is fighting the template rather than using it. The Zero-Trust posture is a second constraint. Tightly governed network access and least-privilege communication between services are the point, but they also mean every new service you add has to be threaded through the same identity and network model. Teams that want to attach a quick internal tool will find the path longer than they expect. There is a third, quieter limitation in the continuity design: activation fails closed. If the role assignment is wrong, or assigned at the wrong scope, hosted continuity does not degrade gracefully, it does not start. That is the correct security choice and a poor debugging experience, which is precisely why the contracts file is worth reading before the first deployment rather than after. Finally, the README does not state supported model versions beyond the gpt-4 topic tag, so verify model availability in your region against the documentation rather than assuming it.
How this differs from assembling the same stack from Azure AI Search and a framework of your choice
The obvious alternative is to build the same thing yourself: Azure AI Search as the index, an orchestration library of your choosing, and your own identity plumbing. The difference in approach is that GPT-RAG treats retrieval as a federated capability rather than a single index. Foundry IQ is documented as blending Blob, Work IQ, Fabric, SharePoint, OneLake, Web and MCP sources with permission trimming applied across them. Replicating that by hand means writing and maintaining a connector per source, plus a permission mapping per source, plus a merge and ranking strategy across the results. That is months of work, and it is the work the accelerator exists to skip. The trade is control. A hand-built Azure AI Search pipeline gives you direct ownership of the index schema, the scoring profile, and the chunking, with no abstraction in between. The accelerator's own rollback path acknowledges this: Azure AI Search direct stays supported, so you can keep the deployment scaffolding and replace the retrieval layer. That is a more useful escape hatch than a full fork.
Maintenance, versioning, and what the MIT licence does and does not cover
The repository is active rather than archived, with a last push in September 2026 and three patch releases in the v3.8.x line within the same month. That release cadence is a signal about how the project is maintained: frequent small releases rather than long-lived major versions. For an accelerator that provisions cloud infrastructure, a fast patch cadence means you should expect to re-run deployments and re-check role assignments when you upgrade, particularly around the continuity contract. The licence is MIT, which is permissive and permits modification and redistribution, but the README's trademark section adds a constraint that sits outside the licence: authorised use of Microsoft trademarks and logos must follow Microsoft's trademark and brand guidelines, and modified versions must not imply sponsorship or cause confusion. If you fork the UI and keep the branding, that section applies to you. This is a description of what the repository states, not legal advice; get your own counsel for a commercial redistribution. The practical maintenance cost is the one the architecture implies rather than one the README quantifies: every service you add inherits the Zero-Trust network and identity model, so the marginal cost of the tenth component is higher here than in a flat deployment.
Editorial conclusion
Adopt GPT-RAG if you are standardising on Microsoft Foundry, want Foundry IQ as the retrieval plane, and can staff the Zero-Trust or network-isolated deployment path including the jumpbox workflow. Do not adopt it if you need a retrieval stack that runs outside Azure or a small single-service deployment you can read end to end in an afternoon. Before committing, verify the exact role IDs and validation rules in contracts/README.md against your tenant, and confirm whether your scenario needs hosted conversation continuity at all, because that capability fails closed until the UI identity holds both roles at the individual agent scope.
Community notes