Connecting Claude to your ERP without handing over the database
TechnoVision
Publication date pending · 6 min read
The Model Context Protocol solved a real problem: an AI client can now discover and call tools on a server without anybody writing a bespoke integration. It is genuinely good, and it makes a bad decision very easy to make.
The bad decision is the credential. Most MCP servers for business systems authenticate with one API key, belonging to one privileged account, shared by everybody who connects. Every laptop with that key reads as an administrator.
Why this is worse than the same mistake in a web app
A web application with an over-privileged service account is at least confined to what its own screens will render. An MCP server is not: the client composes the requests. Whatever the server is willing to answer, some model somewhere will eventually ask for.
And the client is a program on somebody’s laptop, configured by them, updated on its own schedule, and talking to a model you did not choose.
No prompt on the laptop changes what the server is willing to return.
One token, one person
Bind each token to a single user, and run every request with that user’s access rights. The consequences are all good:
- A token belonging to somebody who cannot see payroll cannot be talked into showing it - not because the model declines, but because the query returns nothing.
- The tool list is per person. A client is never even told that a tool it could not use exists, so there is nothing to probe.
- Revocation is meaningful. Revoking one token affects one person, not the whole team.
- The audit trail says who, not what key.
Details that decide whether it survives contact
| Decision | Why it matters |
|---|---|
| Re-resolve the tool name on every call | The name arrives from outside - from a model, a replayed conversation, or a client that composed it. Trusting a previous tools/list is trusting the client. |
| Return tool errors as results, not protocol errors | A confused model should be told what was wrong and try again. A protocol error ends the session instead of correcting it. |
| Store the secret as a digest | A token you can read out of a database backup is a token that leaks with the backup. |
| Keep audit rows after revocation | The interesting question is almost always asked after the token is revoked. |
A trap specific to Odoo 18
What not to expose
Reads. Nothing else. An MCP server that can post a journal entry is a different product with a different risk profile, and shipping both behind one flag means every buyer takes the second risk to get the first benefit.
If you want an assistant that acts, build that deliberately, with confirmation, with a narrower scope, and with its own conversation with your auditor.