Securing MCP Tool Execution: Why AI Agents Need a Control Plane

By Synrese

AI agents are becoming more useful because they can do more than generate text. They can inspect repositories, read files, query APIs, operate browsers, call databases, send messages, and coordinate work across services. The Model Context Protocol, or MCP, is one prominent development in that shift because it gives agent systems a more consistent way to connect with external tools and context.

That consistency is useful. For developers and platform teams, MCP can reduce the amount of one-off integration work required to connect an agent to a filesystem, database, SaaS API, internal service, or local automation tool. Instead of every agent runtime inventing its own tool interface, MCP provides a protocol layer that can make tool discovery and invocation more standardized.

But standardizing tool access also changes the risk profile.

When an agent can call tools, it is no longer only producing suggestions. It may be able to read private data, mutate application state, write files, trigger workflows, send messages, or call APIs using credentials that belong to a user, team, or service account. The security question is not simply “does this agent produce good answers?” It becomes “what is this agent allowed to do, under which identity, in which environment, with what review, and with what audit trail?”

That is where a control-plane approach becomes important. MCP can help define how agents and tools connect. It should not be treated as a complete security boundary by itself. Teams adopting MCP-enabled workflows need an operational layer around tool execution: one that can enforce policy, route approvals, manage identity, constrain credentials, record actions, and fail safely when something goes wrong.

For background on how agents differ from simpler coding assistants, see Synrese’s guides to AI coding agents and AI coding agents vs. AI coding assistants. Browser and research-oriented agents raise related issues, especially when they operate across untrusted web content; see AI agent browsers for research workflows.

MCP expands the agent execution surface

MCP is designed to help applications provide context and tools to large language model systems. The project documentation describes MCP as a protocol for connecting AI applications with external systems, and the public GitHub organization hosts specifications, SDKs, and related implementation resources.

That matters because tool access has historically been fragmented. A development team might wire one agent to a local shell, another to a database, another to GitHub, and another to an internal documentation search API. Each integration might have its own permissions model, logging format, credential handling, and approval behavior. MCP can make that ecosystem more interoperable by giving tool providers and agent clients a shared interface.

The tradeoff is that interoperability can make execution easier to scale before governance catches up. If more tools become available to more agents through a common interface, teams need to understand the aggregate execution surface. A single tool may look low-risk in isolation. A set of tools can create new combinations: read a file, summarize it, call an API, write a ticket, send a message, or update a database.

This does not mean MCP is inherently unsafe. It means MCP-enabled environments need the same kind of operational thinking that teams already apply to CI/CD systems, cloud consoles, database access, internal admin tools, and production automation. The agent is another actor capable of initiating work. The security model must account for that actor.

What MCP does and does not solve

MCP is best understood as a protocol and integration layer, not as a complete governance system for every organization that adopts it. It can help define how a client discovers tools, exchanges context, and invokes capabilities exposed by servers. That is valuable protocol-level work.

But security still depends on implementation choices around the protocol.

For example, a filesystem MCP server may expose read or write capabilities. Whether those capabilities are restricted to a workspace directory, allowed to touch home-directory secrets, or permitted to modify production configuration is not solved merely by the existence of a protocol. A database tool might support useful read-only exploration, but the operational risk changes if it can run write queries against production. A browser automation tool might help with research, but it can also interact with logged-in web applications if not constrained.

The practical distinction is this:

MCP can standardize access.

A control plane governs execution.

That governance layer should answer questions such as:

  • Which tools exist in this environment?
  • Which users, agents, and workspaces can access each tool?
  • Which actions are read-only, write-capable, destructive, or externally visible?
  • Which calls require human approval?
  • Which identity is used when a tool call reaches an external service?
  • Are credentials scoped, isolated, and rotated?
  • Are tool calls logged in a way that can support debugging, incident review, and compliance workflows where required?
  • What happens when the approval service, OAuth flow, policy engine, or gateway is unavailable?

Microsoft’s developer blog post on securing MCP offers one useful control-plane framing for agent tool execution, though it should not be treated as the official MCP security model.

Why tool execution needs a control plane

A control plane is the layer that manages how execution is authorized, constrained, observed, and reviewed. In infrastructure, control planes are used to coordinate access to compute, networking, deployments, identities, and policies. For AI agents, the same concept can be applied to tool execution.

The reason is straightforward: agents can translate natural-language intent into concrete actions. A user might ask an agent to “clean up old files,” “update the staging database,” “send the customer a summary,” or “fix the deployment.” Each request may require judgment. Some actions are harmless. Some are reversible. Some are visible to customers. Some can delete data, expose secrets, or change production behavior.

A control plane gives teams a place to encode that judgment outside the model prompt.

Prompts are not enough. System instructions and tool descriptions can guide agent behavior, but they should not be the only barrier between an agent and a sensitive operation. A model may misunderstand context, receive malicious instructions from untrusted content, or generate a plausible but inappropriate tool call. A control plane can provide deterministic checks around the action itself.

In practice, that means evaluating the requested tool call before it executes. The evaluation may consider the user, the workspace, the tool, the action type, the target environment, the data classification, the requested parameters, and the history of prior actions. Low-risk calls may proceed automatically. Higher-risk calls may require approval, a narrower credential, a sandbox, or denial.

This is especially important as agent workflows become longer-running and more autonomous. A single agent run may include many steps. Without a control plane, teams may only discover after the fact that the agent used a tool in an unexpected way. With a control plane, each step can be mediated.

Core control-plane capabilities developers should evaluate

A useful control plane does not need to start as a large platform. For many teams, it can begin with a gateway, policy layer, and audit log around MCP server access. The important point is to make tool execution explicit and governable.

Tool registry and capability inventory

Teams should know which MCP servers are available, who owns them, what systems they connect to, and what actions they expose. A tool registry should distinguish between read-only search, local file reads, file writes, database mutations, external API calls, browser actions, messaging, infrastructure operations, and deployment-related actions.

The inventory should be understandable to both developers and security reviewers. A tool named query_database is not enough if it can reach production customer data. A tool named send_message is not enough if it can send external email, Slack messages, or customer notifications.

Permission scoping

Permissions should be scoped by user, role, workspace, environment, tool, action, and data sensitivity where possible. An agent working in a local development directory should not automatically inherit access to production infrastructure. A tool used for staging diagnostics should not silently switch to production because a parameter changed.

Least privilege matters here. If a tool only needs read access to documentation, it should not receive credentials that can modify source repositories or internal systems. If a database task is exploratory, read-only credentials are preferable to broad application credentials.

Human approval flows

Human approval is not a complete security solution, but it is a useful risk-reduction mechanism for high-impact actions. Approval gates are especially relevant for file writes outside a sandbox, database mutations, outbound messages, purchases, infrastructure changes, deployments, and destructive operations.

Approval prompts should be specific. “Allow tool call?” is weak. A better approval request explains what tool will run, which identity will be used, what system will be affected, what parameters are involved, and whether the action is reversible.

For developer workflows, inline diffs can be helpful before file writes. For infrastructure workflows, a plan-style preview can reduce ambiguity. For messaging workflows, the exact outgoing message should be reviewable before it is sent.

Identity and authentication

A mature approach should avoid giving agents broad shared secrets. Where feasible, tool calls should use scoped identities, user-bound authorization, service accounts with limited permissions, or short-lived credentials. OAuth-based flows may help in some settings, but they still require careful scope selection, token storage, revocation behavior, and auditability.

The key question is attribution. If an agent calls a tool, can the team determine which user initiated the workflow, which agent runtime performed the call, which credential was used, and which downstream system accepted it? Without attribution, investigation becomes difficult.

Credential isolation

Agents should not be able to freely read or exfiltrate secrets just because they can access a filesystem, environment variables, shell commands, or logs. Credential handling should be separated from general tool execution where possible. A tool may need to act with a credential, but the model does not necessarily need to see the credential.

This distinction is important. Passing secrets through prompts, transcripts, or model-visible tool outputs increases exposure. A gateway or broker can use credentials on behalf of a tool call without returning the raw secret to the agent.

Execution boundaries

Execution boundaries can include sandboxing, network restrictions, filesystem allowlists, environment separation, rate limits, and egress controls. A local development agent may need access to a project directory, but not to every file in a user’s home directory. A browser agent may need to open public documentation, but not authenticated admin panels. A database tool may need to query staging, but not production.

These boundaries should be enforced outside the model. The model can be instructed not to access certain resources, but the runtime should also make those resources unavailable unless explicitly permitted.

Logging and auditability

Tool execution should produce useful logs. At minimum, teams should consider recording:

  • the initiating user or workflow;
  • the agent or client involved;
  • the MCP server and tool name;
  • the requested action and parameters, with sensitive values redacted where appropriate;
  • the approval decision, if any;
  • the identity or credential class used;
  • the target system or environment;
  • the result or error;
  • timestamps and correlation IDs.

Logs should be designed carefully. Logging everything can create privacy and security problems if sensitive data is captured unnecessarily. Logging too little can make incident response and debugging difficult. The right balance depends on the systems connected to the agent.

Policy-as-code

Policy-as-code can make execution rules reviewable, testable, and versioned. Instead of relying on informal convention, teams can define rules such as:

  • read-only documentation search is allowed for all development workspaces;
  • writes outside the repository root require approval;
  • production database writes are denied unless initiated through a specific workflow;
  • outbound customer messages require human review;
  • credential access tools are unavailable to general-purpose agents;
  • browser tools cannot access internal admin domains unless explicitly authorized.

Policy-as-code also makes changes visible in code review. That is useful because tool access often expands gradually. A small permission change can have a large operational effect.

Failure handling

Control planes need safe failure modes. If an approval service is unavailable, should high-risk actions fail closed? If an OAuth refresh fails, should the agent retry, ask the user, or stop? If a policy engine cannot evaluate a request, should the default be allow or deny?

For sensitive actions, fail-closed behavior is generally safer. But teams should decide this explicitly. Ambiguous failure behavior can become a security gap or an operational reliability issue.

Practical risk scenarios

MCP-enabled tools can be safe and useful when configured carefully. The risks come from what connected tools are allowed to do, how much context the agent receives, and whether untrusted content can influence execution.

Filesystem access

A filesystem tool may let an agent inspect a project, generate patches, or reorganize files. That is useful for development. But broad filesystem access can expose SSH keys, shell history, cloud credentials, private notes, or unrelated repositories. Write access can also damage workspaces if the agent modifies the wrong path.

Practical controls include workspace allowlists, read-only defaults, explicit approval for writes, diff previews, and denial of access to known secret paths.

Database tools

Database tools can help agents inspect schemas, generate queries, and debug application behavior. The risk increases when a tool can access sensitive data or perform writes. An unintended query can expose more data than needed. An unintended mutation can corrupt state.

Safer patterns include read-only credentials by default, separate staging and production access, query limits, parameter validation, sensitive-table restrictions, and approval for write operations.

Browser and computer-use agents

Browser or computer-use agents can interact with websites and applications through a graphical interface. Anthropic’s computer use documentation is relevant here because it discusses agents operating computers and the need to think carefully about boundaries and oversight. Browser agents may encounter prompt injection in web pages, emails, documents, or issue comments. They may also click through workflows that have real-world effects.

Controls include domain allowlists, session isolation, human confirmation before submissions, restricted authentication contexts, and clear handling of untrusted content.

Messaging tools

Messaging tools are powerful because they turn agent output into external communication. An agent that drafts a message is different from an agent that sends it. The second case can create reputational, legal, or operational consequences if the message is wrong, premature, or sent to the wrong recipient.

Teams should require review for external messages, customer-facing communications, and broad internal broadcasts. The final message body and recipients should be visible before approval.

Broad API credentials

API tools often inherit the permissions of the credential they use. If a token can read, write, delete, and administer a service, then an agent using that token may be able to trigger those actions unless the gateway constrains them.

Prefer narrowly scoped tokens, per-tool credentials, short-lived credentials, and downstream permission checks. Avoid placing high-privilege tokens in environments where general-purpose agents can reach them.

Prompt injection and untrusted content

Prompt injection is especially relevant when tools retrieve untrusted content from web pages, tickets, documents, emails, or chat messages. A malicious instruction embedded in retrieved content may try to influence the agent into calling another tool, revealing data, or changing behavior.

The practical response is not to assume the model will always ignore malicious text. Treat untrusted content as data. Keep sensitive tools behind policy checks. Require approvals for high-risk actions. Avoid passing secrets into contexts that include untrusted input.

Cross-tool escalation

Some risks emerge only when tools are combined. A low-risk web lookup may retrieve text that instructs the agent to call a messaging tool. A repository search may reveal a deployment script. A database read may produce a list of customer emails that another tool could message. A filesystem read may expose configuration that changes how an API tool is used.

Control planes should evaluate action chains, not only individual tools in isolation. Even if every single step looks plausible, the sequence may cross a risk boundary.

Thinking in policy tiers

A practical way to start is to classify tool calls into policy tiers.

Low-risk actions

Low-risk actions are typically read-only, local, non-sensitive, and reversible. Examples might include searching public documentation, reading files inside a sandboxed test repository, or listing available tools. These actions may be allowed automatically if logs are retained.

Medium-risk actions

Medium-risk actions may include external lookups, internal documentation reads, temporary file writes, staging environment changes, or queries against non-sensitive internal systems. These may require additional logging, rate limits, workspace restrictions, or user confirmation depending on the organization.

High-risk actions

High-risk actions include production writes, access to customer data, outbound messages, infrastructure changes, payment-related actions, credential-adjacent workflows, and database mutations. These should generally require stronger identity, explicit authorization, and human approval.

Critical actions

Critical actions include destructive operations, privileged administration, deployment to production, data deletion, permission changes, and irreversible external effects. Some teams may decide that general-purpose agents should not be able to perform these actions at all. Others may allow them only through tightly controlled workflows with multi-party approval and strong audit trails.

The point is not that every team needs the same tiering model. The point is that tool risk should be classified deliberately, not discovered accidentally.

Implementation checklist for teams adopting MCP tools

Teams evaluating MCP-enabled agent workflows can use the following checklist as a starting point:

  • Inventory every MCP server available to agents.
  • Document each tool’s owner, purpose, downstream systems, and action types.
  • Classify tools by risk level: low, medium, high, or critical.
  • Separate read-only tools from write-capable tools.
  • Use least-privilege credentials for each tool.
  • Avoid broad shared secrets where scoped identities are available.
  • Keep credentials out of model-visible context wherever possible.
  • Restrict filesystem tools to approved directories.
  • Separate development, staging, and production access.
  • Require approval for high-impact actions.
  • Show clear previews for file writes, messages, deployments, and database mutations.
  • Log tool calls and responses where appropriate, with sensitive data redacted.
  • Review how tools handle untrusted content.
  • Test denial paths, failed approvals, expired credentials, and unavailable gateways.
  • Define safe defaults when policy checks fail.
  • Rate-limit tools that can create cost, load, or external side effects.
  • Document ownership for each MCP server and connected system.
  • Review policies whenever tools, agents, or connected services change.

This checklist is intentionally operational. MCP security is not only a protocol question. It is also a workflow, identity, logging, and change-management question.

Where the ecosystem signals point

Recent documentation and product signals suggest that tool governance is becoming a more visible platform concern.

The Microsoft Developer Blog article on securing MCP with a control-plane approach is a clear signal that major developer platform teams are thinking about MCP tool execution as a governance problem. It should be read as one informed perspective, not as the official security model for MCP or as a substitute for primary protocol documentation.

The MCP documentation and GitHub organization provide the protocol-level context: what MCP is intended to connect, how the ecosystem is organized, and where specifications and SDKs are published. Those sources are the right place to verify MCP terminology and protocol behavior.

Anthropic’s computer use documentation and OpenAI’s agents/tools documentation provide broader context for agent systems that can call tools or operate external environments. They are useful for understanding the general move from text generation toward tool-mediated execution, but they should not be treated as MCP-specific security guarantees.

Some agent-platform release notes, including recent Hermes Agent releases, indicate active product work around tool gateways, approvals, OAuth, credential handling, background execution, and workflow controls. Those release notes are useful evidence of product direction in the agent ecosystem. They should not be overstated as proof that any particular workflow is secure. Product capabilities change, and security claims require primary documentation, configuration details, and, where relevant, advisories or audits.

The common thread is that agent tool execution is becoming a platform concern. As tools become easier to attach, teams need better ways to decide which actions should run, which should be reviewed, and which should be unavailable.

Source URLs

Bottom line

MCP can make agent tooling more interoperable. That is valuable for developers building practical workflows across filesystems, APIs, databases, browsers, messaging systems, and internal services. But interoperability should not be mistaken for complete safety.

The central security issue is tool execution governance. Once an agent can act in real systems, teams need policy enforcement, scoped identity, credential isolation, approval routing, execution boundaries, and audit logs. Those controls should sit outside the model prompt and apply at runtime, before sensitive actions occur.

A control-plane approach gives developers and platform teams a way to move from ad hoc tool access to governed execution. It does not eliminate risk. It does, however, make risk more visible, reviewable, and manageable as MCP-enabled agents become part of everyday engineering workflows.