Support
One governed catalog. One standard access layer. Several approved AI experiences.
Most organisations do not have a shortage of AI models. They have a shortage of reliable context those models can use about the organisation itself.
Ask a general-purpose assistant what net revenue means inside your company, which table is authoritative, who owns it or how it reaches an executive report. The assistant can admit that it does not know, or it can construct the most plausible answer it can. The second response is usually more fluent. It is also the dangerous one.
Your data catalog already contains much of the missing context: technical metadata, business definitions, ownership, classification, lineage and the relationships between systems. The problem is not that the knowledge is absent. The problem is that the person asking must stop what they are doing, open another system, understand how the catalog is organised and already know what to search for.
This series explores a different model: keep governed knowledge in the catalog and allow approved AI tools to consult it through the Model Context Protocol (MCP).
The catalog remains the system of record for metadata. MCP provides a standard way for AI clients to discover and call catalog capabilities. Microsoft Copilot Studio, Microsoft Foundry, Claude or another approved MCP client becomes the experience through which the user asks the question. The result is not simply “a chatbot for the data catalog.” It is a reusable enterprise knowledge layer.
Govern metadata once, expose it through a standard read-only service, preserve the identity and permissions of the person asking, and allow several approved AI experiences to reuse the same knowledge.
Why this matters now
Employees are already asking AI assistants about internal data. Without access to governed enterprise context, those assistants can only respond from general knowledge, user-provided fragments or inference.
Connecting an AI agent to the catalog changes that conversation in three practical ways:
- Answers can be grounded in live catalog metadata. The agent searches the governed repository rather than guessing from a familiar naming pattern.
- Existing permissions can remain in force. A shared agent does not have to become a shared identity with broad access.
- The same foundation can serve more than one AI platform. The organisation can reuse the catalog, MCP service and agent behaviour instead of rebuilding the knowledge layer for every client.
This matters to more than the data team. Analysts gain faster discovery. Engineers gain documented impact context. Data Stewards gain a demand-ranked view of missing documentation. Data Owners gain visibility of accountability gaps. Security and architecture teams gain a design they can review as a set of explicit trust boundaries rather than as a vague “AI with data” proposal.
What the series covers
The series follows the sequence an organisation would realistically use: first establish the purpose and value, then define the security and agent behaviour, and only then choose how to implement it.
Act I: Why
Part 1: The catalog as a knowledge layer, not a destination
Explains the architectural shift from a catalog people must remember to visit to a governed service that approved tools can consult at the moment of need.
Best for: Data leaders, Enterprise Architects, Data Architects and governance sponsors.
Part 2: The value case, built on work people already do
Builds the business case around repeated questions, steward interruptions, onboarding, audit response and governed AI usage. It also sets out a conservative value model and the measures to agree before a pilot.
Best for: Sponsors, Data Governance leaders, transformation teams and budget owners.
Act II: Design
Part 3: Securing it end to end
Separates identity, agent controls, transport, authorization and the metadata boundary. It explains why read-only access reduces integrity risk but does not remove confidentiality risk.
Best for: Security Architects, CISOs, Enterprise Architects and platform owners.
Part 4: Designing the assistant around the job, not the platform
Introduces the Portable Agent Contract, six governance role overlays, starter prompts and the release tests that prevent plausible but invented answers.
Best for: Data Governance teams, agent owners, Data Stewards and solution designers.
Act III: Build
Part 5: The shared foundation everything else plugs into
Covers Hosted and Local Mode, container configuration, HTTPS, OAuth registrations, health checks, reverse-proxy settings and the mistakes most likely to consume an afternoon.
Best for: Platform Engineers, integration teams, DevOps and technical architects.
Part 6: The low-code build: Microsoft Copilot Studio
Shows the shortest route to a business-facing, permission-aware catalog agent, including MCP onboarding, OAuth, tool review, testing, governance and a controlled pilot.
Best for: Power Platform makers, Microsoft 365 teams and Data Governance practitioners.
Part 7: The pro-code build: Microsoft Foundry
Explains identity passthrough, project connections, tool allow-lists, approval posture, reusable toolboxes and repeatable evaluation for agents embedded in custom applications.
Best for: AI Engineers, developers and solution architects.
Part 8: The portability test: Claude and the wider ecosystem
Changes the client and vendor while keeping the governed catalog, MCP access layer and agent contract intact. It also explains the difference between remote and local MCP operating models.
Best for: Enterprise Architects, mixed AI estates and teams evaluating platform portability.
Who should read which part
Each part answers a distinct question and can be read on its own.
Ideas to carry through the series
- Govern once. Consume everywhere. Definitions, ownership, classification and lineage remain governed in the catalog. They are not rewritten independently inside each agent.
- Preserve identity. Respect permissions everywhere. The agent should not become a shortcut around the catalog access model. Where the client supports it, users authenticate as themselves and receive answers within their existing permission boundary.
- Connect through standards. Approve deliberately. MCP makes the knowledge layer portable. It does not make every MCP client automatically suitable for enterprise use. Each client still needs an approved identity model, network path, tool scope and operating owner.
What this series does not claim
This is not a proposal to let an AI assistant query business data values directly. The scope is metadata: where data lives, what it means, who owns it, how it is classified and what documented lineage connects it.
It is also not an argument for waiting until the catalog is perfect. A controlled pilot in one well-documented domain can prove value while showing, through real unanswered questions, where documentation investment should go next.
Finally, MCP is the connection standard, not the complete security model. Identity, authorization, transport, tool scope, client approval, monitoring and metadata sensitivity still need explicit decisions.
From catalog adoption to governed AI adoption
The deeper opportunity is not to make the catalog look more intelligent. It is to make the knowledge already governed there available at the moment someone needs it.
If the design works, the user does not need to know what MCP is. The user asks an ordinary question in a familiar tool. The assistant retrieves what the organisation has actually documented, respects the user's permissions, states where the evidence ends and identifies who can help with the rest.
When the catalog cannot answer, that is useful too. It produces a specific, demand-driven signal about the definition, ownership assignment or lineage path that should be improved next.
That is how a catalog begins to operate as an enterprise knowledge layer rather than simply as another destination.
Start with Part 1: The catalog as a knowledge layer, not a destination
AI assistance disclosure: AI tools supported research, editorial refinement and the creation of the visual used in this introduction. The architecture, recommendations and final published content were reviewed and validated by the author.
