Five Myths About Sharing One AI Workbench: A Data-Flow Ledger for Teams

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.

Myth 1: Self-hosting keeps every prompt inside our network

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.

Myth 2: One shared key is access management

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.

Myth 3: Configured models are interchangeable

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:

# illustrative only
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.

Myth 4: MCP integrations are just plugins

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.

Myth 5: Shared team resources means shared memory

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.

The artifact: a four-hop data-flow ledger

Fill one row per hop, per deployment. Every row needs an owner and a review date.

Then run a six-item preflight:

1. Every egress destination has a named owner.
2. Every configured model has a documented data-handling note.
3. Every MCP server has a credential inventory.
4. Prompt attribution works for at least one real user.
5. Retention is documented, or flagged as unknown.
6. The README you read matches the version you deploy.

How to verify the ledger

These steps are illustrative and were not executed for this article. Adapt them to your own environment.

• Enable egress logging at the network layer around the workbench.
• Send one uniquely labelled prompt per configured model.
• Compare observed destinations against your ledger rows.

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.

Where this breaks, and who should skip it

• Air-gapped claims: do not make them until logging shows zero external destinations.
• Solo developers: a full ledger is overhead; a short note in the repo is enough.
• Fast-moving builds: tables rot, so put a review date on every row.

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.

Where the project fits

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.