What Should (and Shouldn’t) Your MCP Be Able to Do?

There’s a natural instinct with new technology to ask: What can we make it do?

With AI agents and Model Context Protocol (MCP), that list is getting longer quickly. Agents can connect to enterprise software, retrieve information, bring together context from different systems, create content, and potentially take actions on a user’s behalf.

That opens up a lot of possibilities. It also raises a question that I think is just as important for enterprise organizations:

What shouldn’t we let it do?

MCP is still new, and we can’t predict every way agents will use the tools made available to them. But we can predict some of the ways things could go wrong if those tools have access they don’t need.

For technology leaders, that makes the conversation about more than connectivity. It’s about control, permissions, accountability, and designing guardrails before you need them.

‍

Start with the right level of access

One of the first principles I’d look for in any enterprise MCP implementation is simple: an agent shouldn’t automatically get more access than it needs to do its job.

When an agent is acting on behalf of a user, it should stay within the boundaries of what that person is already authorized to do. Giving it elevated or service-level privileges creates a separate layer of access that can operate beyond the permissions already established for that user.

That’s why we’ve taken a deliberately constrained approach at Movable Ink. Our MCP Server doesn’t receive elevated privileges simply because it’s an MCP Server. When operating on behalf of an authenticated user, it can only access a subset of the capabilities that person already has permission to use.

But there’s an important catch: not every user has the same level of access. An organization administrator may already have elevated privileges, including the ability to manage users. If an agent inherits every capability available to that administrator, it could make significant administrative changes without ever technically exceeding the user’s permissions.

That’s where more granular controls become important. Enterprises need to consider not only whether an agent has more access than the person using it, but whether every capability available to that person should be available to the agent in the first place. The agent doesn’t need a master key just because the user happens to have one.

There will also be use cases where an agent isn’t acting on behalf of an individual user at all. An organization might want an agent to run a weekly automation, for example. In those cases, a service account paired with explicitly enabled tools can provide a way to support autonomous workflows while maintaining control over what the agent can do.

As AI agents become more capable and enterprises gain confidence in their ability to behave predictably and reliably, these types of workflows will likely become more common. Regardless of how the agent is operating, organizations still need visibility into the activity taking place, the tools being used, and the changes being made.

‍

Consider what happens when AI connects your systems

One of the most useful things about AI agents is their ability to bring together context. It’s also one of the things technology leaders should be paying the closest attention to.

Enterprise software is intentionally designed with boundaries. Different components may be loosely connected for security, privacy, architectural, or operational reasons. An AI agent doesn’t necessarily see those boundaries the same way.

Give an agent access to two tools, and it may combine information from them in a way neither system was originally designed to support. Sometimes that’s exactly the point. 

Imagine an agent has access to both a customer support system and a marketing platform. Information shared with a support team for one purpose could suddenly influence content being created for a marketing campaign, even though those systems and workflows were intentionally kept separate.

That ability to connect context can be incredibly useful, but it also means information can cross boundaries you didn’t expect. Before giving an agent access to multiple tools, consider not only what it can access within each one, but what becomes possible when it can use that information together.

‍

Not all access carries the same risk

It can be helpful to think about agent access as a progression: reading information, drafting something, and making changes that directly affect the customer experience.

Those actions shouldn’t automatically carry the same level of access.

At Movable Ink, we started with read access. From there, agents can support workflows like bringing content into the platform or helping users draft and prepare work.

An agent drafting content is very different from an agent approving that content or editing a live creative without human review. The latter has an immediate impact on the customer experience and carries a greater risk of the agent taking an action you didn’t intend.

Today, I think very few enterprise organizations would be completely comfortable giving an agent that degree of autonomy. That may change as the technology improves and our ability to detect anomalous behavior becomes more sophisticated.

‍

‍

Give the agent what it needs, not everything you have

The same principle applies to data.

An AI agent doesn’t need access to raw customer-level data simply because that data exists somewhere in your technology stack.

Through Movable Ink’s MCP Server, for example, an agent can access information like segment, experiment, campaign, and creative performance. It cannot access individual customer data or the underlying data being imported into the platform.

There’s a big difference between asking an agent to help you understand how a campaign performed and handing it every individual record behind that campaign. If the first gets the job done, there’s little reason to expose the second and introduce unnecessary privacy, security, and data governance risks.

Access should be determined by the job that needs to be done, not by the maximum amount of information technically available.

‍

Remember that agents operate at machine speed

There’s another piece of enterprise governance that’s easy to overlook: usage.

People tend to interact with software at a fairly predictable pace. Agents don’t.

Imagine an agent needs information from an API that returns 100 records at a time. It discovers there are thousands of pages available, so it starts retrieving them one after another. Technically, it’s doing exactly what it was asked to do. But it could also consume significant resources, rack up unnecessary token usage, hit rate limits, or affect system performance.

That means rate limits and usage controls become part of responsible AI design. Agents can consume an enormous number of tokens in a short amount of time, turning an inefficient process into an unexpectedly large IT bill. Thoughtful controls can preserve what makes agents useful while accounting for the speed and scale at which they operate. In some cases, that could mean giving an agent a summary rather than letting it brute-force its way through thousands of individual records.

‍

More access isn’t always better

AI agents become much more useful when they can connect to the tools and context people already rely on to do their jobs. But in an enterprise environment, the goal shouldn’t be to expose every capability simply because you can.

For technology leaders evaluating an MCP, ask yourself these questions: 

• Which tools does the MCP expose?
• What data can those tools access?
• Whose permissions does the agent inherit?
• Can every action be traced back to a person?
• Which actions require human approval?
• What controls are in place around usage and rate limits?

The best place to start is with the access the agent needs. Make sure you know who’s behind it, then expand from there.