External models never see internal-only data, not even its name

Put a model running inside the customer network and an external API model in one installation, and deciding which models people may use does not keep internal data from leaving. Query salaries from the HR database in a conversation on an internal model, continue that conversation on an external model, and the earlier results go to the external provider as part of the conversation context. A conversation that starts on an external model carries its own risk. The start of a conversation lists the databases available along with business summaries, and if one line reads "HR database — employee salaries and reviews," that name and description have already gone out. An instruction hidden in a web page can also tell the model to query that database.

This post covers one check that connects models and data. Providers carry a tier that says whether data stays in the network, and database connections, document collections, and connectors carry an "Internal models only" mark. When a turn (one round of taking a question and producing an answer) starts, the turn's model and tier are settled first, and a turn running on an external model does not carry "Internal models only" resources at all, not even their names. A conversation stays on the tier it started with.

#Model allowance and role permissions cannot see inside a conversation

Administrators already have two settings. Turn a model's Allow use switch off on the model management screen, and that model drops out of the model list for new conversations, the agent default list, and analysis jobs. Agent defaults set the default model for each feature that calls a model, such as chat, database analysis, and meeting summaries. You can assign database analysis and meeting summaries to internal models and let people pick external models only in general chat.

Both settings decide which models can be used. They do not look at what is in the conversation a model receives. Both cases in the opening paragraph happen between an allowed model and a user who has permission. Role permissions are the same. They decide who may see the HR database, not which model that person sees it through. An HR staff member can query the same database on an internal model or an external one.

Blocking right before execution is another option. Reject the HR database query on an external-model turn, and no row values go out. But a rejection happens only after the model knows the database and calls it. By then the database's name and business summary have already gone out in the prompt. Blocking at execution also does nothing about the line at the start of a conversation that names the databases the user has no permission for. That line is there so the model can answer "you can't see that database," but for an external model, those names are information leaving the network too.

#The tier belongs to the provider, and the installation configuration sets it

The mark on the model side is the provider tier, and it has two values. A private provider keeps data inside the customer network; a public provider sends it out. In this post, internal models are models from a private provider and external models are models from a public provider. Each model takes its provider's tier as is.

The installer writes the tier for each provider in the configuration file, and the admin console only displays it. Whoever writes the base URL knows whether that address is an in-house server or an external service. Because the tier cannot be changed in the console, one wrong click during operation cannot turn an external provider into an internal one.

The tier follows the address, not the provider type. vLLM usually runs on in-house GPU servers, but it can run in the cloud too. The same vLLM is private at an in-house address and public at a cloud address.

#"Internal models only" is a mark on the resource itself

The mark on the data side is one per resource. For each database connection, document collection, and connector (an external service the company connects, such as an MCP server), administrators choose "All models" or "Internal models only." The mark is separate from role permissions. To use a resource on an external-model turn, the user must have permission for it and the resource must be set to "All models."

In an installation with a private provider, new resources default to "Internal models only." If an administrator skips the field, the resource stays invisible to external models, and administrators open to external models only the resources that may go there.

A resource once opened to "All models" cannot be set back to "Internal models only." While it was open, its data may have gone into external-model conversations, and calling data that has already left internal-only would make the mark untrue. If data that must not reach external models turns up later, create a new database connection or collection for it and set that to "Internal models only."

#An external-model turn shows those resources nowhere

When a turn runs on an external model, "Internal models only" resources appear nowhere in what that turn sends to the model. They are removed from these places:

• The database and document list, with business summaries, at the start of a conversation
• The list of database names the user has no permission for
• The targets available for @mentions
• The tool list and tool descriptions, including tools loaded later in the conversation
• Every tool that an "Internal models only" connector provides

The external model does not know the HR database exists, so it cannot try to query it. An instruction hidden in a web page or document cannot point the model at a database it does not know about either. If the model learns the name some other way and calls it directly, the same check runs again right before the tool executes and rejects the call.

Exposure is blocked in the one place that builds the tool list, and execution in the one place every tool call passes through. Chat, playbooks, and deep research share that execution path, so no surface needs a block of its own. In both places, an error during the check removes the resource or rejects the call.

Researchers that the lead launches in deep research inherit the lead turn's execution context as is, so the same resources are removed. Meeting summaries go through the same check using the tier of the summary model the user chose.

#A conversation stays on the tier it started with

The check runs before the turn starts. First, the model for this turn is settled: the model chosen for the conversation if there is one, otherwise the feature's default model. The provider is read from the model and the tier from the provider, and the tier goes into the turn's execution context. Only then are the start of the conversation assembled and @mentions resolved. If the model cannot be settled, the turn is rejected instead of guessing a tier.

A conversation is locked to the tier it started with. A conversation that began on an internal model may contain results read from "Internal models only" resources and internal material the user pasted in, so it continues on internal models to the end. One that began on an external model continues on external models. This rule stops the first case in the opening paragraph.

A conversation's model list shows only models of the same tier from the start, and switching models mid-conversation picks from that list. If a request for a model of another tier arrives, the turn-start check rejects it and tells the user to open a new conversation to use that model. Playbooks made from a conversation also follow that conversation's tier.

Text the user types or pastes carries no mark, so there is nothing to check it against. Even so, anything pasted into an internal-model conversation does not leave internal models, because the conversation is locked.

#Embedding and speech recognition are chosen by the installation, not the turn

Searching documents means sending them to an embedding model, and transcribing a meeting means sending its audio to a speech recognition model. These models are not picked per turn. The installation configuration sets one for each role, so they are checked at installation rather than at turn start.

An on-premises installation can run chat, embedding, reranking, and speech recognition all on self-hosted models inside the network. The configuration example notes what goes out with each choice that leaves the network: a managed meeting transcription service sends meeting audio out, and hosted speech recognition sends microphone audio out. Embedding works the same way. In an installation with "Internal models only" resources, putting embedding on a public provider would send those resources' documents out at embedding time, so it raises a warning at startup and when a resource is registered.

#Design choices

We hide resources instead of only rejecting calls. Rejecting right before execution is simpler to build, and the resource list does not have to differ by model. But a rejection comes after the model already knows the resource's name and purpose, and by then they have gone out in the prompt. When the resource is hidden, there is nothing to send out in the first place. Rejection at execution stays as a second check that catches calls that get around the hiding.

We lock a conversation to its starting tier instead of switching models based on the data that came in. Switching with the data would mean working out, on every call, which resource's results remain where in the conversation context, and once compaction or edits are involved that judgment goes wrong easily. With the tier locked, the check runs once at turn start, and the model shown on screen is the model that answered. The cost is that using an external model means opening a new conversation. An internal-model conversation never lists external models in the first place, so users rarely run into the rejection.

The installation configuration sets the tier, not the admin console. The checks built on top of the tier can be trusted only if one click during operation cannot change it. That is also why there are only two tiers, private and public. A category like "external model with a data protection agreement" is something a contract guarantees, and code cannot verify it. Whether to use such a provider is up to administrators through the model's Allow use switch.

The mark goes on database connections and collections, not on tables. Marking each table would multiply the fields to manage by the number of tables, and every missed field would become a hole. If a database has only a few sensitive tables, create one more connection with a database account that sees only those tables and set it to "Internal models only." The database account's privileges and the resource's mark then point at the same boundary.

If your installation uses internal and external models together, list the databases and documents that must not reach external models before deciding which models to allow. That list is the set of resources to mark "Internal models only," and any listed table that shares a connection with other tables marks a connection to split.