Direct answer: MCP is a standard for connecting agents to external tools and data, not a security boundary. Enterprises can adopt it, but should not hand an agent write access to ERP/CRM on day one: start with read-only tools, a dedicated gateway, per-tool authorisation, OAuth audience validation, human approval and audit. Do not connect payments, deletion or permission changes yet.
This guide is for enterprise IT/architecture, AI leads, security, procurement and business-system owners deciding whether to adopt MCP in 2026, which systems to connect first, and how to accept tool permissions, credentials and audit. Information is current to 31 October 2026. It is public protocol/security documentation and project method, not a security certification or legal advice; architecture, OAuth, network, logging and contractual liability are confirmed with the security team.
Tool descriptions are untrusted; tool calls need consent. Do not pass tokens through; do not grant wildcard scopes. A local MCP server runs code on your machine. Start read-only, start with a gateway, start with audit—then discuss writes.
What MCP is—and is not
MCP is an open protocol for LLM apps to connect to external data/tools, using JSON-RPC 2.0 to define host/client/server and resources/prompts/tools. It standardises how to connect, not whether to trust, authorise or audit.
MCP standardises the connection between AI applications and external systems: the host is the LLM application initiating connections, the client is the connector inside the host, and the server provides context and capabilities. A server can expose resources (context/data), prompts (templates/workflows) and tools (executable functions); clients can also offer sampling, roots and elicitation. It solves interface fragmentation, not permissions, audit or data governance. The spec explicitly warns that tools represent arbitrary code execution, tool descriptions/annotations should be treated as untrusted unless from a trusted server, and hosts must obtain explicit user consent before invoking a tool.
| Concept | What it is | Enterprise meaning | What it is not |
|---|---|---|---|
| Host | LLM app initiating connections | Employee agent/IDE/chat entry | Not a security boundary |
| Client | Connector inside the host | Handshake, authorisation, calls | Not automatically trusted |
| Server | Service exposing resources/prompts/tools | ERP/CRM/file/search adapter | Not the business system itself |
| Tools | Executable functions | Look up order/create ticket/send email/update status | Not a "read-only API" |
| Resources/prompts | Context/templates | Knowledge base, reports, process templates | Not guaranteed trustworthy |
Roles/capabilities follow the MCP Specification and Architecture; security principles are in the spec's "Security and Trust & Safety".
Which systems/tools should be connected first?
Start with read-only, reversible, low-risk lookups, knowledge bases and ticket drafts. Do not start with payments, deletions, permission changes, bulk email or production control. Tier tools by read/write/transaction/delete/admin.
The common mistake is treating MCP as "give the agent an ERP account". Instead, tier by tool: read-only lookups (order status, inventory, product data, knowledge base) are lower risk; writes (create ticket, update CRM note, change address) need approval/reversibility; transactions (submit PO, change price, send formal quote) need human/dual approval; deletion, payments, permission management and production control should not be exposed via MCP initially. Every tool needs an owner, purpose, inputs/outputs, failure handling, audit fields and a kill switch.
| Tool tier | Examples | Control | Evidence |
|---|---|---|---|
| Read-only | Order status, inventory, product data, knowledge base | Minimal scope, rate limit, logs | Tool list/call logs |
| Draft/low-risk write | Ticket draft, CRM note, meeting minutes | Human approval, reversible | Approval/rollback test |
| Transaction | Submit PO, change price, formal quote | Human/dual approval, amount thresholds | Approval chain/reconciliation |
| Delete/payment/permission | Delete customer, pay, change role | Do not connect; separate workflow | Excluded list |
| Production control | PLC/line/equipment parameters | Do not connect; OT security | Boundary statement |
The tiers are editorial; tool risk, approval and OT boundaries depend on security policy, system owners and business impact.
How should permissions and credentials be designed?
Use OAuth to issue a token addressed only to the MCP server; forbid token passthrough. Require per-client consent, minimal scopes and user-bound sessions. Do not put long-lived passwords in agent config.
The MCP authorization spec requires an MCP server to validate that a token was issued to it (audience), and forbids passing a client's upstream token through to downstream APIs—otherwise rate limits, validation and audit are bypassed and the caller cannot be identified. Enterprises should: use a separate OAuth client/resource identifier per MCP server; bind the token audience to that server; minimise scopes per tool (no files:*, db:* or all); record per-client consent; exact-match redirect URIs; use unpredictable session IDs bound to the user, never as authentication; and support revocation on leave/role change. Shared accounts, long-lived API keys and ERP admin passwords in config are high risk.
| Control | Requirement | Evidence | Red flag |
|---|---|---|---|
| Token audience | Token issued only to this MCP server | OAuth config/test | Upstream token passthrough |
| Scope | Minimal per tool; no wildcards | Scope list | all/full-access |
| Client consent | Per-client consent/record | Consent log | One consent for everything |
| Redirect URI | Exact match; no wildcards | Registry/test | Pattern matching |
| Session | Secure random, user-bound, revocable | Session log | Session used as auth |
| Credential storage | Vault/short-lived tokens; not in config | Key-management record | Shared account/long-lived key |
OAuth/audience/passthrough requirements follow MCP Authorization and RFC 9700; identity-provider configuration follows enterprise IAM.
Which attack surfaces should be tested?
Test confused deputy, token passthrough, SSRF, session hijacking, local-server code execution, tool-description injection and scope inflation. Each needs a test method and log evidence—not just "it connects".
The MCP security best practices list attacks enterprises must consider: confused deputy (static client ID + dynamic registration + consent cookie skipping consent), token passthrough (bypassing downstream controls/audit), SSRF (malicious server points OAuth metadata URLs at internal networks/cloud metadata), session hijacking (guessed/stolen session IDs), local MCP server compromise (malicious config/supply chain = code execution on the machine), OAuth URL injection (javascript: etc.) and scope inflation (one over-privileged token). Acceptance should test malicious redirects, internal URLs, forged sessions, local configs containing sudo/rm -rf, instructions hidden in tool descriptions and requests for all scopes.
| Attack surface | How to test | Pass standard | Evidence |
|---|---|---|---|
| Confused deputy | Malicious redirect/dynamic registration/reused consent | Per-client consent; exact redirect | Test record |
| Token passthrough | Call downstream with upstream token/change audience | Reject non-server token | 401/logs |
| SSRF | Metadata URL/private IP/redirect | Block private/link-local; HTTPS | Request log |
| Session hijack | Guess/reuse session ID | Unpredictable, user-bound, revocable | Session test |
| Local server | One-click config with dangerous command | Explicit consent; sandbox/least privilege | Config review |
| Tool description injection | Hide instructions in descriptions/resources | Treat as untrusted; human approval | Test cases |
| Scope inflation | Request all/*/full scopes | Minimal scope; incremental elevation | Scope record |
Attacks/mitigations follow MCP Security Best Practices; test methods/pass standards are editorial and depend on the security team's plan.
Self-hosted gateway, SaaS MCP or local server?
Enterprises with ERP/CRM/multi-system governance should prefer a self-hosted or managed MCP gateway; SaaS MCP fits a single tool but check data/scopes; local servers are for controlled development/personal productivity, not open installation by everyone.
The three approaches carry different risk. A SaaS vendor's MCP server is quick to adopt, but data passes through the vendor, scopes may be broad and audit sits outside; a self-hosted MCP gateway centralises identity, tool catalogue, approval, logs, rate limits and kill switches, at build/run cost; a local MCP server suits personal/development use with access to local files/commands—and the highest risk. A common enterprise pattern is "gateway + a few read-only SaaS tools + controlled local development servers", keeping writes behind the gateway with per-tool approval.
| Approach | Fits | Benefit | Risk/acceptance |
|---|---|---|---|
| SaaS MCP | Single tool, fast validation | Quick, vendor-maintained | Data path/scope/audit/exit |
| Self-hosted gateway | Multi-system, central governance | Central identity/catalogue/approval/logs | Build/run/high availability |
| Local server | Development/personal productivity | Convenient local access | Code execution/supply chain/sandbox |
| Do not connect | Payments/deletion/production control | Lowest risk | Keep a manual workflow |
The comparison is editorial; selection depends on system boundaries, data classification, IAM, network and security review.
Launch acceptance checklist
Accept eight items: tool inventory, risk tiers, OAuth/audience, scopes, client consent, attack-surface tests, logging/kill switch, contract/exit. Each needs an owner and evidence—not just "the agent can call it".
The checklist can be shared by IT/architecture, AI leads, security, procurement, business-system owners and vendors. The pass standard is not "the API works" but that tool scope is clear, permissions are minimal, tokens are not passed through, attacks are tested, logs are traceable, the service can be killed and the contract can exit.
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| Tool inventory | Owner/purpose/IO/risk per tool | Tool catalogue | Complete/retire |
| Risk tiers | Read/write/transaction/delete/production approval | Tier table | Downgrade/stop |
| OAuth/audience | Token only for this server; no passthrough | Config/test | Reconfigure/change |
| Scopes | Minimal per tool; incremental elevation | Scope record | Narrow/re-consent |
| Client consent | Per-client consent; exact redirect | Consent/registry | Fix auth flow |
| Attack tests | Confused deputy/SSRF/session/local/injection/scope tested | Test report | Fix/pause |
| Logging/kill switch | Calls/approvals/errors traceable; revoke/kill | Logs/drill | Add logs/switch |
| Contract/exit | Data/logs/subprocessors/termination/deletion clear | Contract/DPA | Add clauses/change vendor |
The acceptance checklist is editorial; MCP, OAuth, logging, data and contract requirements depend on security policy, IAM, vendor docs and counsel.
Who should read this, who should not, and what decision does it support?
It fits enterprise IT/security/business teams preparing to connect agents to ERP/CRM/knowledge bases. It does not fit teams wanting to open write access at once, without IAM/logging/kill switches, or treating MCP as a security boundary.
Who should read: IT/architecture, AI leads, security, procurement and business-system owners; teams evaluating Dify/Coze/Bailian/self-built agents connecting to internal systems; anyone deciding "which tools first, SaaS or gateway, how to configure OAuth, whether local servers are allowed, how to accept". Who should not: projects giving an agent ERP admin rights/shared accounts; teams without IAM, logging, approval or kill switches wanting writes; teams assuming "standard protocol = secure". Decisions supported: MCP scope, tool tiers, OAuth/audience/scopes, client consent, attack-surface tests, gateway selection, logging/kill switch and contract exit.
Lingyi Information is a website and enterprise AI project services company, not a security auditor/certifier, IAM vendor or law firm. This article does not replace a security assessment, penetration test, OAuth configuration or legal advice. Scope is confirmed case by case; no launch speed, zero-incident, traffic or conversion is promised.
FAQ
How is MCP different from a normal API or plugin?
MCP uses a common protocol (JSON-RPC 2.0) to describe resources/prompts/tools so different hosts/clients can discover and call external capabilities consistently; a normal API is system-specific, and a plugin is a platform-specific extension. MCP standardises "how to connect", not permissions, audit or data governance—those remain enterprise responsibilities.
Can an agent connect directly to ERP and write data?
Not advisable at the start. Begin with read-only lookups/drafts; writes need human approval, reversibility, audit and amount/scope thresholds; payments, deletion, permission changes and production control should not be connected yet. ERP writes affect inventory/finance/delivery, and one mistake is expensive.
What should we watch in MCP OAuth?
The token must be issued to this MCP server (audience validation); do not pass an upstream token through to downstream APIs. Require per-client consent, exact redirect URIs, minimal scopes, unpredictable user-bound sessions. OAuth 2.0 Security BCP (RFC 9700) also applies.
Can employees install local MCP servers themselves?
Local servers execute code on the employee's machine and may access files/commands/internal networks—high risk. Require explicit consent before one-click configuration (show the full command), sandbox/least privilege, an allowlist and logs; do not let everyone install servers of unknown origin by default.
How do we prevent prompt injection in tool descriptions/knowledge bases?
Treat tool descriptions, resource content and knowledge-base documents as untrusted input; do not let descriptions become high-privilege instructions; require approval before calls, per-tool authorisation and minimal scopes; add second confirmation/dual approval for high-risk tools; log inputs/outputs and support kill switches.
Is a self-hosted MCP gateway worth it?
If you connect one SaaS tool, read-only, low volume, you can defer it; if you connect ERP/CRM/multiple systems and need central identity/approval/logging/kill switches, a gateway is usually more controllable. It has build/run cost—start with "gateway + read-only tools" and expand writes gradually.
Bottom line
Treat MCP as a standard connector, not a security boundary: start with read-only tools, use a gateway for identity/scopes/approval/logs; no token passthrough, no wildcard scopes, per-client consent; sandbox/consent local servers; test attack surfaces, keep a kill switch and an exit clause before discussing writes.
Method and limits
This article is public protocol/security documentation and project method, not a security certification or legal advice for any enterprise, system, MCP server or vendor. It uses no unpublished client architecture, logs or contracts. Tool tiers, approach comparison and the acceptance checklist are editorial; MCP, OAuth, network, logging, data and contract requirements depend on security policy, IAM, vendor docs and counsel.
Sources
Information is current to 31 October 2026; each official/primary page governs its own protocol version, security requirements and terms.
- Model Context Protocol Specification (2025-06-18): modelcontextprotocol.io. Host/client/server, resources/prompts/tools, JSON-RPC 2.0 and security principles.
- MCP Security Best Practices: modelcontextprotocol.io. Confused deputy, token passthrough, SSRF, session hijacking, local servers, OAuth URL validation and scope minimisation.
- MCP Authorization (2025-11-25): modelcontextprotocol.io. OAuth authorization, token audience, dynamic registration and consent flows.
- RFC 9700, Best Current Practice for OAuth 2.0 Security (January 2025): rfc-editor.org. OAuth 2.0 security best practices applicable to MCP authorization.
- Anthropic, Introducing the Model Context Protocol (November 2024): anthropic.com. MCP positioning, open protocol and ecosystem background.