An AI assistant in every app, under the same rules

What MCP is

MCP, the Model Context Protocol, is an open standard for how an AI assistant reaches a tool outside itself: what operations the tool offers, how the assistant calls one, and what comes back. Claude supports it, and so does a growing list of other assistants. A tool that speaks MCP can be connected to any of them without someone writing an integration for each.

What the standard does not settle is the part IT cares about: who the assistant is when it calls the tool, and therefore what it is allowed to see and change. That is decided by how the connection signs in — and it varies enormously from one product to the next.

The risk is the key, not the assistant

The usual way to give an assistant access to a system is a key: an API token or a service account, pasted into the assistant’s settings once. It is quick, and it quietly changes who is asking. Every question now runs with the key’s access, not the access of the person typing — and keys are almost always made broad, because a narrow one keeps breaking.

• The intern sees what the key sees. Whoever uses the assistant inherits the key’s reach, so rules that keep people out of each other’s records stop applying.
• The log says the key did it. An audit trail that records the service account cannot tell you which person asked for what.
• The key outlives the person. When someone leaves, their directory account is closed. The token in an assistant’s settings is not.

None of this is new. It is the same problem as a shared password, made worse by a tool that is very good at reading everything it is allowed to.

What to ask before connecting one

• Who is the assistant when it calls? The answer you want is “the person using it, signed in the usual way”. A shared key or a service account is the answer to worry about.
• Do the same rules apply? Roles, record-level rules and anything else that limits a person in the app should limit the assistant acting for them — enforced by the system, not by the assistant’s good behaviour.
• What can the credential be used for? A token handed to an assistant should be good for that connection and nothing else, not a general key to the rest of the system.
• Can it write? Reading is one decision, changing and deleting another. Find out whether the assistant can do both, and how you would keep it to reading.
• What happens when someone leaves? Closing their account in the directory should end the assistant’s access along with everything else.

How it works on Softeria: built into every app

Every app built on the platform answers MCP at its own address with /mcp on the end — the address you would open the app at, on our domain or on your own. There is nothing to install, deploy or switch on.

• Add a connector. In Claude: Settings → Connectors → Add custom connector. Other MCP-capable assistants have the same step.
• Paste the address. For example https://app.your-company.com/mcp.
• Sign in. The app’s own login page opens. Sign in exactly as you always do — the same account, the same buttons.
• Approve. That is the whole setup. Ask for something in the conversation and the assistant goes and gets it.

It signs in as you

Every call the assistant makes runs as the person who signed in. Roles, access rules and security policies apply exactly as they do in the app: no bypass, no admin mode, nothing reachable that the person could not reach themselves. An inspector’s assistant sees the inspector’s region.

So when an assistant says it is not allowed to see something, that is the person’s access working, not a broken connection — and the fix is wherever that access is decided, not a reconnect. The credential the assistant ends up holding is good for the app’s MCP address and nothing else; it cannot be turned around and used as a general key to the API.

What it can reach

The app’s data, as operations named after it: it can read, create, change and delete records in collections and views, read queries, and call functions. Reading is the real thing — filtering, sorting, paging, picking fields, pulling in related records, and search where it is turned on.

A real app adds up to hundreds of operations, more than an assistant can hold at once, so it is not handed the list. It searches for the one it needs by name, reads its contract and runs it — and the names follow your data model, so what the assistant says it did lines up with what you called things.

Where to be careful

Creating, changing and deleting through an assistant are ordinary writes. Functions that run on a change run, and a delete cannot be undone.

The assistant cannot warn you which is which. Everything it does reaches the app through one and the same operation, so its approval prompt looks identical whether it is about to list ten orders or delete one. That means “always allow”, granted once during a harmless lookup, also approves every change and delete that follows. Approve changes one at a time — and for work that should only ever read, sign in with an account whose role grants reading only.

• Very large answers stop at about a megabyte of text. Past that the assistant is told to narrow the request, rather than handed a cut-off answer it might report as complete.
• Files do not come back. The assistant is told a file exists, its type and its size; open it in the app. A small file can be sent with a new record.
• Each request stands on its own. Nothing is held open between them, so long-running work belongs in a function, not in a conversation.

The part worth keeping

Whatever you connect an assistant to: make it sign in as the person, under the rules that already apply to them, with a credential that is good for nothing else. Then an assistant is just another way of using the app — and the question of what it may see has the same answer as the question of what the person may see, which you have already answered once.