← Back to blog

When AI Agents Stop Talking and Start Acting

An AI assistant that can answer questions is useful. An AI agent that can check a customer account, retrieve an invoice, query an internal database, update a CRM record, create a support ticket, or trigger a business workflow can be far more valuable.

It can also create a very different class of risk.

As companies move from generative AI experiments to production AI agents, the difficult problem is no longer only whether a model can produce a good answer. It is how to give that model controlled access to the systems it needs in order to do useful work.

Consider a customer operations agent. To resolve one case, it may need to identify a customer in Salesforce, check an order in an internal database, retrieve shipping information from a logistics platform, read support history, and prepare a refund or replacement. Each system has its own API, authentication model, permissions, data structures, and operational rules. Multiply that across several agents and dozens of systems, and integration complexity grows quickly.

Model Context Protocol, or MCP, addresses part of that problem by providing a standardized way for AI applications to discover and interact with external tools, resources, and services. The MCP project has also moved steadily toward the concerns that appear once those connections reach real organizations, including scalability, enterprise authorization, agent identity, governance, and security. (MCP roadmap)

That standardization is valuable. A company building several AI applications should not have to recreate the same CRM, database, developer-tool, and internal-search integrations for every new agent.

But standardization raises a more important question:

What should an AI agent actually be allowed to do once it is connected?

An agent may choose which tool to call based on a user's request, information retrieved from another system, the contents of a document, or instructions embedded in data it has just consumed. It may combine permissions from several systems in ways that no individual integration was designed to anticipate. Its path from input to action may also be less deterministic than a conventional application.

A support agent that can read an order status is one thing. An agent that can read customer records, issue refunds, send external messages, modify accounts, and interact with production systems is another.

This is why connecting AI agents to enterprise systems cannot be treated as an integration problem alone. It is also an identity, authorization, governance, observability, and autonomy problem.

The 2026-07-28 MCP specification made substantial progress toward production deployment, including a stateless protocol core, header-based routing for gateways, authorization hardening, and a formal extensions framework. But no protocol can decide an organization's security policy for it. MCP can standardize how an AI application reaches a tool; it cannot, by itself, determine whether the agent should use that tool, what limits should apply, when a human must approve an action, or how much damage a compromised or mistaken agent should be able to cause. (2026-07-28 MCP specification)

Those decisions belong to the architecture around MCP.

This guide explains how that architecture should be designed, where the main security risks appear, how authorization differs from permission to execute a specific action, and how enterprises can give agents enough access to be useful without giving them more authority than the task requires.

What MCP Changes in Enterprise AI Architecture

At its simplest, MCP is a standard way for AI applications to interact with external systems.

Those systems may be databases, internal APIs, developer tools, document repositories, SaaS applications, search services, or almost anything else an AI application needs to access.

Conceptually:

AI Application / Agent
          │
          ▼
      MCP Client
          │
          ▼
      MCP Server
          │
          ▼
External System

The application in which the model operates is typically the host. The host contains an MCP client that communicates with one or more MCP servers. Those servers expose capabilities the application can discover and use.

An MCP server does not replace the underlying CRM, database, GitHub repository, ERP API, or internal service. It provides a standardized AI-facing interface to them.

Three primitives are especially important:

• Tools expose operations that can be invoked, such as searching for a customer, creating a ticket, querying an order system, or calling an internal API.
• Resources expose information that applications can read and use as context, such as documentation, records, files, or repository artifacts.
• Prompts provide reusable templates or instructions for model interactions.

The distinction between them matters because reading information and performing an action create different risk profiles. Exposing an employee handbook as a resource is not equivalent to exposing a tool that can change payroll information.

From One-Off Integrations to Reusable Infrastructure

Without a common layer, different teams often build similar integrations repeatedly. A sales agent may have one Salesforce connector, a support agent another, and a third application its own database access logic. Authentication, schemas, monitoring, and permission handling become inconsistent even when the underlying business system is the same.

MCP creates the possibility of treating those connections as reusable infrastructure:

                     ┌── CRM MCP Server
                     ├── Support MCP Server
AI Applications ─────┼── ERP MCP Server
                     ├── Developer MCP Server
                     └── Internal Data MCP Server

A well-designed CRM MCP server can expose a controlled set of capabilities to several authorized applications. Changes to the underlying CRM API can then be handled at that integration boundary rather than independently inside every agent.

This does not remove integration work. It changes where the work lives.

It can also reduce application-level coupling. If a capability is exposed through a standard interface rather than embedded only inside one vendor's agent implementation, another compatible host may be able to use it later. That does not make the enterprise fully vendor-neutral, but it can prevent every business integration from becoming inseparable from the first AI application that needed it. The official MCP SDK is designed around this separation between servers that expose capabilities and hosts that consume them. (MCP SDK)

MCP Creates a Natural Control Point

At enterprise scale, reusable connectivity has another advantage: it creates a place where common controls can be applied.

Instead of asking each agent team to implement authentication, authorization, logging, rate limits, network policy, credential management, and security review independently, an organization can move more of those responsibilities toward shared infrastructure.

A simplified model is:

AI Applications
       │
       ▼
Identity and Agent Runtime
       │
       ▼
Policy / Authorization
       │
       ▼
MCP Access Layer
       │
       ▼
Enterprise Systems

The same standardization that reduces duplication, however, also concentrates risk. If many applications depend on one MCP server or access layer, a weakness there can affect all of them. Standardized permissions can standardize a mistake just as efficiently as they standardize a good integration.

That is why the most useful enterprise question is not simply:

Which systems can we connect to MCP?

It is:

Which business capabilities should be available to which agents, and under what conditions?

A CRM, for example, does not have to appear to an agent as one unrestricted administrative interface. An MCP server can expose narrower operations such as search_customer, read_order_history, add_internal_note, or request_account_update, while leaving unrelated administrative capabilities inaccessible.

Good MCP architecture therefore begins with the workflow rather than the full power of the underlying system.

The Enterprise MCP Security Problem

Traditional API security remains necessary in an MCP deployment, but it is not sufficient. This is where MCP intersects directly with broader cybersecurity architecture.

A conventional application usually reaches an API through logic written in advance. Developers define which endpoint is called, under what conditions, which parameters are accepted, and what happens with the result.

An agent introduces a different trust model. The model may select a tool after interpreting a user request, retrieving data, reading an email, examining a document, or processing output returned by another tool. The decision can therefore be influenced by external context.

User
  │
  ▼
Agent / Model
  ▲
  │
External context
Emails, files, web pages,
records, tool results
  │
  ▼
Tool decision
  │
  ▼
MCP
  │
  ▼
Business system

This creates risks that combine familiar security failures with model-driven behavior.

Excessive Permissions

The simplest mistake is giving an agent more functionality than its task requires.

A support agent may need to find a customer, review an order, check delivery status, and create a case. The service account behind the integration may also be capable of modifying billing data, exporting customer records, disabling accounts, and deleting information.

Using that broad account may be convenient. It also enlarges the consequences of any model error, malicious instruction, or compromised server.

The safer design is to expose only the business capabilities required by the workflow and separate read from write access where practical. Current OWASP guidance for AI agents and MCP environments recommends this form of tool-level least privilege and explicit authorization for sensitive operations. (OWASP AI Agent Security Cheat Sheet)

Prompt Injection Can Become Tool Abuse

Prompt injection becomes more consequential once a model can act.

An attacker does not need direct access to the agent interface if malicious instructions can be placed inside content that the agent will later process. Emails, documents, web pages, support tickets, database fields, repository files, and tool responses can all become sources of indirect prompt injection.

For a chatbot, a successful injection may result in a bad answer. For an agent with enterprise tools, it can influence which data is queried, which tool is selected, or which action is attempted.

OWASP advises treating external data such as user messages, retrieved documents, API responses, and emails as untrusted input. Its MCP guidance also recommends validating and sanitizing tool outputs before returning them to model context. The practical implication is that prompt-injection defenses should not be the only boundary. Even if the model requests an inappropriate action, independent authorization and policy controls should still be able to reject it. (OWASP AI Agent Security Cheat Sheet) (OWASP MCP Security Cheat Sheet)

MCP Servers and Tool Definitions Become Part of the Supply Chain

Connecting to an MCP server means trusting more than the protocol. The organization may also be trusting the server's code, dependencies, tool definitions, publisher, update process, hosting environment, and downstream services.

Tool descriptions deserve special attention because they are visible to the model and can influence tool selection. A compromised or malicious server can therefore affect both conventional execution and the model's decision-making context.

OWASP's MCP guidance identifies risks such as tool poisoning, tool shadowing, compromised third-party servers, and post-approval changes to previously trusted tools. (OWASP MCP Security Cheat Sheet)

For production use, servers need provenance, ownership, controlled versions, review, and a way to detect material changes.

Credentials and the Confused Deputy Problem

An MCP server often requires authorization to the system behind it. If it operates with a broad shared credential, agents may indirectly gain authority that exceeds the permissions of the person who initiated the request.

A database MCP server, for example, may connect with an account that can read every customer record. If authorization is checked only when a user reaches the MCP server, a salesperson might be able to retrieve information they could not access through the normal business application.

The same problem becomes more serious with write access.

Where possible, user identity and authorization context should remain relevant as the request reaches the protected resource. Shared service credentials should be narrowly scoped, and OAuth scopes or equivalent permissions should match the specific capabilities the workflow needs. OWASP identifies both over-scoped tokens and confused deputy scenarios as important MCP risks. (OWASP MCP Security Cheat Sheet)

Cross-System Composition Creates New Capabilities

Some of the most important risks do not exist inside any single tool.

An agent may legitimately be allowed to read CRM records, search internal documents, and send email. Together, those permissions can create a path for information to move from a protected system to an external recipient, even though no administrator explicitly granted a permission called "export confidential information."

The capability emerges from composition.

The same pattern appears in financial workflows, developer environments, and infrastructure automation. Individually reasonable permissions can combine into a much more powerful workflow.

For this reason, mature agent security must evaluate not only whether each individual tool call is allowed, but also what becomes possible when tools are used together.

Autonomous Actions Increase Blast Radius

The final issue is not a specific vulnerability. It is the potential impact of one bad decision.

An agent that searches internal documentation has a limited operational blast radius. An agent that can alter production infrastructure, approve refunds, change customer accounts, send external messages, or transfer funds does not.

The relevant question is therefore not only whether the model is reliable enough to use a tool. It is what happens when the model is wrong, manipulated, or given an ambiguous instruction.

This is why security controls should strengthen as actions become more consequential, less reversible, more financially significant, or more externally visible.

Authentication Is Necessary, but Execution Policy Is Different

Authentication establishes identity. Authorization determines what that identity may access.

Agentic systems need an additional decision:

Should this specific action be executed in this context?

Suppose an employee is authenticated through the company identity provider and is permitted to access customer records. An agent operating on that employee's behalf may also be authorized to use a tool that can update those records.

Both checks can succeed while a particular action remains inappropriate. The user may have asked only for an investigation. The model may have inferred that an update was useful, or external content may have influenced the decision.

A practical enterprise model therefore separates three questions:

Identity
Who is making the request?

        ↓

Authorization
What resources and tools may they access?

        ↓

Execution Policy
Should this action be allowed now?

Execution policy can consider the initiating user, the agent, the tool, the data involved, transaction value, reversibility, environment, rate limits, and whether human approval is required.

A refund workflow illustrates the difference. The organization may allow the agent to prepare any eligible refund request, execute refunds below $100, require approval between $100 and $1,000, and prohibit autonomous execution above that threshold.

The tool can remain the same. The policy around its execution changes.

The 2026-07-28 MCP specification strengthened authorization behavior, while the stable Enterprise-Managed Authorization extension allows organizations to centrally provision MCP server access through an existing identity provider. Those are important foundations, but they do not replace business-level execution policy. (2026-07-28 MCP specification) (Enterprise-Managed Authorization)

A Secure Enterprise MCP Architecture

A production deployment should not place a model directly in front of powerful systems and rely on prompt instructions to keep it within bounds. The same security-by-design principle applies to custom software and API integration more broadly.

A more defensible pattern is:

Not every organization needs a product literally called an "MCP gateway." The access-layer role may be implemented through an API gateway, service mesh, dedicated MCP infrastructure, or existing security controls.

What matters is the separation of responsibilities.

Preserve Identity Through the Workflow

The system should know which user or service initiated the request and, where relevant, which agent is acting on its behalf. That context should remain meaningful downstream.

A salesperson asking an agent for an account record should not silently become an anonymous request from a globally privileged AI service.

Centralized identity provides the basis for access decisions, but it does not mean every authenticated agent receives the same authority.

Keep Policy Outside the Model

The agent runtime can interpret requests, maintain context, and decide which capability may help complete a task. It should not have the final word on sensitive execution.

If the model proposes update_customer_account, a deterministic policy layer should evaluate that request before the business system receives it.

This also makes policy easier to audit and change. A company can lower an autonomous refund threshold from $100 to $50 in policy code without rewriting a system prompt and hoping the model applies the new rule consistently.

Expose Narrow Business Capabilities

MCP servers should expose the smallest useful set of operations rather than mirroring the entire underlying API.

Instead of:

execute_order_operation

a customer-service server may expose:

find_order
read_order_status
read_shipping_status
prepare_replacement
request_refund

This reduces both accidental misuse and the number of capabilities an attacker can attempt to manipulate.

Keep Credentials Away From Model Context

Models usually do not need to see the credentials used to execute their requests.

API keys, database passwords, OAuth refresh tokens, and cloud credentials should remain in trusted infrastructure. The model requests an approved capability; the surrounding system supplies the credential required to perform it.

Established secrets management, short-lived credentials where possible, and narrow scopes remain essential.

Treat Network Access as a Permission

An agent that can read sensitive data and make unrestricted outbound requests may have an exfiltration path even when every MCP tool is individually well designed.

A server that only needs access to an internal CRM does not necessarily need unrestricted internet access. A local MCP process should not automatically inherit broad filesystem, shell, network, and credential access from the machine on which it runs.

Design for Failure

The architecture should assume that one layer may fail.

A prompt-injection filter may miss an instruction. A model may misunderstand a request. A server may have a vulnerability. A credential may be misconfigured.

Defense in depth means that a bad model decision still encounters other boundaries: policy enforcement, server-side validation, scoped credentials, approval requirements, network restrictions, and monitoring.

MCP is the interface. The surrounding architecture determines how much authority actually passes through it.

The Principle of Least Agency

The principle of least privilege says that a user, service, or application should receive only the permissions needed to perform its task.

AI agents require a related question.

An agent may have legitimate access to a tool and still have too much freedom over when and how that tool is used. This leads to a useful design principle: least agency. OWASP's Top 10 for Agentic Applications 2026 likewise uses least agency alongside least privilege when discussing controls for tool misuse. (OWASP Top 10 for Agentic Applications 2026)

An agent should receive not only the minimum access required to perform a task, but also the minimum level of autonomy required to complete it.

Least privilege asks:

What is the agent allowed to access?

Least agency asks:

What is the agent allowed to decide and execute without further approval?

A customer-service agent may need access to order history, delivery data, account information, and refund tools. Least privilege limits it to those systems. Least agency determines whether it can execute every refund it is technically able to request.

A practical policy might be:

Read customer and order data
        → autonomous

Determine refund eligibility
        → autonomous

Prepare refund
        → autonomous

Execute refund under $100
        → autonomous

Execute $100–$1,000 refund
        → supervisor approval

Execute refund above $1,000
        → agent execution prohibited

This allows autonomy to increase gradually instead of forcing a choice between full manual supervision and unrestricted automation.

A new agent can begin by observing, recommending, and preparing actions. Low-risk and reversible operations can then become automated. Higher-impact capabilities can remain approval-gated even if the rest of the workflow becomes highly autonomous.

Human Approval Should Follow Risk

Human approval is useful when it is placed where it materially reduces risk.

Approving every tool call destroys much of the value of automation. Approving nothing can give the agent more authority than the consequences justify.

A simple model is:

Approval should also be bound to the exact action. A dialog that says only "Allow the agent to continue?" provides little protection.

A meaningful request should identify the operation, target, amount or other consequential parameters, reason, requesting agent, and expiration. If a significant parameter changes, a new approval should be required. OWASP recommends binding high-impact approvals to the actor, tool, target resource, parameters, timestamp, and expiration. (OWASP AI Agent Security Cheat Sheet)

The goal is not to keep people in every step. It is to keep them at the points where a mistake matters most.

MCP Governance and Observability

As MCP adoption grows, the problem becomes organizational as well as technical.

A small team can manage a few experimental servers informally. That does not scale when multiple departments connect agents to customer data, financial systems, cloud infrastructure, developer tools, and third-party services.

Every Production Server Needs Ownership

A production MCP server should have an identified owner responsible for its purpose, exposed capabilities, credential model, permissions, changes, vulnerabilities, and eventual decommissioning.

Organizations also benefit from an approved internal catalog that records basic information such as owner, data classification, available tools, required permissions, version, review status, and permitted environments.

This separates experimentation from production and reduces the chance that teams create multiple uncontrolled variants of the same integration.

Tool Changes Are Security-Relevant Changes

A server that originally exposed three read-only tools may later add a write operation. A tool description may change. An OAuth scope may expand. A new dependency or external service may appear.

Those changes can alter the effective authority available to every connected agent.

Material changes to tool definitions, permissions, authentication behavior, dependencies, and network access should therefore be reviewable and detectable. High-risk environments may also need version pinning or equivalent controls to prevent a remote server from changing behavior silently.

Governance should include decommissioning as well. The organization should be able to identify which agents depend on a server, revoke its credentials, remove it from approved discovery, and confirm that it can no longer be used.

Third-Party MCP Servers Are Supply-Chain Dependencies

A remote server operated by a third party should be evaluated in proportion to the sensitivity of the workflow.

Relevant questions include which data is sent to the provider, how authentication works, how long data is retained, where it is processed, how changes are communicated, which permissions are requested, and whether the server introduces additional downstream services.

A public-information connector and a server with access to confidential customer data should not receive the same level of review.

Observability Must Follow the Full Action Path

Governance tells an organization what should exist. Observability shows what actually happened.

Traditional API logs may confirm that an endpoint returned 200 OK, but that does not explain why an agent called it, which user initiated the workflow, what policy decision occurred, or which action followed.

For consequential operations, a useful trace should connect:

User request
      ↓
Agent / session
      ↓
Tool selection
      ↓
Policy decision
      ↓
MCP invocation
      ↓
Approval, if required
      ↓
External action
      ↓
Result

OpenTelemetry's developing Generative AI semantic conventions provide a model for representing agent invocations, model calls, and tool executions in the same trace. The relevant invoke_agent and execute_tool operation names are still marked as Development, so they are useful for observability design but should not be presented as a fully stabilized standard. (OpenTelemetry GenAI semantic conventions) (OpenTelemetry GenAI observability)

More logging is not automatically better. Prompts, tool arguments, results, documents, and model outputs may contain customer data, source code, credentials, or regulated information. Observability must therefore balance traceability with data minimization, retention, access controls, redaction, and encryption.

Monitoring should also look beyond isolated tool calls. Repeated authorization failures, unusual sequences of tools, sudden increases in data retrieval, or unexpected outbound actions can reveal behavior that no single call would make obvious.

The objective is not to record hidden model reasoning. It is to make observable decisions and effects accountable.

A Practical Example: Customer Operations With MCP

Consider a company automating part of its customer support process.

A customer reports that an order never arrived. The company wants an agent to investigate, determine the appropriate resolution, and complete low-risk actions automatically.

The agent needs access to several systems:

CRM
Order Management
Logistics
Support Platform
Refund System

The architecture might look like this:

Support User
     │
     ▼
Customer Operations Agent
     │
     ▼
Policy / Authorization
     │
     ▼
MCP Access Layer
     │
 ┌───┼──────┬────────┬────────┐
 ▼   ▼      ▼        ▼        ▼
CRM Orders Logistics Support Refunds

The agent first calls read-only tools such as find_customer, get_order, and get_tracking_status. The policy layer verifies that the employee is allowed to access the account and that the agent's scope includes the relevant records.

The logistics system reports that the package was lost. The agent checks the company's refund policy, confirms that no previous refund exists, and proposes:

Action: Refund
Order: ORD-91832
Amount: $72
Reason: Carrier-confirmed loss

The model's conclusion is not itself authorization.

A policy layer verifies the amount, eligibility, target order, prior transaction state, and other deterministic conditions. Because the amount is below the autonomous threshold, the system permits issue_refund.

The MCP server does not expose general payment administration. The refund tool validates the order and permitted amount before calling the underlying payments system. The model never sees payment credentials and cannot choose an arbitrary destination.

After execution, the agent can add a support note and prepare a customer response.

Now change one fact: the refund is $840.

The investigation remains the same. The policy layer, however, routes the proposed refund for supervisor approval. The approval identifies the exact order, amount, reason, and target. If approved, it applies to that transaction rather than becoming general permission for the agent.

This is least agency in practice. The AI performs most of the workflow, while human involvement appears only at the point where the financial consequence justifies it.

The same architecture also limits prompt-injection damage. If a customer email contains instructions to export unrelated customer records, the model may still be influenced, but the agent has no bulk-export tool, customer access is scoped, outbound actions are restricted, and cross-system execution remains subject to policy.

Security therefore does not depend on detecting every malicious instruction perfectly. It depends on making sure a bad model decision still meets meaningful boundaries.

The underlying MCP integrations can also be reused. A sales agent may use the CRM server without seeing refund capabilities. An operations agent may use logistics data without access to customer communication. A finance agent may use payment tools under a different policy.

Connectivity is reusable.

Authority is not automatically reusable with it.

Common MCP Implementation Mistakes

Production problems often come from shortcuts that were harmless in a demo and remained in place as the agent gained access to more important systems.

Exposing the Entire Backend

Wrapping a large administrative API and exposing most of it through MCP is easy. It also transfers the power of that system directly into the agent environment.

Start from the workflow and expose only the capabilities the agent needs.

Using Broad Shared Credentials

One highly privileged service account for every user and agent weakens downstream authorization and increases the impact of compromise.

Preserve user context where practical and scope service credentials narrowly.

Treating OAuth as the Whole Security Model

A valid identity and token establish access. They do not establish that every tool call is appropriate in context.

Sensitive actions still need execution policy.

Connecting Everything to One General-Purpose Agent

An agent with CRM, email, shell, cloud, database, financial, and repository tools has a large capability surface even if each integration is legitimate.

Narrower agents or capability profiles are often easier to reason about and secure.

Treating Read and Write Access the Same

Search and delete are not equivalent. Draft and send are not equivalent. Query and modify are not equivalent.

Separate read and write capabilities and apply different controls.

Trusting a Server Forever Because It Was Approved Once

Dependencies, tool definitions, permissions, and remote implementations change. Server approval must be a lifecycle process.

Moving Directly From Demo to Production Autonomy

A successful demonstration proves that an agent can complete a workflow under favorable conditions. It does not prove that the workflow is ready for unsupervised production use.

Production adds ambiguous requests, stale data, retries, partial failures, malicious content, permission differences, model changes, and interactions between systems.

Expand autonomy gradually and separately from connectivity.

MCP vs APIs vs Function Calling: Do You Actually Need MCP?

MCP should not become the default answer to every AI integration problem.

Direct APIs, tool or function calling, and MCP solve related but different problems, and many production systems will use all three.

Direct APIs May Be Simpler

If one AI application performs a narrow, stable workflow against two internal services, adding MCP may provide little immediate value.

AI Application
      │
      ├── Internal Supplier API
      └── Accounting API

The developers already know which systems are involved, which operations are available, and how authentication works. There may be no meaningful reuse or interoperability problem to solve.

Every abstraction creates operational cost. MCP adds server lifecycle, authorization, discovery, monitoring, and governance. If the environment is simple, the additional layer may be unnecessary.

Tool Calling Solves a Different Layer

Function or tool calling allows a model to request a structured action from the application, such as lookup_customer or create_ticket.

That answers a model-runtime question:

How can this model request that my application use a tool?

MCP answers a broader integration question:

How can AI applications consume externally provided tools and resources through a common protocol?

They are complementary.

A model may select a tool through its tool-calling mechanism. The application may have obtained that tool from an MCP server. The MCP server may then call an ordinary REST, GraphQL, gRPC, database, or proprietary interface.

Model
   │  tool selection
   ▼
AI Application
   │  MCP
   ▼
MCP Server
   │  existing API
   ▼
Enterprise System

MCP Becomes More Valuable as the Integration Graph Grows

The case for MCP strengthens when several applications need overlapping access to the same systems.

If a company operates support, sales, finance, engineering, and knowledge agents, multiple teams may otherwise implement the same CRM, database, document, Jira, GitHub, or reporting integrations independently.

A reusable MCP layer can reduce that duplication and provide a common boundary for governance.

A direct integration may still be preferable when:

• there is only one application;
• few external systems are involved;
• the workflow is fixed;
• the integration is highly application-specific;
• latency or operational simplicity dominates;
• reuse is unlikely.

MCP becomes more compelling when:

• multiple AI applications need the same systems;
• capabilities should be reusable across models or agent platforms;
• the number of tools is growing;
• the enterprise wants a governed AI integration layer;
• internal capabilities should be maintained as reusable platform services;
• the AI application layer is likely to change over time.

A useful comparison is:

The strongest reason to adopt MCP is not that it is new. It is that the integration environment has become complex enough for standardization to solve a real problem.

If that complexity is absent, simplicity may still be the better architecture.

Should Enterprises Adopt MCP in 2026?

By September 2026, MCP has moved well beyond the idea of a desktop assistant connecting to a few local tools. As of September 25, 2026, 2026-07-28 remains the latest final MCP specification revision; the project's public planning matrix lists the next 2026-12-15 revision as not ready. (MCP specification planning matrix)

The 2026-07-28 specification brought the protocol closer to conventional production infrastructure through a stateless core, authorization hardening, a formal extensions framework, header-based routing for gateways, and a deprecation policy. Enterprise-Managed Authorization also allows organizations to integrate MCP access with existing identity infrastructure. (2026-07-28 MCP specification) (Enterprise-Managed Authorization)

That makes MCP a credible production option.

It does not make every MCP deployment production-ready.

The practical decision is not whether an enterprise trusts the protocol in the abstract. It is whether a specific combination of agents, servers, permissions, data, and business actions can be operated safely.

MCP is particularly attractive where reusable connectivity has clear value and authority can be constrained: internal knowledge systems, analytics, read-heavy workflows, developer tools with appropriate sandboxing, and shared enterprise capabilities used by several AI applications.

Higher-risk workflows such as financial operations, customer-account changes, production infrastructure, identity administration, or regulated data can also use MCP, but they require correspondingly stronger controls around identity, execution policy, credentials, network access, approval, provenance, and observability.

A sensible adoption process begins with the workflow, not the protocol.

Define what the agent needs to do. Expose only those capabilities. Connect them through MCP where standardization provides a real benefit. Expand autonomy separately from connectivity.

An organization can standardize access to enterprise systems while initially keeping most actions in recommendation or preparation mode. Low-risk operations can become automated as evidence accumulates. High-impact actions may remain approval-gated indefinitely.

Production MCP Checklist

Before an MCP-based agent interacts with production systems, an organization should be able to answer these questions.

Architecture and Scope

• Is there a clear reason to use MCP instead of a simpler direct integration?
• Are capabilities defined around the workflow rather than the full underlying API?
• Are read and write operations separated where practical?
• Does the agent have only the tools required for its job?
• Have cross-system capability combinations been reviewed?

Identity and Authorization

• Can important actions be linked to the relevant user, service, and agent?
• Are credentials narrow in scope and isolated from model context?
• Are authorization checks enforced on relevant requests rather than only at login?
• Does downstream access still respect the user's authorization context where required?
• Are sensitive actions governed by execution policy beyond simple tool access?

Server and Supply-Chain Security

• Does every production MCP server have an owner?
• Are third-party servers reviewed as supply-chain dependencies?
• Are important changes to tools, permissions, descriptions, and dependencies detectable?
• Can an obsolete or compromised server be revoked quickly?

Autonomy

• Has each consequential tool been assigned a risk level?
• Are reversible and irreversible actions treated differently?
• Are autonomous actions bounded by deterministic rules?
• Do high-impact actions require independent authorization?
• Is human approval bound to the exact action and parameters?

Data, Network, and Operations

• Is sensitive data exposed only when necessary?
• Are tool inputs and outputs validated?
• Is outbound network access restricted where appropriate?
• Are plausible exfiltration paths understood?
• Can the organization trace a user request through policy, MCP, and external action?
• Are sensitive prompts and tool outputs protected from excessive logging?
• Can agents, tools, credentials, and servers be disabled during an incident?

Testing

• Has the system been tested against direct and indirect prompt injection?
• Have malicious documents, emails, websites, and tool outputs been considered?
• Have retries, duplicate actions, partial failures, and unavailable dependencies been tested?
• Have authorization boundaries been tested across different user roles?
• Has the system been tested for plausible but incorrect model decisions?

A read-only research agent and an agent capable of moving money should not require identical controls. What matters is that the architecture matches the consequences of failure.

For organizations with one narrow workflow, MCP may remain unnecessary. For those building multiple agents, sharing capabilities across applications, or creating a governed internal AI platform, the case is considerably stronger.

MCP can standardize connectivity. Production readiness comes from deciding what should be connected, what authority should pass through those connections, and where that authority must stop.

Related Orcas Group Reading

• The Gap Between AI Demos and Production AI Systems
• AI Agent Development Cost in 2026: Full Pricing Guide
• Vibe Coding for Startups in 2026: Can You Build a Production-Ready MVP With AI?

Conclusion: MCP Is Infrastructure, Not a Security Boundary

MCP is solving a real enterprise AI problem.

As agents need access to databases, SaaS platforms, internal APIs, documents, developer systems, and operational workflows, building every connection independently becomes difficult to maintain. A common protocol can make those capabilities reusable and reduce some of the coupling between AI applications and the systems they depend on.

The mistake is to confuse easier connectivity with safer connectivity.

An MCP server can expose a tool or resource through a standard interface. It does not decide whether a particular agent should have that capability, whether the user behind the request is authorized to exercise it, whether the action is appropriate in context, or whether its consequences justify autonomous execution.

Those decisions remain part of the surrounding architecture.

For enterprises, the important design question is therefore not how many systems an agent can reach. It is how precisely the organization can control what the agent is allowed to do once those connections exist.

That requires familiar disciplines such as identity management, least privilege, credential isolation, network controls, logging, and supply-chain review. Agentic systems add another: the amount of independent authority granted to the model.

The principle of least agency captures that difference. Give the agent enough autonomy to make the workflow useful, but no more than the task and its consequences justify.

MCP makes it easier to connect AI to real business capabilities. The quality of an enterprise implementation will depend on how carefully that access is shaped.

Building AI Agents That Need Access to Real Business Systems?

At Orcas Group, we design and build production AI systems that integrate with existing enterprise infrastructure, including internal APIs, databases, SaaS platforms, and operational workflows.

The work goes beyond connecting a model to a tool. Production systems also require architecture around identity, permissions, policy enforcement, observability, and security. Our AI engineering work is supported by dedicated cybersecurity and IT capabilities, which is especially important when agents move from retrieving information to taking action inside business systems.

If your AI project is moving from experimentation toward production, Orcas Group can help design the integration and security architecture required to make that transition safely.

Discuss Your AI Architecture →

About the Author

Ivan Janković is the Founder and CEO of Orcas Group. His background combines international management, law, and information technology, with more than a decade of experience working at the intersection of regulated industries and modern software. He studied in Geneva, graduated in Management from Webster University in Vienna, and later completed Master's studies in Law and Information Technology at the Faculty of Law, University of Niš.

Before founding Orcas Group, Ivan worked as a consultant for a private Swiss-based bank on blockchain technology initiatives, with work spanning architecture, compliance, and product strategy. Under his leadership, Orcas Group has grown to a team of 20+ specialists and delivered 100+ projects across sectors including fintech, SaaS, healthtech, LegalTech, e-commerce, manufacturing, and government.

His current work sits at the intersection of AI strategy, enterprise software, cybersecurity, compliance, and technology delivery. That combination is particularly relevant to production AI systems, where model capability, software architecture, security, and governance increasingly need to be designed together.

More about Ivan Janković and Orcas Group →