Until recently, connecting an AI assistant to your accounting system, CRM or database meant custom development. Now there’s a standard for it. The Model Context Protocol, or MCP, lets AI tools plug into other systems through connectors called MCP servers. Many software vendors now offer one, and building your own is straightforward.
That’s good news, because AI is only as useful as the information and actions it can reach. But it moves the important question somewhere new. Once an agent can read your customer list or create a bill, the question isn’t how clever the model is. It’s what the agent is allowed to do, and whose permissions it’s using to do it.
What MCP actually changes
An MCP server sits between the AI and one of your systems. It offers the AI a set of tools, such as “search invoices”, “look up a customer” or “create a draft quote”, and carries out those actions when the AI asks.
Two things follow from that. First, the tools the connector offers set the outer limit of what the agent can do. A connector that only offers read tools can’t change anything, however the agent is prompted. Second, every action still happens in your real system, under some identity, with some set of permissions. MCP doesn’t replace your security model. It relies on it.
Whose permissions is the agent using?
This is the question that matters most, and there are really only three answers.
The agent acts as the person using it. The user signs in, and the agent can do exactly what that person can do, no more. The MCP specification is built around this model for connectors over the web: the AI tool makes requests on behalf of the user, with access tokens issued for that specific connector. For assistants that help people with their own work, this is the right default. A sales rep’s agent sees the sales rep’s customers. A junior’s agent can’t approve what the junior can’t approve.
The agent has its own identity. Background agents that run on a schedule, or work through a shared inbox, can’t borrow a person’s login. They need an identity of their own, and that identity needs its own tightly scoped permissions. This is where most of the risk sits, because the easy option is usually far too broad.
The agent uses a shared admin login. A connector set up with an administrator account, a master API key or a database login that can do anything. It’s quick to set up and it’s the most common mistake we see. Whatever the agent is asked to do, by a user or by a cleverly worded email it happens to read, it can do with full access.
Make the target system enforce the limits
The safest agents get their limits from the systems they connect to, not from instructions in a prompt. OWASP’s guidance on excessive agency in AI applications makes the same point. Keep the functions available to an agent to a minimum, keep its permissions in downstream systems to a minimum, run actions in the context of the user where you can, require approval for high-impact actions, and enforce authorisation in the downstream system rather than trusting the AI to decide what’s allowed.
In practice that means using the role-based access control your systems already have:
- Read-only logins for anything that only needs to look. An agent that answers questions about sales doesn’t need a database login that can write.
- Roles that match the job. If your CRM has a “sales user” role, the agent’s identity gets that role, not “administrator”.
- Scopes that match the task. Many systems let you limit an app to specific mailboxes, sites, folders or companies. Use them.
Microsoft 365 is a good example of why the detail matters. An app can be given permission to send email, and in Exchange Online that permission can be limited to a single mailbox using role-based access control for applications. Microsoft notes that these grants add to any permissions given in Entra ID. So if the same app also has a tenant-wide “send mail” permission in Entra, the mailbox limit achieves nothing. An app that sends website enquiries should be able to send from one shared mailbox, not as anyone in the company.
Separate looking from doing
A simple pattern that removes a lot of risk is to split read and write into different connectors, or different identities. The agent that searches, summarises and drafts gets broad read access to what it needs. Anything that writes, such as creating a bill, updating a customer record or sending an email, goes through a narrower path with its own permissions, and usually a person approving it.
This also makes testing easier. You can give people the read-only agent early, learn how they use it, and add carefully chosen write actions later.
Be careful what you install
MCP servers are software, and some run on your own computer with your own access. The MCP project’s own security guidance warns that local servers run with the same privileges as the application that starts them. Treat a new connector like any other software you’d install: know who made it, check what it can reach, and prefer official connectors from the vendor of the system you’re connecting.
If you’re building connectors, the specification is also clear that a connector shouldn’t pass a user’s login token straight through to other services. Each connection gets its own properly issued token, which keeps audit trails honest and stops one connector becoming a skeleton key to everything else.
Before you connect an agent to a system
Work through these steps for each connection:
- List the tools the connector offers, and switch off any the agent doesn’t need.
- Decide whose permissions it uses. The user’s, for assistants. Its own tightly scoped identity, for background agents. Never a shared admin login.
- Set the limits in the target system: roles, scopes, mailbox or site restrictions, read-only database logins.
- Check for broad grants elsewhere that would cancel out those limits, such as a tenant-wide permission sitting alongside a scoped one.
- Separate read from write, and put a person in front of anything that moves money, changes core records or contacts customers.
- Log every action with the identity that took it, so you can see what happened and why.
- Review access regularly, and whenever a new tool or connector is added.
Where to start
Pick one system an agent connects to today, or will soon, and answer one question honestly: if the agent did everything its permissions allow, what’s the worst that could happen? If the answer worries you, the permissions are too broad. We design and review agent access, connectors and integrations as part of our AI and agents and integration and automation work. Get in touch if you’d like a second pair of eyes.