Your team shares one AI workbench and one model key. Can you name every hop a prompt takes?
Most teams answer with the server and stop there. That answer is usually incomplete.
Self-hosting moves the application. It does not automatically move the model. Where a prompt travels depends on what you configure.
So here are five myths, each with a check you can run before rollout.
The claim: we host it, so the data stays home.
Why it breaks: the workbench and the model endpoint are two different systems. If the configured model is an external provider, prompts leave the host. That is a configuration fact, not a hosting fact.
The check: list every outbound destination in your config. Include model base URLs, MCP servers, auth providers, and telemetry. A hop with no owner has no review.
Corrected model: count egress per hop, not per product.
The claim: everyone uses the same key, so access is controlled.
Why it breaks: a shared key gives many people one identity. You can limit who holds the key. You cannot attribute an action to a teammate from the key alone.
The check: pick one prompt from last week. Can you name the sender without asking around? If not, you have a shared secret, not access control.
Corrected model: access management is identity, role, and retention. A key is only credential handling.
Which identity features your build exposes depends on version and configuration. Verify against current documentation for the build you run. Do not assume parity across versions.
The claim: we can swap models freely because the workbench abstracts them.
Why it breaks: a shared UI does not flatten provider behavior. Context limits, tool-calling formats, and structured-output strictness all differ.
The check: replay three representative prompts against each configured model. Compare refusal behavior, tool call shape, and output length. Keep what your tasks actually need.
Corrected model: a model choice is a per-task contract with a documented fallback. It is not one global switch you flip.
Illustrative policy file, not a product schema and not executed:
model_policy:
default: provider-a/model-x
fallback: provider-b/model-y
task_overrides:
code_edit:
require_tool_calls: true
long_doc:
min_context: look-up-in-provider-docs
Replace every placeholder with a value your provider documents today.
The claim: integrations are sandboxed extras we can enable later.
Why it breaks: an MCP server is a separate service with its own credentials and data access. The workbench routes calls to it. Routing does not erase that boundary.
The check: write one line per MCP server. What does it read? Which credentials does it hold? Does it call an external API? A blank line is an unreviewed trust boundary.
Corrected model: each MCP server is a vendor you happen to operate.
The claim: the workbench already knows what the team knows.
Why it breaks: shared resources usually means shared configuration and assets, not one conversation across people. Assuming memory you never verified breeds confident wrong answers.
The check: read the persistence and retention notes for your exact version. If nothing is documented, treat memory as absent and retention as unknown.
Fill one row per hop, per deployment. Every row needs an owner and a review date.
| Hop | Data | Controlled by | Leaves host | Owner |
|---|---|---|---|---|
| Client to workbench | prompts, files | your team | no, if self-hosted | ? |
| Workbench to model provider | prompts, context | provider | depends on provider | ? |
| Workbench to MCP server | tool args, results | your team or a third party | depends on server | ? |
| Workbench to telemetry | usage events | vendor or self | depends | ? |
Then run a six-item preflight:
These steps are illustrative and were not executed for this article. Adapt them to your own environment.
No logging available? Do a config review instead. Mark unverified rows as findings, not as passes. An empty cell is a question, never a clearance.
Skip this approach if you cannot change model configuration. Skip it if you expect the ledger to replace a security review. It is an inventory, not an audit.
The repository at https://github.com/chaitin/MonkeyCode describes MonkeyAI, an open-source team AI workbench for office, coding, and design. Its listed capabilities include shared team resources, configurable models, and MCP integrations, alongside access management and self-hosting.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
Two boundaries keep the mapping honest. First, self-hosting the workbench does not mean external model or tool providers stop receiving data. Second, the same repository keeps README.monkeycode.md, which documents the historical MonkeyCode AI development platform. Read the file that matches the build you actually run.
If your next rollout opens with a filled ledger row instead of a slide, you are ahead. Start from the repo README and map one hop at a time.