{"id":"KM-AI-0232","slug":"what-changes-when-mcp-servers-moves-into-production","title":"MCP Servers in Production: Capability Governance, Trust and Recovery","excerpt":"Operate MCP servers safely by inventorying capabilities, separating client and server trust, treating content as untrusted, observing tool use and planning retirement.","kind":"Guide","category":"ai","tags":["MCP servers","Artificial Intelligence","AI automation","strategy","operations leaders"],"seoKeywords":["MCP servers","Model Context Protocol","MCP security","MCP server governance","AI tool integration"],"authorId":"krishnam-murarka","publishedAt":"2026-06-24","updatedAt":"2026-09-09","readingTime":"13 min","image":"/social-images/blog/edilec-photo-km-ai-0232-0d6562e09d36.jpg","featured":false,"trending":false,"sourceCredits":[{"title":"Model Context Protocol specification","url":"https://modelcontextprotocol.io/specification/2025-03-26/basic/index","author":"Model Context Protocol project"},{"title":"NIST Generative AI Profile","url":"https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf","author":"National Institute of Standards and Technology"},{"title":"NCSC Guidelines for secure AI system development","url":"https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development/guidelines","author":"UK National Cyber Security Centre"},{"title":"OWASP Top 10 for LLM Applications","url":"https://genai.owasp.org/llmrisk/llm01-prompt-injection/","author":"OWASP Foundation"},{"title":"MCP authorization specification","url":"https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization","author":"Model Context Protocol project"},{"title":"NIST AI Risk Management Framework","url":"https://www.nist.gov/itl/ai-risk-management-framework","author":"National Institute of Standards and Technology"},{"title":"OpenAI agents guide","url":"https://platform.openai.com/docs/guides/agents","author":"OpenAI"}],"researchSources":[{"title":"Model Context Protocol specification","url":"https://modelcontextprotocol.io/specification/2025-03-26/basic/index","author":"Model Context Protocol project","reason":"Defines clients, servers, tools, resources, prompts and negotiated authorization boundaries."},{"title":"NIST Generative AI Profile","url":"https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf","author":"National Institute of Standards and Technology","reason":"Adds risks and lifecycle considerations for generative systems connected to external context."},{"title":"NCSC Guidelines for secure AI system development","url":"https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development/guidelines","author":"UK National Cyber Security Centre","reason":"Covers secure design, development, deployment and operation of AI systems."},{"title":"OWASP Top 10 for LLM Applications","url":"https://genai.owasp.org/llmrisk/llm01-prompt-injection/","author":"OWASP Foundation","reason":"Identifies prompt injection, insecure output handling, excessive agency and supply-chain risks."}],"mediaAssets":[],"status":"published","body":[{"type":"paragraph","text":"MCP servers change production architecture because they make tools, resources, and prompts discoverable to AI clients through a common integration pattern. That convenience can also enlarge the capability surface quickly: a client may encounter a server with data access, an action tool, or instructions that influence how it behaves. Operations leaders should treat each production MCP server as a supplier-managed integration with an owner, deployment identity, declared capabilities, authorization model, update path, and retirement plan. The [MCP authorization specification](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization) describes authorization for HTTP transports; it should inform, not replace, an organization's broader access and risk decisions. [MCP Servers for AI Automation](/blog/km-ai-0212/mcp-servers-for-ai-automation-a-practical-guide/) is a useful practical companion."},{"type":"heading","id":"build-a-server-inventory","text":"Build a server inventory","depth":2},{"type":"paragraph","text":"Inventory before enabling discovery. For each server, record its publisher, code or package provenance, deployment location, transport, owner, business purpose, data categories, resources, tools, prompt templates, supported clients, authentication method, and environment. Distinguish a local development server from a production shared service; the threat and support models are not the same. Review the capability list with the business owner, not just the engineer who connected it. A server that seems harmless because it only reads a directory may expose a much broader collection through a poorly scoped resource or a confused client. Keep an allowlist of approved servers and versions, and make unapproved connections visibly fail rather than merely relying on user discretion."},{"type":"image","src":"/social-images/blog/edilec-photo-km-ai-0232-0d6562e09d36.jpg","alt":"An integration inventory separates read resources from action capabilities.","caption":"The MCP production guide treats discovered tools, resources and prompts as governed capabilities with separate trust and retirement rules.","width":1200,"height":750},{"type":"table","columns":["Inventory field","Question to answer","Operational use"],"rows":[["Publisher and version","Who maintains this artifact and what exact build is allowed?","Supports review, patching, and incident response."],["Capability set","What resources and tools can the server expose?","Enables least-privilege client policy."],["Data and effect","What can it read, reveal, or change?","Determines risk tier and approval requirements."],["Owner and exit","Who supports it and how is access removed?","Prevents abandoned integration surface."]]},{"type":"heading","id":"separate-client-trust-from-server-trust","text":"Separate client trust from server trust","depth":2},{"type":"paragraph","text":"A trusted client does not make every connected server trustworthy, and a well-built server should not assume every client deserves every capability. Authenticate both sides where the transport supports it, bind credentials to the intended server and audience, and limit each client to an approved capability set. The MCP authorization specification notes that authorization is optional and transport-specific; production policy must close any gaps with established identity, secret-management, and network controls. Avoid long-lived, shared credentials that let a conversational context silently inherit a broad operator identity. Use per-user or per-service delegation where the business effect requires it, and check current authorization at execution rather than relying on a past chat session."},{"type":"list","items":["Approve servers by publisher, deployment, and exact version rather than name alone.","Give each client a minimal allowlist of resources and tools for its declared workflow.","Use scoped, renewable credentials and avoid placing secrets in prompts or server metadata.","Bind user-facing actions to the user's current identity and policy, not a background superuser.","Review server updates and capability additions as material changes before enabling them."]},{"type":"heading","id":"treat-server-content-as-untrusted","text":"Treat server content as untrusted","depth":2},{"type":"paragraph","text":"MCP makes it easier to pass resources and tool results into a model's context; that does not make the content safe to follow as instructions. A server response may be stale, malformed, unexpectedly broad, or maliciously constructed. Parse structured outputs, validate tool arguments at the target service, and label retrieved content so it cannot silently override the client application's policy. The [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) explains why indirect prompt injection and excessive agency are relevant to connected-agent systems. Establish output limits, timeouts, rate limits, and error handling at both client and server boundaries. The safest default for a new server is read-only, narrow in scope, and observable."},{"type":"callout","tone":"warning","title":"Protocol support does not grant business permission","text":"MCP standardizes a way to connect. It does not decide whether a client should access a dataset, whether a user can approve an action, or whether an effect complies with policy."},{"type":"heading","id":"observe-capability-use","text":"Observe capability use","depth":2},{"type":"paragraph","text":"Instrument the path from client request to server response and final business effect. Capture server identity and version, client identity, user or service principal where applicable, capability invoked, policy decision, timing, error category, and safe record references. Avoid logging raw sensitive content by default. Monitor denied requests, unused tools, repeated failures, scope mismatches, credential errors, latency, and unusually broad data access. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is useful for establishing ownership and review routines around those signals. A trace should let an authorized operator answer what was attempted, why it was allowed or denied, and how to stop the path if it behaves unexpectedly."},{"type":"table","columns":["Signal","Risk it reveals","Response"],"rows":[["New capability appears","Server update widened the surface","Hold the update and review the inventory delta."],["High denial rate","Client requests do not match policy or user need","Fix workflow design; do not simply broaden permissions."],["Unused sensitive resource","Excess exposure without product value","Remove it from the client allowlist."],["Repeated timeout","Dependency is not operable for the workflow","Add fallback, service objectives, or retire the integration."]]},{"type":"heading","id":"release-and-retire-deliberately","text":"Release and retire deliberately","depth":2},{"type":"paragraph","text":"Review data flow as well as protocol behavior. A server may preserve a narrow tool schema while changing where records are processed, cached, or exported. Capture those deployment and subprocessor changes in the review so a capability remains consistent with the data and vendor commitments that justified its original approval."},{"type":"paragraph","text":"Make the review outcome visible to client owners: approved version, allowed capability set, next review date, and disable contact. That small operational record helps teams use MCP servers intentionally rather than relying on tribal knowledge about which connection is acceptable."},{"type":"paragraph","text":"An MCP inventory becomes useful when it is reviewed on a cadence that matches change. Reassess a shared or high-impact server after capability additions, authentication changes, publisher transfers, deployment moves, dependency alerts, or material incidents. For stable low-risk servers, a periodic review can confirm ownership, usage, patch status, and continued business justification. Compare the current advertised capabilities with the approved inventory; protocol-level discovery can reveal additions that an older approval never considered. Require a technical evidence package for material updates, including version notes, test results, security assessment where appropriate, and rollback plan. Invite the business owner to decide whether the new surface is still necessary. This prevents server governance from becoming a one-time procurement exercise while still giving teams a predictable route to evolve useful integrations."},{"type":"list","items":["Set review frequency by data sensitivity, side-effect potential, client count, and change velocity.","Trigger an out-of-cycle review for capability, identity, deployment, or publisher changes.","Compare live server discovery against the approved inventory and investigate any difference.","Require tested rollback and disable steps before enabling a material server update.","Confirm that unused servers and resources are actually removed from clients and credentials.","Document the continued business purpose so capability surface does not persist by inertia."]},{"type":"paragraph","text":"Introduce one server to one approved client workflow first, preferably with read-only capabilities and a clear conventional fallback. Test permission boundaries, malformed outputs, dependency failures, version changes, and client behavior when a server is unavailable. Assign a technical owner who can patch or disable the server and a business owner who can decide whether the capability remains justified. Retire unused tools and resources; dormant integration surface is difficult to review and easy to forget. The [OpenAI agents guide](https://platform.openai.com/docs/guides/agents) can help teams organize agent execution, while the production operating model should remain anchored in the organization's own identity, application, and support practices."},{"type":"heading","id":"frequently-asked-questions","text":"Frequently Asked Questions","depth":2},{"type":"paragraph","text":"Question: How should an MCP server capability be trusted? Answer: Inventory its tools, resources, and prompts; verify the source and transport; scope authentication; and review each capability before allowing it into a production workflow."},{"type":"paragraph","text":"Question: What prevents an MCP tool from causing unintended action? Answer: Use deterministic allowlists, narrow schemas and permissions, previews or approvals for consequential actions, and logs that connect the request to the resulting tool call."},{"type":"paragraph","text":"Are MCP servers safe by default? No. Their safety depends on publisher trust, deployment, identity, authorization, capability scope, and how clients process server-provided content. Should every client discover every approved server? Usually not; discovery should follow a defined workflow and allowlist. Can MCP replace application APIs? It can complement them for agent integrations, but target services still need stable, policy-enforcing interfaces. What should be logged? Enough identity, capability, policy, timing, and safe references to investigate behavior, while minimizing raw sensitive content. For action boundaries, see [Tool Calling for AI Automation](/blog/km-ai-0206/tool-calling-for-ai-automation-a-practical-guide/)."},{"type":"heading","id":"key-takeaways","text":"Key Takeaways","depth":2},{"type":"list","items":["Treat each MCP server as a controlled integration with an inventory, owner, and lifecycle.","Separate server trust from client trust and grant only approved, scoped capabilities.","Validate server content and enforce action policy in target services, not in model instructions.","Monitor capability use and retire surface area that has no justified operational value."]},{"type":"heading","id":"conclusion","text":"Conclusion","depth":2},{"type":"paragraph","text":"MCP servers can make agent integrations more composable, but composability is not a substitute for governance. Inventory the servers, bind identity and permission to real work, observe every capability path, and keep retirement as deliberate as deployment. Then the protocol can reduce integration friction without creating an unmanaged capability estate."},{"type":"heading","id":"mcp-production-readiness","text":"Review MCP production readiness","depth":2},{"type":"paragraph","text":"An MCP server deserves a production review that starts with capability, not transport. List every tool, resource and prompt it exposes; name the data each capability can read, the effects it can cause, the identity used, the rate limit, the owner and the evidence retained. The [MCP specification](https://modelcontextprotocol.io/specification/2025-03-26/basic/index) describes the protocol surface, but it does not remove the need for local authorization and business policy. [OWASP guidance](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) is a useful companion for prompt injection, insecure output handling and excessive agency."},{"type":"paragraph","text":"Test tool descriptions and returned content as untrusted input. Include lookalike tools, poisoned resources, oversized responses, stale permissions, partial failures and a user who is authorized to read but not write. Log the caller, server, capability, input classification, approval, result summary and downstream effect without storing unnecessary sensitive content. Give operators a kill switch and a way to revoke one capability without taking the whole client offline. Related context is available in [MCP servers](/blog/km-ai-0212/mcp-servers-for-ai-automation-a-practical-guide/), [AI guardrails](/blog/km-ai-0195/how-engineering-teams-should-think-about-ai-guardrails/), and [AI agents](/blog/km-ai-0001/ai-agents-explained-from-first-principles/)."},{"type":"paragraph","text":"Further Edilec context: [MCP servers practical guide](/blog/km-ai-0212/mcp-servers-for-ai-automation-a-practical-guide/), [AI guardrails guide](/blog/km-ai-0195/how-engineering-teams-should-think-about-ai-guardrails/), [AI agents first principles](/blog/km-ai-0001/ai-agents-explained-from-first-principles/). The operating decision applies those references specifically to mcp servers in production: capability governance, trust and recovery."},{"type":"paragraph","text":"Source trail: the [MCP specification](https://modelcontextprotocol.io/specification/2025-03-26/basic/index) defines the protocol capabilities; the [NIST Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) frames lifecycle risk; [NCSC secure AI guidance](https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development/guidelines) follows security into operation; and the [OWASP LLM Top 10](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) covers prompt and agency risks. Local policy still determines trust and authorization."},{"type":"image","src":"/attachments/article-media/editorial/edilec-batch101-what-changes-when-mcp-servers-moves-into-production.svg","alt":"MCP server production governance route","caption":"The route separates protocol capability from local trust, authorization, observation and lifecycle ownership."}],"faqs":[{"question":"How should an MCP server capability be trusted?","answer":"Inventory its tools, resources, and prompts; verify the source and transport; scope authentication; and review each capability before allowing it into a production workflow."},{"question":"What prevents an MCP tool from causing unintended action?","answer":"Use deterministic allowlists, narrow schemas and permissions, previews or approvals for consequential actions, and logs that connect the request to the resulting tool call."},{"question":"What should an MCP production inventory record?","answer":"Record the server owner, publisher and version, transport, client, exposed capabilities, data and side effects, identity, approval scope, evidence retained, and disable path."},{"question":"How should an MCP server be retired?","answer":"Stop new use, revoke credentials, remove client capability grants, preserve only necessary evidence, and confirm that dependent workflows have a safe alternative."}],"relatedIds":["KM-AI-0233","KM-AI-0239","KM-AI-0001","KM-AI-0107"],"relatedArticleIds":["KM-AI-0212","KM-AI-0206","KM-AI-0195","KM-AI-0233","KM-AI-0239","KM-AI-0001"]}