Let AI Use Your Systems Without Handing It the Keys

The useful AI work in a business needs the assistant to reach real data: orders, accounts, policies, documents. That is also where the risk is.

An MCP server is how you connect the two. Roles are how you keep it safe.

What an MCP server is

MCP (Model Context Protocol) is the standard way for an AI assistant to use tools you define. Instead of someone pasting data into a chat window, the assistant asks your server, and the server fetches it or does the job.

You decide which tools exist, what they return and what they refuse to do. The assistant can only use what you give it.

Why it suits an internal tool

• No new screen. People stay in the assistant they already use.
• Rules written once. They live in the server, not in everyone’s prompts.
• Not tied to one product. It is a standard.
• Small. A few well-defined tools often do the job.

It is not always the answer. If a form or a spreadsheet does the job, use that. Choose the simplest thing that works.

Where it earns its place

Examples. Anywhere staff ask a colleague, or open three systems, to get one answer.

• Sales: account history, open quotes and last conversations in one summary before a call.
• Finance: month-end checks that compare two sources and flag what does not match.
• Operations: the status of an order or booking, from the live system.
• Documents and policies: an answer with its source, limited to what that person may open.
• Support: a draft reply from the customer’s history, reviewed before it goes.
• HR: an employee’s own leave balance, and only their own.

Each time it is the same: ask in plain language, fetch from the real system, answer within what that person is allowed to see.

Roles keep the data safe

The assistant signs in as a person. It uses a normal sign-in, not a shared password or a master key. The server in the middle holds no database key.

The database applies the rules. The server passes the caller’s own login to the database, which enforces row level security: rules on each table for who may read or write which rows. The same rules apply whichever route the request takes, so there is only one permission list.

Roles are checked on every request. The role is looked up in the database each time, not stored in the login. Change or remove someone’s role and it applies on their next request.

Nothing by default. A new user has no role and sees nothing. Sign-ups are off; people are invited.

Reading and adding are separate. The role that adds data cannot delete it, and a later bad run cannot overwrite a good result.

Data safety

• Fewest tools possible. Every tool is something the assistant can do. Start with one read-only tool and add the next when there is a reason.
• Keys stay out of reach. They live in managed secret stores, never in prompts, files or chat.
• A log that names someone. Who called which tool, and when. Never the token.
• A person approves changes. Reading can be automatic. Anything that changes data or sends something outward is reviewed, or limited to a role trusted with it.
• Assume what it reads is hostile. An assistant reading web pages or emails can be misled by what they say. Its role limits the damage.
• Test the refusals. Run every role against every table, including the cases that must fail.

What it does not fix

Roles protect data. They do not make answers correct, so anything that matters should show its sources and have a person checking it. Roles also need an owner, and access needs reviewing when people join and leave.

Before you connect an AI tool to your data

1. When it signs in, who is it, and what can that person do?
2. If someone’s role changes today, when does the assistant notice?
3. Can it delete or change anything, or only read?
4. Where do the keys live, and who can see them?
5. If it reads something hostile, what is the worst it can do?
6. Afterwards, can you see who asked for what?

Any “I’m not sure” is where to start.

Where to go next

If you are weighing this up for a real system, discuss your AI project and I will tell you whether an MCP server fits or something simpler would do. You can also read about AI agent development.

The same thinking applies to your website. As assistants start acting on sites for customers, a page can offer them a short menu of safe actions. Try the interactive WebMCP lesson to see how that works, in about 20 minutes.