Designing an MCP Server Agents Cannot Misuse: Lessons from FAQ Hub

Answer: Treat an MCP server as a product API for a probabilistic caller. Bind every key to one customer and product with least-privilege permissions, split writes into export, plan, apply and publish steps, keep publication an explicit and audited action, treat all imported content as untrusted data, and give agents a way to report what they could not answer.

FAQ Hub, our help-centre and AI assistant platform that serves many businesses from one system, exposes its content to AI agents through a Model Context Protocol server. Authoring agents in IDEs and pipelines use it to keep help content in sync with a product’s repository. Support agents use it to read published knowledge.

Exposing a platform shared by many customers to agents forced us to make design decisions that apply to any MCP server or agent tool surface. Here are the ones that mattered most.

1. One key, one customer, one product, explicit permissions

Every MCP request authenticates with a product API key. The customer and product come from the key, never from tool arguments, so an agent cannot ask for another customer’s content even if a prompt tells it to.

Keys carry explicit scopes, and we ship presets rather than asking customers to compose them:

• A support agent preset can read published knowledge and report gaps. It can never see drafts.
• A writer preset can read content and create plans and drafts.
• Admin keys exist, but are not what we recommend for automation.

Least privilege only works if the least-privileged option is the obvious one. Presets make it obvious.

2. Split every write into plan and apply

Agents are good at producing changes and bad at knowing when they are wrong. So no tool writes directly. Content changes go through a sequence:

1. Export the current state, so the agent works from facts rather than memory.
2. Plan a change set. The server validates it and returns a dry-run diff: what would be created, updated or left alone.
3. Apply the plan, which creates drafts only, with idempotency so a retry does not duplicate work.
4. Publish as a separate, explicit step.

The plan step is where most mistakes are caught, by the agent itself, by a human reviewer or by validation rules, before anything changes.

3. Publication is a human decision, and the record says so

Publishing is the moment content reaches customers, so it stays explicit and attributable. Published knowledge carries a trust tier: content published by an identified person is marked human-reviewed; content published through automation is marked as such. We never upgrade automation to “human” because we cannot prove a person approved an API call.

That distinction flows into our Open Knowledge Format exports, where each concept’s verified metadata records who or what published it.

4. Imported content is data, never instructions

Agents bring content in from repositories, documentation sites and other knowledge bundles. Every file is treated as untrusted:

• Bounded size and file count, safe paths only.
• Markdown converted with raw HTML disabled, then run through the same sanitising validator as any other input.
• Links rewritten only when they point at content inside the import, so nothing points at a page that does not exist.
• The import produces a dry-run plan like any other change. Nothing is written until a caller applies it.

Prompt injection is much less dangerous when the content an agent reads cannot change what the server allows.

5. Close the loop with gap reporting

The most valuable tool we added was not a write tool. It lets a support agent report a question it could not answer from published knowledge. Gap reports are deduplicated, rate-limited and visible only to that customer, and zero-result agent searches are tracked the same way as zero-result searches from human visitors.

Authoring agents can then list open gaps, search existing content and propose new articles through the normal plan-and-review flow. The system improves from its own failures, with a person still deciding what gets published.

What carries over to your platform

You do not need to be building a knowledge product for these lessons to apply. Any MCP server or agent tool surface benefits from the same rules:

• Derive scope from credentials, not arguments.
• Offer least-privilege presets.
• Make writes plan-then-apply, idempotent and reviewable.
• Keep irreversible or customer-facing actions explicit and attributed.
• Treat everything an agent reads as data.
• Give agents a structured way to say “I could not do this”.

Our AI integration and agentic workflows practice designs tool surfaces like this for existing products, and you can see the production version in FAQ Hub.

Related

• Keeping customer data separate when AI agents call your systems - the data-separation side of the same problem
• Agentic workflows in regulated fintech - propose-and-approve for money movement
• What AI readiness actually means - safe system connections is area three