What is headless knowledge management? One source, read through search, API and MCP
Headless knowledge management keeps one governed source that people, Copilot and AI agents read through search, an API or MCP. What it changes, and its limits.
Headless knowledge management separates the place where knowledge is governed from the places where it is read. The knowledge base becomes one source, with owners, review dates, permissions and a record of where each statement comes from. People, Microsoft Copilot and AI agents then read it in the tools they already use, through open interfaces: search, an application programming interface (API) and the Model Context Protocol (MCP).
When the same procedure is read in five different tools, its value depends on how the source is governed. Any of those tools can change next year. The source has to stay right for all of them.
Where the word "headless" comes from
In computing, a headless server runs without a screen or a keyboard. Nobody sits in front of it: other systems talk to it over the network.
Content management borrowed the idea for a practical reason. In October 2009, Daniel Jacobson, then Director of Application Development at NPR, the US public radio network, described the approach his team called COPE: create once, publish everywhere. Content goes into one system, and from there the same content feeds the website, mobile apps and other displays through an API. In his words, "Separating content from display is one of the key concepts supporting COPE." Content systems built on that principle, with a store and an API but no front end of their own, later became known as headless.
Knowledge management has reached the same point, for a different reason. The "head" of a knowledge base used to be its own portal: people went there to search and read. Today the same procedure is read in a support ticket, in a chat with an assistant inside Microsoft Teams or Slack, by Copilot, by an agent the IT team built, and on a help portal for customers. Most of those readers never open the knowledge base itself.
What a headless knowledge base is
A headless knowledge base has two halves. The first is the source. It holds the knowledge and four facts about each piece of it:
- Ownership: who is responsible for it today, by name.
- Validity: when it was last checked, and when it must be checked again.
- Permissions: who may read it, and so who may receive an answer built from it.
- Provenance: where each statement comes from, so that an answer can cite it.
The second half is a set of interfaces that open the source to readers: a search that ranks by meaning, a knowledge base API for the systems the organisation builds, and an MCP server for AI assistants and agents. Each front end (the place where someone reads the knowledge) reads through one of them, and each needs something different from the source.
| Who reads | Through | What the source must pass on |
|---|---|---|
| A person in the knowledge base | The knowledge base itself | The article, its owner and its review date |
| An assistant in Teams, Slack or a ticket | Search, or a browser extension | The right passage, filtered by that person's rights |
| Microsoft Copilot, ChatGPT or Claude | An MCP server | The content and its metadata, read as the signed-in person |
| An agent the IT team built | The API or search | The same, plus the review status to check before it answers |
| Customers on a help portal | Public pages | Content marked public, and nothing else |
"Headless" here describes an architecture, not a product category. It also does not mean the front ends stop mattering, and the last part of this article returns to them.
What MCP and the agent standards settle today
What it is. MCP is an open protocol that connects AI applications to data and tools. The current version of its specification is dated 28 July 2026. Our guide to AI knowledge management explains how agents connect through it.
Who governs it. MCP is now run as "a Series of LF Projects", a Linux Foundation structure, and its specification is published under the Apache 2.0 licence. On 9 December 2025, the Linux Foundation formed the Agentic AI Foundation with MCP among its first projects. The Agent2Agent (A2A) protocol, which connects agents to each other, joined the foundation on 27 August 2026.
What standards bodies are doing. The Internet Engineering Task Force (IETF) is chartering a working group on agent communication protocols, called agentproto. Its proposed charter leaves MCP and A2A to their own maintainers, and its milestones end with a protocol sent for approval as a proposed standard in March 2028. In February 2026, the US National Institute of Standards and Technology (NIST) launched an AI Agent Standards Initiative. One of its three pillars is research on agent security and identity.
What MCP leaves to you. The protocol settles how an assistant connects. It does not settle who may read what. The specification says that authorisation is optional for MCP implementations. When a server does use it over HTTP, it is expected to follow OAuth 2.1: the server must only accept tokens issued for it, and clients should ask for the smallest set of permissions they need. The specification also says that MCP "cannot enforce these security principles at the protocol level", and asks implementers to build their own consent flows and access controls. It does not describe how a server should match what it returns to each person's rights in the source system.
Connecting is now standard. Deciding who may read what is still the job of the source.
Permissions follow the answer
Public guidance on AI security is clearer about permissions than the protocols are, and it points at the source.
France's national cybersecurity agency, ANSSI, published 35 security recommendations for generative AI systems in April 2024. It asks for access on a need-to-know basis to be built in from the design stage (R8): training data cannot carry access rights, while documents added in production can. It asks for an authorisation check on every exchange between an AI system and business applications (R26). And it asks for the access rights that AI tools hold on mail, document spaces and code to be reviewed when the tools are activated, then regularly, for example every month (R35).
In May 2025, security agencies from the United States, the United Kingdom, Australia and New Zealand published joint guidance on the data that AI systems use. On answers, it is direct: the output of an AI system "should be classified at the same level as the input data".
Read together, these give the permissions rule of a headless design, in three parts:
- An answer is as confidential as its most confidential input. The source must know the level of each document, not only of the folder it sits in.
- Every front end reads as the person who asks. A connector that reads with a broad service account gives everyone the rights of that account.
- Rights are reviewed per connector. Each front end is a new reader with its own scopes.
The guidance stops before the hardest cases. None of these texts says what to do when one answer combines documents with different rights, or when a right is removed after a document was copied into a separate index. A copy keeps the rights it had on the day it was made. Reading from the source at the moment of the question, with the rights of the person asking, avoids that second problem.
Why the source decides the answer
Ownership and review dates matter because models tend to believe the documents they are given. In a peer-reviewed study published in The Lancet Digital Health in January 2026, researchers tested 20 large language models on health misinformation. When one false recommendation was inserted into a real hospital discharge note, the models accepted it in 46.1% of cases, against 8.9% for false claims taken from social media. Of the three kinds of text tested, the clinical notes, written in official-looking prose, were believed most often, and to a model, a company procedure looks just as official. Our article on WYKIWYG, what you know is what you get reviews the wider evidence.
What it changes for a rollout
The sources are the product. Before you choose the next assistant, list what each existing front end reads, and from where. A knowledge audit gives the structure: which spaces, which owners, which review dates, which rights. A gap you find there will appear in every front end at once.
The front ends are many. Expect more of them, not fewer. Keep a list of them, with a named owner for each connection.
Test what each one reads. Ask the same questions in each front end, as people with different rights, and compare the answers and the sources they cite. NIST's profile for generative AI (NIST AI 600-1, July 2024) suggests re-assessing risks after adding retrieval-augmented generation (RAG) to a system. A new front end on the same source is the same kind of change. Our guide to retrieval-augmented generation explains how retrieval works.
A public example shows this design at national scale. In February 2026, data.gouv.fr, the French government's open data platform, announced an experimental MCP server that any compatible assistant can read without a key. Its guide still warns that answers can be wrong, and recommends the API for serious uses, where results can be traced. Open data needs no rights per person. Company knowledge does, which is why the permissions rule matters more inside a company.
Where the thesis stops
The headless argument is strong about reading. It is weaker about writing.
A front end shapes what people write. Good contributions come from an editor with templates, an approval step and a clear owner. People write where it is easy, and a chat window is a poor place to draft a procedure that 200 colleagues will follow. A source with no good place to write in it decays, whatever its interfaces.
Adoption also depends on the front end. People judge the knowledge by the answer they see in their own tool, and a wrong answer there costs trust in the knowledge itself. The front ends deserve care. They are simply not the place where knowledge is governed.
The comparison with content management has a limit too. A web page is published and read. A procedure ages, changes owner and conflicts with a newer one. That is the harder problem, and the one that knowledge as code addresses with practices borrowed from software: versions, review and a history of every change.
What the standards leave out, and what Elium does
The standards and the guidance above say little about the source itself: who owns each document, when it expires, and how its rights reach every reader. That is the part we build at Elium, a European knowledge management platform. If your engineers run their own retrieval, retrieval stays with them, and we maintain the knowledge it reads.
- One governed source. Every article has a named owner, who is responsible for keeping it accurate, and it can carry a verification date. When the date approaches, the article appears in the owner's task list. See Keep articles up to date and Permissions and visibilities.
- Read as the person. The Elium MCP server connects ChatGPT, Claude, Microsoft Copilot Studio and other compatible assistants. Every MCP tool runs with the permissions of the signed-in user, so an assistant never sees content that person could not open. See About MCP.
- Validity the reader can check. When an assistant reads an article, it also receives the owner, the review or expiry date and the approval status, so it can say how current its source is. See Search and read content with MCP.
- Many front ends. The same platform is read through the API, in a browser extension next to a ticket, and on a public portal for customers. See API and connected applications, Browser extension and About the public portal.
At the Département de l'Orne, for example, IT technicians receive answers inside their GLPI tickets, and every procedure has an expiry date that triggers a review each year. The Orne customer story describes the set-up.
Where to go next
- Read the main guide: AI knowledge management: why Copilot gets it wrong, and how to fix the source.
- Compare: AI-powered knowledge base software.
- Use a template: the knowledge audit checklist.
- Do it in Elium: connect an assistant to Elium over MCP.
Common questions
Headless knowledge management keeps knowledge in one governed source and lets people and AI agents read it elsewhere, through search, an API or MCP. Writing, review and permissions stay in the source; reading happens in Teams, a ticket, Copilot, an agent or a help portal.
No, MCP does not handle permissions on its own. The specification makes authorisation optional, and when authorisation is used over HTTP it is expected to follow OAuth 2.1. Matching each answer to the rights of the person asking is the server's job, so check that every connector reads as the signed-in person.
A headless content management system (CMS) separates content from its display, so one article can appear on many channels. A headless knowledge base does the same for readers, but its content goes out of date and carries access rights. The source therefore also manages owners, review dates and permissions for every reader, human or AI.
Yes, for writing and for trust. Authors need an editor, templates and approval, and readers sometimes need the full article and its owner behind an answer. Most daily reading can happen in the tools people already use.
An answer should be classified at the same level as the data it was built from, as joint guidance from US, UK, Australian and New Zealand security agencies recommends (May 2025). Each front end reads as the person who asks, and the rights of every AI connector are reviewed regularly.
Sources
- Daniel Jacobson (NPR), COPE: Create Once, Publish Everywhere, ProgrammableWeb, 13 October 2009 (archived copy, University of North Texas).
- Model Context Protocol, Specification, version of 28 July 2026, its Authorization section, and Governance and stewardship.
- Linux Foundation, Linux Foundation announces the formation of the Agentic AI Foundation, 9 December 2025.
- A2A project, A new chapter for A2A: joining the Agentic AI Foundation, 27 August 2026.
- IETF, Agent Communication Protocols (agentproto) working group, proposed charter and milestones.
- NIST, Center for AI Standards and Innovation, Announcing the AI Agent Standards Initiative for interoperable and secure innovation, 17 February 2026.
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1), July 2024.
- ANSSI, Recommandations de sécurité pour un système d'IA générative, version 1.0, 29 April 2024 (in French).
- NSA Artificial Intelligence Security Center, CISA, FBI, ASD's ACSC, NCSC-NZ and NCSC-UK, AI Data Security: Best Practices for Securing Data Used to Train and Operate AI Systems, May 2025.
- Mahmud Omar and colleagues, Mapping the susceptibility of large language models to medical misinformation across clinical notes and social media, The Lancet Digital Health 8(1), January 2026.
- data.gouv.fr, Le serveur MCP de data.gouv.fr (in French), and Jacques Cheminat, Data.gouv.fr expérimente un serveur MCP, Le Monde Informatique, 27 February 2026.
