Foundry IQ is a managed knowledge layer for Microsoft Foundry that connects enterprise data into reusable, permission-aware knowledge bases for AI agents. Teams use it to ground agents in approved enterprise knowledge from Azure, SharePoint, OneLake, the web, and Azure AI Search-backed knowledge bases while preserving permissions and reusable retrieval configuration. It is not a general data lake, a replacement for source-system permissions, a guarantee that retrieved content is correct, or a reason to skip citation, freshness, and access reviews.
Microsoft Foundry IQ, Foundry IQ knowledge base, managed knowledge layer, permission-aware knowledge base
Difficulty
intermediate
CLI mappings
6
Last verified
2026-05-14
Microsoft Learn
Foundry IQ is a managed knowledge layer for Microsoft Foundry that connects enterprise data into reusable, permission-aware knowledge bases for AI agents.
Technically, the Foundry IQ is configured or observed through Foundry IQ knowledge bases, Foundry Agent Service, Azure AI Search agentic retrieval, data sources, indexes, knowledge connectors, permissions, citations, retrieval configuration, grounding traces, and project-level agent integration. It depends on source connectivity, Azure AI Search knowledge base requirements, identity and permission mapping, content freshness, indexing quality, semantic configuration, data classification, citation handling, agent instructions, and evaluation tests. Operators inspect it through the Azure portal, ARM or Bicep, Azure CLI, SDK or REST calls, Azure Monitor, diagnostic logs, and application telemetry.
Why it matters
Foundry IQ matters because it gives AI agents a governed reusable knowledge layer instead of forcing each agent team to rebuild retrieval, indexing, and permission checks separately. Without clear vocabulary, teams may expose documents beyond source permissions, ground answers in stale content, duplicate retrieval stacks, hide citation failures, or assume a knowledge base makes agent output automatically correct. It also affects security, reliability, operations, cost, and performance because one configuration choice can change who can act, what fails, how quickly work completes, what evidence exists, and how much the platform costs. Good glossary discipline helps teams ask who owns it, what depends on it, which metric proves health, and what rollback path exists before a release.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
A Foundry Agent configuration references a Foundry IQ knowledge base, backing Azure AI Search resource, data sources, citation settings, and retrieval tool behavior. Review scope, owners, metrics, and rollback evidence.
Signal 02
Monitoring shows indexing status, search query latency, retrieval failures, permission filtering problems, missing citations, or agent responses grounded in stale content. Review scope, owners, metrics, and rollback evidence.
Signal 03
Governance records mention SharePoint, OneLake, Azure data, web sources, permission-aware knowledge, search indexes, citations, and reusable grounding for several agents. Review scope, owners, metrics, and rollback evidence.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Create a reusable permission-aware knowledge base that multiple Foundry agents can use for grounded retrieval.
Troubleshoot uncited, stale, or low-quality agent answers by reviewing search index health, source freshness, and retrieval configuration.
Review enterprise data connections, permissions, and citations before exposing an agent to production users.
Support incident response by correlating Azure configuration, diagnostic logs, metrics, deployment history, and application traces.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Foundry IQ in action for legal technology
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Northstar LegalOps, a legal technology organization, needed to solve a production challenge: contract review agents answered policy questions from outdated documents scattered across SharePoint and a data lake. The architecture team used Foundry IQ to make the design measurable, governable, and easier to support.
🎯Business/Technical Objectives
Use approved knowledge sources
Preserve document permissions
Require citations in answers
Reduce duplicate retrieval work
✅Solution Using Foundry IQ
Architects built a Foundry IQ knowledge base backed by Azure AI Search, connected approved SharePoint and lake sources, and attached it to two Foundry Agents. Evaluations failed responses without citations or stale policy references. Before cutover, engineers captured read-only configuration, validated identity and network access, compared expected behavior with Azure Monitor or service logs, and stored rollback instructions in the change record. Operators received a runbook with first-response checks, known failure modes, owner contacts, and escalation paths. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state.
📈Results & Business Impact
Duplicate RAG indexes were retired
Responses included approved citations
Permission reviews matched source systems
Policy-answer escalations dropped by 39 percent
💡Key Takeaway for Glossary Readers
Foundry IQ makes grounding reusable, but source freshness and permission proof still need active governance.
Case study 02
Foundry IQ in action for manufacturing
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Apex Equipment, a manufacturing organization, needed to solve a production challenge: field-service agents needed repair guidance from manuals, bulletins, and known-issue records without exposing restricted engineering notes. The architecture team used Foundry IQ to make the design measurable, governable, and easier to support.
🎯Business/Technical Objectives
Ground repair answers in approved content
Filter restricted documents
Improve technician response time
Track retrieval quality
✅Solution Using Foundry IQ
The team connected approved manuals and service bulletins to Foundry IQ, kept restricted notes out of the knowledge base, and attached the base to a troubleshooting agent. Traces captured retrieved passages and citations. Before cutover, engineers captured read-only configuration, validated identity and network access, compared expected behavior with Azure Monitor or service logs, and stored rollback instructions in the change record. Operators received a runbook with first-response checks, known failure modes, owner contacts, and escalation paths. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state.
📈Results & Business Impact
Technician search time fell by 52 percent
Restricted engineering notes were excluded
Uncited answers triggered review
Retrieval metrics guided source cleanup
💡Key Takeaway for Glossary Readers
A permission-aware knowledge layer is only as safe as the source boundaries it enforces.
Case study 03
Foundry IQ in action for employee benefits
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
GreenLine Benefits, a employee benefits organization, needed to solve a production challenge: HR support agents needed consistent policy answers across regional benefit documents and annual plan updates. The architecture team used Foundry IQ to make the design measurable, governable, and easier to support.
🎯Business/Technical Objectives
Answer from current policy documents
Support regional differences
Lower HR ticket volume
Validate content freshness monthly
✅Solution Using Foundry IQ
Foundry IQ connected current benefits documents, used metadata for region filtering, and exposed the knowledge base to an HR agent. Monthly checks compared index freshness with the authoritative policy repository. Before cutover, engineers captured read-only configuration, validated identity and network access, compared expected behavior with Azure Monitor or service logs, and stored rollback instructions in the change record. Operators received a runbook with first-response checks, known failure modes, owner contacts, and escalation paths. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state. The team also reviewed owner tags, diagnostic coverage, alert routing, and incident communication paths so support could confirm the workflow without changing production state.
📈Results & Business Impact
Routine HR tickets dropped by 31 percent
Regional answers cited correct plan documents
Monthly freshness checks caught one stale source
Agent evaluations improved after metadata cleanup
💡Key Takeaway for Glossary Readers
Foundry IQ turns enterprise knowledge into an operational asset when freshness, metadata, and citations are measurable.
Why use Azure CLI for this?
Azure CLI helps validate Foundry IQ because it captures reproducible evidence for scope, configuration, permissions, runtime state, diagnostics, and related resources before a production change.
CLI use cases
List or show Azure resources and related configuration for Foundry IQ.
Capture read-only evidence before changing identity, networking, triggers, capacity, policy, deployment, or automation settings.
Compare Azure metrics, logs, run history, deployment operations, and application evidence during production incidents.
Before you run CLI
Confirm the tenant, subscription, resource group, resource names, environment, and time window are the intended scope.
Run read-only list, show, metrics, operation, or query commands before any create, update, delete, start, stop, policy, or deployment change.
Get approval for mutating commands because configuration changes can expose data, break workflows, increase cost, or alter compliance evidence.
What output tells you
Resource IDs, enabled state, configuration values, identity settings, network posture, and ownership metadata show the current design.
Metrics, logs, run history, or deployment operations show whether the platform behaved as expected during the reviewed time window.
Application and downstream evidence shows whether the issue is Azure configuration, permissions, client behavior, data readiness, or business processing.
Mapped Azure CLI commands
Some evidence is visible only in service logs, SDK behavior, deployment output, SQL metadata, portal configuration, or application telemetry; Azure CLI still validates surrounding resources and operational scope.
Architecture context
Foundry IQ is the managed knowledge layer that connects Microsoft Foundry agents to reusable, permission-aware knowledge bases, commonly backed by Azure AI Search agentic retrieval. Architecturally, I place it between enterprise data sources and agent tools, where retrieval quality, identity trimming, citations, and source freshness matter more than raw document volume. The design includes knowledge source selection, indexing strategy, permissions, project connections, managed identity, tenant alignment, citation behavior, and monitoring of retrieval results. I review it with data owners because a knowledge base can expose stale, sensitive, or misleading information if source governance is weak. The best designs keep ingestion, retrieval, and agent instructions explicit so grounded answers can be audited.
Security
Security for the Foundry IQ starts with knowing who can create knowledge bases, connect enterprise data, approve source permissions, query retrieved content, view citations and traces, manage search indexes, and attach knowledge to agents. Review knowledge base name, project, backing search resource, data sources, permission model, index freshness, citation behavior, retrieval settings, connected agents, evaluation results, and owner review cadence before approving production changes. Prefer managed identity and Microsoft Entra ID where the service supports it, keep secrets in approved vaults, scope roles narrowly, and protect diagnostics that may reveal sensitive names, payloads, or operational patterns. During audits, capture Activity Log entries, role assignments, network settings, diagnostic settings, and owner approvals so teams can prove access and behavior were intentional.
Cost
Cost for the Foundry IQ is driven by Azure AI Search capacity, indexing volume, storage, retrieval calls, connector processing, evaluation runs, duplicate knowledge bases, trace retention, and human review after low-confidence or uncited answers. The expensive mistake is not only Azure consumption; it is also duplicate processing, failed retries, audit cleanup, manual investigations, and unnecessary capacity caused by weak design evidence. Review whether the workload truly needs the selected tier, frequency, retention, diagnostics, network path, and automation pattern. Use tags, budgets, alerts, and recurring reviews so teams can explain why the current design exists and remove stale resources safely. This keeps Foundry IQ review specific across architecture, security, operations, and incident response.
Reliability
Reliability for the Foundry IQ depends on source availability, indexing jobs, search service health, permission synchronization, retrieval quality, citation generation, content freshness, agent integration, and fallback behavior when grounding is missing or stale. A healthy Azure resource can still fail the business workflow if downstream services, identities, triggers, clients, or data contracts are wrong. Test retries, failover assumptions, disabled states, stale configuration, private DNS problems, timeout behavior, and duplicate processing before relying on the design. Keep runbooks for first-response checks, known limits, owner escalation, and rollback so support teams can recover without guessing. This keeps Foundry IQ review specific across architecture, security, operations, and incident response.
Performance
Performance for the Foundry IQ depends on index size, retrieval strategy, semantic ranking, vector search settings, connector latency, search service capacity, permission filtering, number of sources, query complexity, and agent tool-call sequencing. Measure platform-side metrics and application-side completion metrics because fast service response does not always mean the business task finished. Use realistic data sizes, concurrency, filter patterns, region placement, authentication paths, and downstream limits in tests. When performance regresses, compare configuration changes, resource limits, client logs, diagnostic data, and workload timing before adding capacity or blaming one Azure service. This keeps Foundry IQ review specific across architecture, security, operations, and incident response.
Operations
Operations for the Foundry IQ require named owners, documented resource IDs, expected behavior, diagnostic settings, and first-response checks. Before a change, capture read-only CLI output, portal screenshots when useful, deployment history, and relevant application configuration. During incidents, avoid changing several settings at once. Compare service metrics, logs, run history, identity evidence, network state, and downstream health in the same time window. Keep release notes clear enough for support teams to verify current behavior quickly. This keeps Foundry IQ review specific across architecture, security, operations, and incident response. This keeps Foundry IQ review specific across architecture, security, operations, and incident response.
Common mistakes
Treating Foundry IQ as a label instead of checking the exact resource scope, live configuration, owner, and dependencies.
Changing several settings at once without saving read-only evidence, rollback instructions, and the expected metric change.
Assuming the Azure resource succeeded means the end-to-end business workflow completed correctly and safely.