7. Model Context Protocol (MCP) Servers in Enterprise AI Architecture

Featured Content - Research and Perspectives

7. Model Context Protocol (MCP) Servers in Enterprise AI Architecture

Posted on 09.21.26
Digital analytics and growth data visualization on a smartphone screen.
by Ian Meinert •  Article 7 of 7

A Security and DevSecOps Assessment for Enterprise and Government-Adjacent Delivery Programs

 

Security researchers have found practical real-world problems in the MCP ecosystem: credential exposure, prompt injection, supply chain vulnerabilities and remote code execution risks. The servers they studied were publicly available, third-party implementations.

The blanket recommendation to avoid MCP conflates two very different problems. Pulling unvetted servers from public registries is one thing. Writing, operating and controlling your own MCP deployment is another. This paper is about that gap.

When your team wrote the code, handles its own credentials and controls where it runs, most of those findings just don’t apply. The risks that do carry over aren’t MCP problems. They’re the standard AI security issues that come with any agentic setup, and they’re manageable with controls you’d be running anyway.

The paper also covers the federal regulatory side: EO 14028, OMB M-16-21 and relevant CISA guidance. On attestation, OMB M-22-18’s standardized SSDF self-attestation form was rescinded by OMB M-26-05 in January 2026, so requirements are now agency-discretionary. Check with your contracting agency to confirm what they currently require.

The security concerns cited against MCP are failures in the public third-party ecosystem, not flaws in the protocol itself. Teams that build and run their own servers don’t inherit those risks. Where it gets more complicated for federal contractors is the compliance layer the security research community hasn’t touched: SBOM requirements, SSDF attestation under current agency policy and source code inventory obligations. None of those are optional, and this paper covers all of them.

 

ABOUT THE AUTHOR

Ian Meinert is a Subject Matter Expert at Aptive, specializing in enterprise AI strategy and federal health IT, supporting the Department of Veterans Affairs. With a career spanning VA systems modernization and healthcare data interoperability, he brings practitioner-level insight to agentic AI deployment in complex government environments. A retired Marine Corps Veteran and former VA federal employee, Ian combines operational discipline with deep institutional knowledge to help organizations navigate the transition from AI experimentation to mission-ready implementation.

Background: What is MCP and Why Does It Matter?

MCP is an open standard Anthropic released in November 2024. The short version: it’s a structured way for AI agents to talk to the tools and systems around them. Query a database, pull a document, push structured output to a downstream service. All through one consistent, auditable interface instead of a sprawl of custom integrations.

Before MCP, wiring LLMs into enterprise systems meant building custom connectors for each application, each with its own authentication model, error handling, retry logic and logging. At scale, that gets unwieldy fast. MCP replaces the sprawl with a single standardized layer.

The Published Concerns: What Critics Are Saying

CREDENTIAL EXPOSURE IN PUBLIC IMPLEMENTATIONS

Astrix Security analyzed 5,200 open-source MCP servers and the numbers aren’t good: 88% require credentials, 53% rely on long-lived static API keys or personal access tokens and only 8.5% actually implement OAuth (Astrix Security, 2025). That’s the public ecosystem in a sentence.

 

PROMPT INJECTION AND TOOL POISONING

A compromised MCP server sits between the model and everything it can touch. That’s a useful position for an attacker: embed instructions in the server’s response and the LLM treats them like legitimate user commands. OWASP puts this near the top of their LLM risk list for good reason.

 

SUPPLY CHAIN RISK (RUG PULLS)

A third-party MCP server that passes an initial security review can later be updated with malicious tool definitions by a compromised maintainer. It’s the same pattern as package poisoning attacks that have hit developer environments.

 

REMOTE CODE EXECUTION VIA CHAINED VULNERABILITIES

CVE-2025-6514 is a good example of how these chains unravel. The mcp-remote OAuth proxy had a flaw in how it processed OAuth metadata. An attacker could craft that metadata to inject shell commands and execute them with full user privileges. By the time it was disclosed, the package had been downloaded over 437,000 times (Peles & JFrog Security Research, 2025). Not a theoretical edge case.

One thing worth keeping in mind as you read these findings: most of the organizations publishing them sell products that address the exact risks they’re describing. That doesn’t make the vulnerabilities less real, and it doesn’t mean the research is wrong. But it does explain why each report tends to frame the problem as severe and the solution as procurement. Read the findings on their technical merits; just don’t let the framing do the threat modeling for you.

The Counter-Argument: Thread Model Mismatch

Every risk cited above assumes the same thing: the MCP server came from somewhere else. Change that assumption and the threat model looks completely different. If your team wrote it, reviewed it before it merged, containerized it and wired it to credentials you manage, the attack surface that worries researchers largely doesn’t exist.

Risk Applicability: Self-Hosted vs. Public Ecosystem

Four of the seven major risks the research community has identified simply don’t apply when you own the server. Rug pull attacks need a third-party maintainer with push access. Hardcoded secrets in community packages? You’re not pulling those packages. Tool poisoning from a public registry and RCE via compromised public servers both require connecting to those registries in the first place. When your team controls the repo and nothing external runs in your environment, those attack paths close.

Three risks do carry over. The most common one in practice is prompt injection: anything your MCP server pulls into context is a potential vector, and external data sources are the usual culprit. Overprivileged OAuth scopes are the second, because scope creep starts in dev environments and tends to make it to production quietly. The third is audit logging gaps if you didn’t build it in from the start. The mitigations aren’t complicated: OWASP LLM Top 10 input handling, least-privilege scope grants audited at each deployment and centralized tool call logging into a SIEM. None of this is MCP-specific. Same baseline you’d need for any agentic setup.

Most enterprise self-hosted setups are single-tenant, so cross-tenant leakage isn’t really on the table yet. That changes the moment multi-tenancy shows up on the roadmap. At that point, session isolation and token binding have to be part of the architecture from day one. Retrofit them later and you’re rebuilding, not patching.

Here’s how that maps to NIST 800-53’s System and Communications Protection family:

  • SC-2 (Application Partitioning): keeps tenant functionality separated from system management.
  • SC-4 (Information in Shared Resources): the control most directly on point, since unauthorized info transfer through shared components is exactly what multi-tenant MCP deployments risk.
  • AC-3 / AC-4: authorization at the session boundary and information flow control between tenants.
  • SC-8 (Transmission Confidentiality and Integrity): comes into play once MCP nodes are talking across network segments.
  • IA-4 (Identifier Management): where token binding actually lives. It’s not an access-control afterthought, it’s about how identifiers get assigned and bound to sessions in.

DevSecOps and SDLC Comparison

Compared to pulling from the public MCP ecosystem or building bespoke custom integrations, self-hosted MCP wins on almost every dimension that matters for regulated work. On credential risk: self-hosted is low because your team controls injection and rotation. The public ecosystem is high (Astrix found 53% of servers relying on static secrets). Custom integrations depend entirely on the team. Supply chain exposure is the starker gap: zero for self-hosted because you own every line, high for public servers where rug pulls and tool poisoning are live threats, and moderate for custom builds where library and SDK dependencies introduce their own risk.

Observability is where self-hosted MCP has a real structural edge. All tool calls run through one client, so logging is centralized whether you want it to be or not. Public MCP gives you the same client-side logging, but you’re blind to what the server itself is doing. Custom integrations are the hardest: each connector logs on its own terms, and pulling a unified view together is work you have to do manually. On ATO and compliance, self-hosted maps cleanly to NIST 800-53 controls. The public ecosystem doesn’t work for authorization-boundary systems. Custom integrations have a well-worn path through the audit process, though you’re not getting credit for anything you didn’t build explicitly.

Development velocity at scale favors both self-hosted MCP and the public ecosystem over custom builds. With MCP you get a single protocol, reusable server implementations and consistent patterns you can carry across every AI tooling project. Custom integration work starts from scratch every time: different auth model, different logging approach, different everything. Long-term, self-hosted MCP tracks where agentic AI architecture is going. Custom integrations don’t have a natural path there.

A Real Limitation: Token Overhead

The security argument isn’t the only thing giving teams pause. Context window cost is a separate concern and worth taking seriously on its own terms. Every MCP server loaded at session start dumps its full tool schema into context, whether those tools get used or not. Owens (2026) measured this across typical multi-server configurations and found overhead ranging from 32,000 to 82,000 tokens per session. One developer tracked 81,986 tokens consumed before typing a single question. A search MCP covering eight providers alone chewed through more than 14,000 of those tokens, and no search actually ran. That’s a lot of context window gone before the work starts.

Some teams have responded by ditching MCP servers altogether for CLI tools and lightweight instruction files that only activate when needed (Owens, 2026; FlowHunt, 2025). That solves the token problem, but you give up MCP’s standardization and authentication model, which matters when you’re operating in regulated environments. Testing for this paper turned up a better path: lazy-loading MCP. Tool definitions live outside the context window and only surface when the agent matches them to a query. Typical usage ran 3,000 to 5,000 tokens per query across three to five matched tools. The full schema never loads. Governance and auditability stay intact, same as eager-loading.

Skills+CLI removes the protocol entirely, which is a reasonable call for individual developer workflows where you don’t need audit trails or formal access controls. Deferred MCP loading keeps the protocol but changes when definitions enter context, so you only pay for what you actually use. For anything touching federal data or regulated systems, lazy-loading self-hosted MCP is the more defensible setup. Token overhead is a real problem worth solving. Just not by throwing out the protocol.

Required Controls for Self-Hosted MCP Deployments

If your MCP deployment is touching sensitive or regulated data, the following controls aren’t optional extras. They’re the starting point.

 

Authentication and Credential Management
  • OAuth 2.1 for all MCP server authentication. Static API keys and PATs get rejected at the gateway layer.
  • Credentials go in a secrets vault. Not environment variables, not source code.
  • Set a rotation schedule and document the procedure in the server’s runbook. If it’s not written down, it won’t happen consistently.

 

Runtime Isolation
  • Every MCP server runs in a container with explicit CPU, memory, and network limits. No exceptions for “low-risk” internal tools.
  • Container network egress is restricted to a defined allowlist of internal endpoints. MCP server processes don’t get unrestricted outbound internet access.
  • Non-root user contexts inside containers. MCP server processes don’t need host-level privileges, and they shouldn’t have them.
Supply Chain, Version Control and SBOM
  • MCP server code lives in version-controlled repos. Peer review before merge, no exceptions. If someone can push directly to the server without a review, that’s the attack surface.
  • Tool schema definitions are treated as code: versioned, reviewed, and change-controlled.
  • Pin server images to specific digest hashes in deployment manifests. No floating latest tags in production.
  • No community MCP servers from public registries without a full source review and an internal fork. The whole point of self-hosting is that you own what runs.
  • Generate and maintain an SBOM for every internally developed MCP server. Use SPDX or CycloneDX format consistent with NTIA minimum elements. EO 14028 Section 4(e)(vii) requires SBOM provision for software sold to federal agencies, but exact delivery requirements flow from your agency’s contract terms. Confirm those requirements early, not at delivery. Update the SBOM with every release and keep it for the full contract period of performance.
  • Run every SBOM component against the CISA Known Exploited Vulnerabilities catalog at each build and before production deployments. Anything KEV-listed doesn’t ship without an approved mitigation plan in hand.
  • Attest to SSDF (NIST SP 800-218) compliance before delivering any MCP server component to a federal agency. The standardized self-attestation form from OMB M-22-18 was rescinded by M-26-05 in January 2026. Each agency now sets its own attestation requirements. Find out what your contracting agency wants before you deliver, not after.

 

Federal Source Code Obligations (OMB M-16-21)

OMB M-16-21 hasn’t been rescinded. If you’re building MCP servers under a federal contract, these obligations apply regardless of whether your program officer has raised them:

  • Keep an inventory of all custom-developed MCP server code produced under the contract. It needs to be registered in the agency’s code repository (code.gov or equivalent) within 90 days of development completion. That window comes up faster than teams expect.
  • At least 20% of that code goes open source unless you have a documented exemption signed off by the agency CIO. Budget this into the delivery plan up front.
  • Government data rights apply to code developed under federal contract. Make sure your contract terms reflect the right government use and data rights clauses (FAR 52.227-14 or equivalent). Don’t let this get papered over at award and discovered at delivery.

 

Observability and Audit Logging
  • All MCP tool call logs go through a SIEM-compatible pipeline. Every invocation gets logged: tool name, parameters, caller identity, timestamp, result. No gaps.
  • Map your logging to NIST 800-53 AU-12 and AU-3. If you’re logging what’s described in the bullet above, you’re mostly there.
  • Anomaly detection on tool call patterns. Unexpected invocations or high-frequency calls should alert. If something’s calling a data-write tool 300 times in two minutes, you want to know.
  • EO 14028 requires federal systems to retain logs for a minimum period set by agency policy and to share them with CISA on request during an incident investigation. Know your agency’s retention window. Don’t find out during an incident that logs rolled over.

 

Input Validation and Prompt Injection Defense
  • Pre-call interceptors validate tool call parameters against expected schemas before execution. Anything that doesn’t match the schema shouldn’t reach the tool.
  • Sanitize external data before it enters the LLM context. The OWASP LLM Top 10 input handling guidance is a practical starting point; most of what it covers applies directly here.
  • Human-in-the-loop gates for any tool call that writes data or touches sensitive records. Let the model assist; keep humans in the decision on consequential actions.
  • Least-privilege scope grants. Audit OAuth scopes at each deployment and again before compliance reviews.

Third-Party AI and MCP Vendor Evaluation

Pulling in a third-party AI component, whether that’s a foundational model, an AI platform or someone else’s MCP server, means your supply chain now includes code you didn’t write. A quick security scan doesn’t cover it. The framework here picks up where the supply chain controls above left off, applied to your vendor relationships specifically.

Start with secure development practices. Does the vendor attest to SSDF (NIST SP 800-218)? For federal work, find out what your contracting agency currently requires before you ask the vendor. The standardized form that used to be the default was pulled when M-26-05 superseded M-22-18, and each agency now sets its own bar under EO 14028.

On SBOM: does the vendor provide a machine-readable SBOM for the component or model? The format needs to be SPDX or CycloneDX, consistent with NTIA minimum elements. EO 14028 points to SBOM provision for federal software, but exact delivery requirements flow through agency contract terms and current OMB guidance under M-26-05. Check with your contracting agency before you assume what’s required.

Ask about training data provenance. Is the training data documented? Are sources disclosed? For sensitive domain deployments you need a published model card with training data provenance and no undisclosed third-party data (NIST AI 600-1 and AI RMF GV-5.1 set the bar). Also pull the vendor’s incident disclosure history: look for a published CVE record, a responsible disclosure policy and nothing critical sitting undisclosed in the last twelve months.

On data handling: where is inference data processed and stored, and does the vendor use it for model training? You need a documented processing location, an opt-out from training data use and for federal deployments, data has to stay within authorized boundaries (FedRAMP; VA Handbook 6500 where applicable). Access control is a separate question worth asking explicitly: OAuth 2.1 support, no static long-lived tokens, and documented credential rotation. NIST 800-53 IA-5 and AC-3 cover this.

Check whether the component emits auditable logs in a standard format. Structured JSON and OpenTelemetry support are what you want, with configurable retention (NIST 800-53 AU-2 and AU-12). For anything custom-developed under a federal contract, also verify whether M-16-21 applies. If it does, the component needs to be inventoried in the agency’s code repository and the 20% open source release obligation kicks in unless there’s a documented exemption.

Finally, get a vulnerability response SLA in writing. The bar is patch or mitigation within 15 days for critical findings, 30 for high, documented in the contract or terms of service (EO 14028 and CISA guidance set the expectation). Run this evaluation at initial onboarding and revisit it annually, or whenever a vendor ships a major version update to something you’re running in production. AI components change fast enough that a one-time review goes stale.

Set a reminder to revisit it. Vendor posture shifts, models get updated, and a component that cleared review six months ago may look different today.

Recommendations

Self-hosted MCP, built and operated with the controls in this paper, is a sound architecture for agentic AI in regulated environments. The security concerns circulating in the research community are real, but they’re about a different deployment model. For federal programs specifically, the layer that hasn’t gotten attention is the compliance side: SBOM generation, SSDF attestation under your contracting agency’s current requirements (which shifted when M-26-05 rescinded M-22-18), and source code inventory under OMB M-16-21. That’s what separates a technically solid deployment from one that blows up at delivery.

 

  • Write and deploy your own MCP servers for all agentic AI capabilities that need tool access. Don’t pull from public registries for production use.
  • Any community MCP server needs a full source review and an internal fork before it touches your environment. No exceptions for “just a quick test.”
  • Generate SBOMs for every internally developed MCP server and wire CISA KEV scanning into your CI/CD pipeline before any federal deployment. Catching vulnerable dependencies at build time is much easier than explaining them post-award.
  • Get SSDF attestations from third-party AI and MCP component vendors per your contracting agency’s current policy before integrating anything into a federal-adjacent system. Requirements vary by agency now that M-22-18 has been rescinded.
  • Build a source code inventory process into the delivery plan for any federal MCP work. OMB M-16-21 is still active, and that 90-day registration window closes faster than teams expect.
  • Run the third-party vendor evaluation framework at initial onboarding and revisit it annually. Major updates come fast in AI, and a clean review from 12 months ago can go stale quickly.
  • Start NIST 800-53 control mapping at the design phase, including the SR control family. Retrofitting supply chain documentation after deployment is painful and usually incomplete.

References

Astrix Security. (2025, October 15). State of MCP Server Security 2025: 5,200 servers, credential risks, and an open-source fix. https://astrix.security/learn/blog/state-of-mcp-server-security-2025/

Atlassian. (2025, June). MCP clients: Understanding the potential security risks. https://www.atlassian.com/blog/artificial-intelligence/mcp-risk-awareness

Cybersecurity and Infrastructure Security Agency. (2023, April). Zero trust maturity model, Version 2.0. https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf

Cybersecurity and Infrastructure Security Agency. (2023). Secure by design principles. https://www.cisa.gov/resources-tools/resources/secure-by-design

Cybersecurity and Infrastructure Security Agency. (2023). Software bill of materials (SBOM) resources. https://www.cisa.gov/sbom

Cybersecurity and Infrastructure Security Agency. (n.d.). Known exploited vulnerabilities (KEV) catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Docker. (2025, October). MCP security explained: Identity risks in the Model Context Protocol ecosystem. https://www.docker.com/blog/mcp-security-issues-threatening-ai-infrastructure/

Executive Office of the President. (2021, May 12). Executive Order 14028: Improving the nation’s cybersecurity. Federal Register, 86(93), 26633–26661. https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity

Anthropic. (2024). Model Context Protocol specification. https://modelcontextprotocol.io

MCP Security Community. (2026). MCP top 10 security risks. https://modelcontextprotocol-security.io

Joint Task Force. (2020). Security and privacy controls for information systems and organizations (NIST SP 800-53, Rev. 5). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-53r5

Dodson, D., & NIST. (2022, February). Secure software development framework (SSDF), Version 1.1 (NIST SP 800-218). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-218. Note: Version 1.2 released as Initial Public Draft December 17, 2025; v1.1 remains the current final version.

Office of Management and Budget. (2016, August 8). M-16-21: Federal source code policy. https://obamawhitehouse.archives.gov/sites/default/files/omb/memoranda/2016/m_16_21.pdf

Office of Management and Budget. (2022, September 14). M-22-18: Enhancing the security of the software supply chain through secure software development practices. Note: Rescinded by OMB M-26-05 (January 2026). https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf

Office of Management and Budget. (2025, April 3). M-25-21: Accelerating federal use of AI through innovation, governance, and public trust. https://www.whitehouse.gov/wp-content/uploads/2025/04/M-25-21.pdf

Office of Management and Budget. (2025, April 3). M-25-22: Driving efficient acquisition of artificial intelligence in government. https://www.whitehouse.gov/wp-content/uploads/2025/04/M-25-22.pdf

Office of Management and Budget. (2026, January 23). M-26-05: Adopting a risk-based approach to software and hardware security. https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf

OWASP Foundation. (2024). OWASP top 10 for large language model applications, Version 2025. https://owasp.org/www-project-top-10-for-large-language-model-applications/

Peles, O., & JFrog Security Research. (2025, July 9). Critical RCE vulnerability in mcp-remote: CVE-2025-6514 threatens LLM clients [CVSS 9.6]. https://jfrog.com/blog/2025-6514-critical-mcp-remote-rce-vulnerability/

Red Hat. (2025, November). Model Context Protocol (MCP): Understanding security risks and controls. https://www.redhat.com/en/blog/model-context-protocol-mcp-understanding-security-risks-and-controls

Trend Micro. (2026, April). Update on exposed MCP servers: The threat widens to the cloud. https://www.trendmicro.com/vinfo/us/security/news/vulnerabilities-and-exploits/update-on-exposed-mcp-servers-the-threat-widens-to-the-cloud

Owens, J. (2026). MCPs are dead. https://joshowens.dev/mcps-are-dead/

FlowHunt. (2025). Why top engineers are ditching MCP servers. https://www.flowhunt.io/blog/why-top-engineers-are-ditching-mcp-servers/

© 2026 Aptive Resources  •  All rights reserved
Futuristic digital data streams and floating screens in a high tech environment.

The Series

Article 1 puts the series in federal governance context. Article 2 gets into operational maturity: what a production-ready agentic AI program actually looks like day to day. After that, we’ll cover the technical core, built for delivery architects, DevSecOps leads and ATO teams, with each article building on the previous one.

Digital security and data protection concept with blockchain and shield icons.

1. NIST AI RMF 1.0 Alignment Analysis: Agentic AI Governance for Federal Programs

Coverage assessment mapping the series to all four AI RMF functions and naming residual gaps

 

PUBLISHED: August 18, 2026
Read More
Read More
Digital analytics and growth data visualization on a smartphone screen.

2. Advanced Operational Maturity for Multi-Agent AI Systems

KPI baselines, model risk lifecycle, data lineage, continuous assurance and ATO evidence packaging

 

PUBLISHED: AUGUST 18, 2026
Read More
Read More
Futuristic AI chatbot icons connected to a central server for AI governance.

3. Organizational AI Governance: Frameworks, Artifacts and Implementation Guidance

The nine artifacts a defensible AI program needs, from risk tolerance through incident response

 

PUBLISHED: AUGUST 25, 2026
Read More
Read More
Cloud computing and data storage concept with cloud icon and database servers.

4. Multi-Model and Multi-Agent AI Systems: Infrastructure Implementation Guide

The security infrastructure behind the policy, from sandboxed code execution to a CISA-aligned 72-hour AI incident response plan

 

PUBLISHED: SEPTEMBER 1, 2026
Read More
Read More
Digital security and AI governance concept with shield, gear, and globe on smartphone.

5. The Orchestrator Capability Manifest: Governing Tool Access, Prompt Integrity and Model Authorization in Multi-Agent AI Systems

Structured governance artifact defining agent roles, tool grants, prompt versioning and model pinning

 

PUBLISHED: September 8, 2026
Read More
Read More
Digital security and automation concept with a laptop and flowchart icons.

6. Multi-Model and Multi-Agent AI Workflows: Architecture, Risk and DevSecOps Controls

Trust boundaries, interagent messaging controls, human-in-the-loop gate design and authorization

 

PUBLISHED: September 15, 2026
Read More
Read More
Digital data servers with a gear icon representing AI governance and data management.

7. Model Context Protocol (MCP) Servers in Enterprise AI Architecture

Security architecture, supply chain controls and NIST 800-53 mapping for self-hosted MCP servers

 

PUBLISHED September 22, 2026
Read More
Read More