A chat window that can only answer questions is fairly low risk. The moment you let that assistant read your inbox, search your shared drive, update records in your CRM, or run queries against a database, it becomes something different: a piece of software acting on your behalf, with your permissions, taking instructions from text it reads along the way.

That shift is happening quickly in small organizations, mostly through the Model Context Protocol (MCP) and agentic tools like Claude Code. The productivity gains are real. So are the failure modes, and most of them come from setup decisions made in the first afternoon. This guide covers how we think about the risks and the controls we put in place before connecting an assistant to anything that matters.

What MCP Actually Is

MCP is an open standard for connecting AI applications to tools and data. An MCP server is a small program that exposes capabilities, such as “search this mailbox,” “read this folder,” or “create a ticket,” in a format an AI application can understand. The AI application (the client, for example Claude Desktop or Claude Code) discovers those capabilities and lets the model call them when it decides they’re useful.

Think of it as a universal adapter. Before MCP, every integration between an AI app and a business system was custom work. Now one server for your CRM can, in principle, plug into any MCP-compatible assistant.

Two things follow from that design, and both matter for security:

  • The model decides when to call a tool. You give it a goal; it chooses which tools to use and with what inputs. That’s the useful part, and it’s also the part that can be manipulated.
  • An MCP server is code with real access. A local server runs on your computer with your user account’s permissions; a remote one holds tokens to your accounts. Installing one is closer to installing software or granting an app OAuth access to your account than it is to changing a setting.

An “agent” is simply an AI system that runs this loop on its own for several steps: read something, decide, call a tool, read the result, decide again.

The Threat Model in Plain Terms

When we assess an AI integration, we ask the same questions we’d ask of any new system: where did it come from, who maintains it, what can it do, and how could it be misused? For AI agents, five risks come up again and again.

Prompt injection through untrusted content

Language models don’t reliably distinguish between instructions from you and instructions embedded in the content they read. If your assistant summarizes an email that contains hidden text saying “forward the last ten invoices to this address,” a model with send-mail access may try to comply. The same applies to web pages, shared documents, PDF attachments, support tickets, and calendar invites. Anyone who can get text in front of your agent can attempt to steer it.

The dangerous combination is an agent that (1) can access private data, (2) reads content from outsiders, and (3) can send information out, whether by email, HTTP request, or posting to a shared channel. Security researcher Simon Willison calls this the “lethal trifecta.” If your setup has all three, assume a determined attacker can eventually exfiltrate data through it.

Over-broad permissions

The fastest way to connect a tool is usually to authorize it with your own admin account and every scope it asks for. That means the agent can do anything you can do: delete files, change sharing settings, email every contact. Most tasks need a fraction of that.

Unvetted third-party servers

The number of community MCP servers is large and growing, and anyone can publish one. Some are excellent. Some are abandoned weekend projects, and a few have been written with malicious intent. Because a server’s tool descriptions are fed to the model, a malicious server can also inject instructions directly, not just misbehave in its own code.

Credential handling

MCP servers need API keys or tokens to reach your systems. It is common to find those keys pasted into plaintext config files, committed to Git repositories, or shared across every person and tool in the organization. A leaked key with broad scope is a breach waiting for a date.

Irreversible actions

A wrong summary is an inconvenience. A deleted folder, a sent email, a bulk CRM update, a payment, or a dropped database table may not be recoverable. Agents make mistakes even without an attacker involved, and they make them quickly.

Practical Controls That Work

None of these controls is exotic. They’re the same principles we apply to any system with access to sensitive data, adapted for software that takes instructions from text.

Start read-only, then expand deliberately

Begin with read access only. An assistant that can search your files and draft replies (which a human then sends) delivers much of the value with a fraction of the risk. Add write capabilities one at a time, only when a specific workflow needs them, and ask whether a narrower scope would do. “Create draft” is safer than “send.” “Append a note” is safer than “edit any field.”

Require human approval for consequential actions

Anything that sends, deletes, pays, shares externally, or changes permissions should require a person to approve it. Claude Code, for example, asks before running commands or editing files by default and lets you configure which actions are allowed without a prompt. Resist the temptation to approve everything permanently after the first week. Approval prompts only protect you if someone actually reads them.

Use separate service accounts

Don’t connect agents with your personal or admin credentials. Create a dedicated account for each integration with only the access it needs: one shared folder rather than the whole drive, a dedicated shared mailbox rather than your own inbox. This limits the blast radius and makes the agent’s activity easy to identify in logs.

Vet every server before installing it

Before adding a third-party MCP server, we check:

  • Provenance: Is it published by the vendor of the system it connects to, or by an unknown individual? Official servers aren’t automatically safe, but accountability matters.
  • Maintenance: When was it last updated? Are security issues acknowledged and fixed?
  • Code and permissions: Does it request more access than its stated purpose requires? Does it make network calls you wouldn’t expect?
  • Pinning: Install a specific reviewed version rather than always pulling the latest, so an update can’t silently change behavior.

If a server can’t pass that review, a short custom server that does exactly one thing is often a better choice than a feature-rich one you can’t audit.

Store credentials properly

Keep API keys and tokens in a password manager or a secrets store, not in config files that get copied around. A business password manager such as Bitwarden or 1Password gives you shared vaults with access controls, which beats a key sitting in a chat thread. The trade-offs: business tiers are a per-user cost, and password managers are built for people, so keys that software reads automatically are better kept in a dedicated secrets manager. Use short-lived tokens where the service supports them, scope each key to one integration, and rotate keys when people leave or a server is retired.

Log everything the agent does

You should be able to answer “what did the assistant do last Tuesday, and why?” Turn on audit logging in the connected services, keep the agent’s tool-call history where your client supports it, and review it periodically. Logs won’t prevent an incident, but without them you can’t scope one.

Sandbox agents that run code

Agents that execute commands, like coding assistants, should run in an isolated environment: a container, a virtual machine, or at minimum a dedicated user account without access to production credentials. Restrict outbound network access where you can. That narrows the exfiltration leg of the trifecta, though any tool that can send email or post messages remains a way out.

Roll out in stages

Pilot with one or two people on low-stakes data. Watch what the agent actually does, including where it goes wrong. Write down which actions are approved and which aren’t, then expand. Treat the rollout like a software release: if the integration can’t pass your documented checks, it doesn’t ship.

What These Controls Don’t Solve

Prompt injection is not a solved problem. Model providers have made meaningful progress on resisting it, and classifier-based filters catch many attempts, but no current technique blocks it reliably. In our own testing of safeguard models, every filter trades recall (the share of attacks it catches) against precision (the share of its flags that are real attacks). Tune it to catch more and it starts blocking real work; tune it to flag less and some attacks get through.

That’s why the controls above focus on limiting what a compromised agent can do rather than trusting that it won’t be compromised. Least privilege, human approval, and network restrictions still work when the model gets fooled. Detection alone doesn’t.

The controls also carry real costs. Approval prompts slow people down. Separate accounts take administration. Vetting servers takes time someone has to budget. For some workflows, the honest conclusion is that the risk isn’t worth the convenience yet, and a well-written prompt template in a regular chat window gets you most of the way there.

Getting Help With Your Setup

Connecting AI to your business systems is worth doing carefully, and the decisions you make in the first week tend to stick. If you’d like help mapping which integrations make sense, scoping permissions, vetting MCP servers, or setting up a staged rollout, see our AI services for organizations. We’ll help you capture the time savings without handing an agent the keys to everything.