MCP Keys with Granular Rights: Read, Create, Edit, Delete — Per Data Area

"We've turned on MCP" sounds like a box already ticked — it isn't. The real work starts afterwards: who's actually allowed to do what through that access? That's exactly what decides whether an AI connection to your website is a smart tool or an open barn door.

When I built the MCP access for btlabs Core, it was clear to me early on: one master key for everything would be the most convenient solution — and the wrong one. Just as you wouldn't hand a new hire the master key to every door on day one, an AI agent should only get access to what its task actually requires.

Why isn't a blanket MCP access enough?

A blanket access isn't enough because it automatically grants an agent more than it needs for its actual task. If an AI agent is meant to read out your opening hours but could technically also change your price list, you've created a risk that has nothing to do with the actual task — regardless of whether that agent is trustworthy or simply misconfigured. The principle behind this is as old as IT security itself: access only to what the task requires. With AI agents it's just more urgent, because they act autonomously, often on behalf of a user you'll never see.

What does granular access per data area mean in practice?

Granular access per data area means that for each area of your content — say, opening hours, blog posts, prices or contact requests — you decide individually whether a given key may read, create, edit or delete there. Not "MCP on or off", but a matrix of area and right. A key for PR work, for example, might be allowed to read and create blog posts, but only read prices and never delete anything. A second key, used only by you, can have far broader permissions — because you're the one on the other end taking responsibility.

• Read: the agent can query data but change nothing — the basis for every public AI answer about you.
• Create: the agent can add new entries, such as drafts or new contact requests — existing content stays untouched.
• Edit: the agent can modify existing entries — useful for your own upkeep, risky for outside access.
• Delete: the agent can remove entries — the most consequential right, and the one to grant most sparingly.

Why shouldn't an agent that reads appointments also be able to change prices?

An agent that reads appointments shouldn't also be able to change prices because the two tasks have nothing to do with each other, and a single misconfigured or compromised access would otherwise put several data areas at risk at once. Picture an external booking assistant getting access to your calendar — sensible and practical. If that same key, out of convenience, also had write access to your product prices, a bug in a completely unrelated system would suddenly affect your core business. Separate rights, scoped to the data area, prevent exactly that: a problem in one area stays confined to that area.

What two ways of using MCP should you keep apart?

There are two fundamentally different ways of using MCP, and each needs its own, purpose-cut rights. The first: an external AI service — ChatGPT, Perplexity, a client's assistant — reads public data about your business to answer third parties' questions. Here, the key typically only needs read rights on publicly visible areas, nothing more. The second, often overlooked one: you yourself — or an AI assistant of your choice that you've set up — work directly with your own website. You "talk" to your system: maintaining content, querying your own data, delegating recurring tasks, without clicking through an admin menu.

That second case in particular is one of the core advantages of btlabs Core: you don't just get a website that's AI-readable from the outside — you get your own, secured access that lets you, or your preferred AI acting on your behalf, manage the website directly. Both ways of using it run over the same open standard, just with differently scoped rights: generous for yourself, tightly scoped for outside services. How this fits into the bigger picture of well thought-out AI automation for your business is covered on the linked page.

What does this look like in practice for your business?

In practice, you decide together with us which key may access which data area with which right — before the access is even switched on. One example: a key for an external booking assistant gets read rights on opening hours and availability, but no access to contact data or prices. Your own key for day-to-day upkeep gets read, create and edit rights on content, but deliberately no automatic delete right on customer data. Every access is logged, so you can always trace who accessed what, and when.

How is this different from being "agent-ready"?

Being agent-ready — cleanly readable for external AI agents — is one half of the picture, but it's separate from who gets to access that data with which right. Granular rights per data area are the layer underneath: the access control that makes sure readability doesn't mean uncontrolled access. One makes you findable; the other keeps control in your hands.

How does setting up an access like this actually work?

Setting it up happens in a shared conversation, where we first clarify who will actually use this access, before any key is even generated. It always starts with the purpose: should an external AI service read your opening hours to answer customer questions? Should your own AI assistant help you maintain blog posts? Only from that answer does it become clear which data areas are relevant and which of the four rights — read, create, edit, delete — makes sense for each area.

From there, a key is created that's cut exactly to that purpose, no more and no less. If the purpose changes later — say, because a new AI service comes into play, or you want to hand your own assistant more tasks — we adjust the rights in a targeted way, rather than issuing a new blanket access. That way you keep the overview: you always know which key is meant for whom and what it can do, even as multiple accesses for different purposes accumulate over time.

If you want to find out what granular MCP rights could look like for your own data areas — for external AI services just as much as for your own AI assistant — let's talk it through in a short, no-nonsense conversation.