When your AI talks to another AI: do you really know where your organizational knowledge travels?

Artificial intelligence is rapidly taking hold in businesses and government organizations. Employees use it to analyze documents, summarize reports, write code, prepare presentations, search for information, structure decisions, and speed up a multitude of daily tasks. As AI agents emerge, this integration goes even further: artificial intelligence can now directly access certain applications, consult documents, query databases, use APIs, and take part in operational processes.

These capabilities can deliver considerable gains. They also create a new reality: part of an organization's knowledge is beginning to travel through artificial intelligence infrastructures whose components users do not necessarily know in full.

A recent episode involving Moonshot AI, the company behind the Kimi models, and Anthropic helps measure the importance of this question. Initially, U.S. authorities accused Moonshot of having used Claude's capabilities to accelerate the development of Kimi through distillation techniques. These accusations fueled a debate, notably about the timeline put forward and about what it could actually explain.

A few weeks later, Anthropic made far more specific allegations. According to the company, Moonshot had relayed certain requests from its own users to Claude and retrieved elements of those exchanges. Anthropic states that these operations would have represented more than 23 million exchanges between May and July 2026, and that some requests contained sensitive information from users who believed they were interacting solely with Kimi.

Beyond the commercial, technological, and geopolitical dimensions of this case, a far more universal question arises for organizations: when an employee sends information to an artificial intelligence, do we really know who receives it, where it travels, and what can subsequently be done with it?

For a business or a government organization, the main lesson from this situation concerns the chain of trust. When a user opens an artificial intelligence interface, they generally see a brand, a product, and a conversation window. This apparent simplicity can conceal a far more complex architecture.

Several providers may operate behind that interface. The visible service may use a model developed by another company. Certain requests may be routed to different models depending on their nature. A search function may rely on an external service. An agent may call several APIs. Data may pass through an orchestration platform, a cloud infrastructure, and various specialized systems before the response is finally presented to the user. The experience remains simple. The technology chain, however, can be long.

This distinction takes on its full importance when an organization uses artificial intelligence with its own information. According to Anthropic, certain requests sent to Kimi were relayed to Claude without the users concerned necessarily knowing that their data was being transmitted to another provider. The company states that some exchanges included internal code, active credentials, and information originating from government organizations or public enterprises.

Without having to arbitrate the accusations between the companies involved, the situation illustrates a far more general weakness. Users know the tool they are using. They know far less about the architecture behind that tool. For an organization handling sensitive information, this difference can become considerable.

Authorizing the use of an AI service should therefore no longer rest solely on the name displayed at the top of the screen. The entire processing chain must be understood. Which model actually executes the request? Where is the infrastructure located? Is the same model always used? Can the provider pass certain requests to a subcontractor? Are conversations retained? Can they be used for training? What metadata is recorded? Are secondary services or APIs involved in the processing?

These questions become particularly important when the information concerns intellectual property, operations, defense, research, critical infrastructure, personal information, or strategic decisions. The problem then goes far beyond protecting an individual file. It directly affects the organization's knowledge.

For a long time, an information leak mainly evoked a stolen document, a copied database, or an email sent to the wrong recipient. Artificial intelligence changes that dynamic. Today an employee can copy a few pages of a strategic document into an interface and, in a matter of seconds, transmit knowledge that took years to develop.

That knowledge may take the form of source code, a technical architecture, an industrial process, a market analysis, a business strategy, an operating procedure, a financial model, or a series of decisions that together reveal how the organization works. Each fragment may seem relatively ordinary. Their combination can represent a considerable share of its competitive or operational advantage.

This reality requires broadening the notion of intellectual property. Patents, trademarks, and software obviously remain important, but a large part of an organization's strategic heritage lies in its know-how. Why was a given decision made? How does this process really work? What problems have already been encountered? Which solution proved effective? Which clients come with particular constraints? Which suppliers are especially critical? What architecture is being considered for the next product?

It is precisely this context that makes artificial intelligence so useful. A generic AI may possess remarkable capabilities, but it becomes far more relevant when it understands the organization, its documents, its processes, its vocabulary, and its constraints. A paradox then appears: the more an organization shares its knowledge with AI, the more value AI can create; and the more it shares that knowledge, the more it must master the conditions under which that knowledge is used.

A rule that simply asks employees never to send confidential information to an AI tool remains useful, but it is becoming insufficient. An employee does not necessarily know that a piece of information is sensitive. A document may contain mostly public information and a few strategic elements. An enterprise application may use an AI model in the background without the user interacting with it directly. A coding assistant may have access to the code and context of an entire project.

The arrival of AI agents amplifies this phenomenon further. A chatbot generally waits for a user to provide it with information. An agent can go and get it itself. It can consult a mailbox, open documents, query a database, use a CRM, call APIs, and trigger certain actions. The question is therefore no longer only what an employee voluntarily decides to send to the AI. It is also necessary to know what the AI itself is authorized to consult and transmit.

The agent's digital identity then becomes fundamental. Like an employee, an agent should have a distinct identity and permissions that correspond precisely to its role. It does not need access to all of the organization's knowledge simply because it is technically capable of processing it. The principles of least privilege, Zero Trust, and Continuous Trust become directly applicable to AI agents: verifying their identity, limiting their access, monitoring their behavior, and being able to modify or revoke their permissions quickly.

This transformation also makes AI procurement a genuine security and governance challenge. The quality of the responses obviously remains an important criterion when an organization chooses a provider, but it is no longer sufficient. It is also necessary to understand the provider's digital supply chain. Who actually supplies the model? Who supplies the infrastructure? Which subcontractors are involved? Which APIs are used? Where does the data travel? What foreign dependencies exist? What happens if the provider suddenly changes its terms, its architecture, or its partners?

The visible provider may be only the first layer of a much larger architecture.

This reality leads naturally to digital sovereignty. An organization can perfectly well host its data in Canada while using an artificial intelligence service whose requests are partly processed under another jurisdiction. It can run a local model whose functions partly rely on external APIs. It can also develop its own application while remaining dependent on a foreign provider for inference, training, or certain specialized capabilities.

Data residency is therefore one part of sovereignty. Control over how data travels is another. Being sovereign also means knowing where your information travels and retaining the ability to change course when that circulation no longer matches the organization's interests.

This approach does not necessarily mean hosting every model locally. Public artificial intelligence services offer extraordinary power, diversity, and speed of innovation. For many uses involving no sensitive information, they can be an excellent solution. Certain categories of knowledge may nevertheless justify a different architecture.

An organization working on sensitive technologies, security architectures, government programs, regulated data, or strategic intellectual property may benefit from running certain models in an infrastructure it controls more directly. A private or sovereign AI can allow for tighter control over data residency, logs, access, the models used, and connections with other systems.

A mature architecture can therefore use several categories of artificial intelligence simultaneously. Public models can serve general tasks. Enterprise environments benefiting from stronger contractual and technical guarantees can process certain internal information. Private or sovereign infrastructures can be reserved for the most sensitive knowledge. The classification of data and organizational knowledge can then determine which environments are appropriate for which uses.

Artificial intelligence then becomes a genuine enterprise architecture rather than a collection of SaaS subscriptions.

This evolution also gives particular importance to knowledge governance. An organization cannot determine what an AI should be able to consult if it does not itself know what knowledge it holds, where that knowledge resides, what value it has, and who should be able to access it. This is precisely one of the roles the Qb Knowledge Standard — QKS can play. Structuring and governing knowledge makes it possible to exploit it more effectively with AI, but also to determine what must be classified, protected, or restricted to certain environments.

Knowledge governance and AI governance thus become deeply linked. An agent tasked with supporting sales probably does not need access to confidential research documents. An assistant intended for human resources does not need to consult cybersecurity architectures. An engineering agent may need technical documentation without having the same rights as a system administrator. Before granting agents more autonomy, it is therefore necessary to understand the knowledge they will be authorized to use.

The Anthropic–Moonshot case also highlights the other side of the problem: the models themselves can constitute extremely valuable intellectual property. An organization that develops or trains its own models must consider how to detect behaviors that may be seeking to systematically extract certain capabilities from them. A few requests made by a user are ordinary. Thousands of accounts generating millions of methodically structured requests present a very different profile.

Behavioral analysis, anomaly detection, quota management, strong identity, and API monitoring then become mechanisms for protecting intellectual property. AI cybersecurity therefore works in both directions: protecting the organization against what its uses of AI could expose, and protecting its own artificial intelligence capabilities against those who would seek to extract their value.

This problem should not, however, be confused with distillation itself. Distillation is a legitimate and widely used technique in artificial intelligence for transferring certain capabilities from one model to another. The issue arises when techniques are employed in violation of rights, contractual terms, or control mechanisms. This distinction is important: a technology is not inherently problematic simply because it can be used in a contested manner.

For executives, the lesson nevertheless remains very concrete. Any technological capability valuable enough will probably end up attracting attempts to observe it, reproduce it, or extract part of its value. Organizations that develop their own AI assets will therefore gradually have to treat them as strategic assets that also require a protection architecture.

That architecture cannot rest solely on an assessment carried out at the time the provider was chosen. A security analysis has a date. The provider may add new partners, modify its infrastructure, change its contractual terms, be acquired by another company, or introduce new functions. A service may also begin using several models without any visible change to its interface.

Trust must therefore be continuously verifiable. Dependencies must be reassessed, flows documented, contracts adapted, and unusual behaviors detected. This logic connects directly to Continuous Trust: a trust decision made two years ago is not enough to determine the appropriate level of trust today, when the technological environment has changed.

For government organizations, this vigilance can become particularly important. The data handled may concern citizens, critical infrastructure, public policy, national security, or international relations. The consequences of an unintended transfer can then go far beyond commercial confidentiality. This caution should not, however, lead to systematically slowing the adoption of artificial intelligence.

Clear governance can produce the opposite effect. When employees know which tools are authorized, which data can be used, and which environments are appropriate for different categories of information, they have less need to improvise. Developers have approved APIs, users understand the limits, security teams gain more visibility, and executives better understand their exposure. An organization that understands its risks can often authorize more uses than an organization that simply does not know what is circulating.

This is where security can become an accelerator of adoption rather than a brake. The role of Hypersecurity also takes on its full meaning here. Cybersecurity remains indispensable for protecting data, identities, APIs, applications, models, and infrastructures. Hypersecurity adds a cross-cutting view of their interactions, their dependencies, and their evolution. It seeks to understand how knowledge travels among people, agents, models, applications, providers, and infrastructures, and then to maintain a level of control compatible with the risk.

In a distributed AI environment, protecting a database is therefore no longer enough. It is necessary to protect the paths that lead to it, the identities that can query it, the agents capable of extracting information from it, the models that can process it, the providers involved in that processing, and the actions that can subsequently be carried out. Control becomes dynamic because the interactions are becoming dynamic too.

For Quantum Beyond, the first step is therefore to understand before connecting. Which AI tools are already in use? What data and what knowledge travel through them? Which providers and subcontractors are involved? Which APIs are connected? Which agents have access? What dependencies exist? Which knowledge is sensitive enough to require a different infrastructure or level of control?

This understanding can then feed an architecture adapted to the risk. AI governance, QKS, IAM, Zero Trust and Continuous Trust, private and sovereign AI, Hypersecurity architecture, cyber resilience, and digital sovereignty can work together to allow the organization to make greater use of artificial intelligence while retaining sufficient control over its knowledge and its operations.

The most important question may therefore no longer be simply who owns the data. Modern architectures also require asking who can read it, who can process it, where it can be copied, which models can interact with it, which other organizations might eventually access it, and what actions may follow from its use.

Control over information is gradually becoming a question of circulation.

An organization can remain the legal owner of a piece of information while having lost part of its operational control over it. As artificial intelligence becomes embedded in work processes, this distinction will become essential.

The accusations surrounding Kimi and Anthropic are part of a complex context where technological competition, commercial interests, intellectual property, cybersecurity, and geopolitical considerations intersect. It is not Quantum Beyond's role to arbitrate that debate. The lesson a business or a government organization can draw from it is far more directly applicable to its own operations.

An artificial intelligence is never merely a window in which an employee types a question. Behind that window lies an architecture made up of models, providers, APIs, cloud infrastructures, identity systems, complementary services, and sometimes other artificial intelligence models. Each new connection can become a new path taken by the organization's knowledge.

Organizations that want to benefit fully from AI will therefore have to develop a fundamental capability: understanding and governing this circulation. That means knowing the providers and their dependencies, mapping the flows, classifying data and knowledge, controlling human and non-human identities, applying least privilege, monitoring usage, protecting intellectual property, and determining which information can reasonably be entrusted to which environments.

Quantum Beyond can support internal teams in this approach by bringing together AI governance, QKS, IAM, Zero Trust and Continuous Trust, private and sovereign AI, Hypersecurity, and knowledge governance. The objective is to give organizations enough visibility and control to integrate artificial intelligence far more deeply into their activities while preserving their strategic assets and their decision-making capability.

AI delivers its greatest value when it understands the organization's context well enough to be genuinely useful to it. That knowledge has considerable value in its own right. Learning to share it in a controlled manner will therefore become one of the fundamental skills of the organizations that succeed in their transformation through artificial intelligence.

In the age of AI, protecting your knowledge no longer means only preventing someone from stealing it. It also means knowing who we choose to entrust it to, which paths it will travel, and how far we are prepared to let it go.