MCP server security checklist: best practices for enterprise AI

Updated 21 August, 2026

TL;DR: When an AI agent executes a tool call through a Model Context Protocol (MCP) server, it creates a governance gap that traditional network security tools cannot close, because those tools inspect packets, not the semantic intent of an AI's decision. Securing MCP servers in a regulated enterprise requires an operational checklist where every onboarding step, tool permission, and runtime control maps to AIUC-1, NIST AI RMF (AI Risk Management Framework), and OWASP (Open Worldwide Application Security Project) Agentic AI standards. This checklist covers that scope for compliance teams in financial services, manufacturing, and defense-adjacent organizations.

For compliance teams in regulated industries, the gap between MCP server deployments and governance documentation is structural. MCP servers enter environments through developer toolchains, not procurement workflows, leaving no default onboarding gate before a server becomes a production dependency. No asset record, no access policy, and no audit log reaching your SIEM (Security Information and Event Management) means the invisible asset is exactly what an OCC examiner, FDIC examiner, or AIUC-1 assessor will find.

The scale of this exposure is concrete: CVE (Common Vulnerabilities and Exposures) 2025-6514, a critical OS command injection vulnerability in the mcp-remote package, carries a CVSS (Common Vulnerability Scoring System) 3.1 base score of 9.6 and was present in integration guides from Cloudflare, Hugging Face, and Auth0 before the flaw was disclosed. The vulnerability was rooted in a failure to sanitize the authorization_endpoint URL value received from a remote MCP server during OAuth (Open Authorization) flow initialization. Neither a network firewall nor a web application firewall can parse the semantic content of an AI agent's tool call decision, and the MCP specification itself states it "cannot enforce these security principles at the protocol level," placing the governance burden entirely on the enterprise.

This MCP server security checklist covers the full MCP server lifecycle: onboarding validation, tool permission scoping, runtime policy enforcement, audit log generation, configuration drift detection, and decommissioning. Every item maps to a recognized control so that OCC examiners, FDIC examiners, and AIUC-1 assessors can trace your evidence back to a specific framework requirement.

Mapping checklist items to regulatory controls

Telling an AIUC-1 assessor or OCC examiner "we support NIST AI RMF" carries no weight without a documented mapping that traces each technical control to a specific framework pillar, function, or requirement. The tables and summaries below provide that mapping for the primary frameworks your organization is most likely reporting against, starting with AIUC-1 as the cross-framework anchor.

Mapping MCP servers to AIUC-1 controls

AIUC-1 is the primary cross-framework anchor for enterprise vendor due diligence and procurement attestation. Its six pillars (Security, Safety, Reliability, Accountability, Data and Privacy, and Society) cover the full scope of MCP server risk. Three pillars apply directly to MCP server governance.

Registering MCP servers in a governed AI System, enforcing runtime access controls, and generating SIEM-formatted audit logs addresses all three directly applicable pillars in a single traceable workflow, producing evidence that maps across the full six-pillar AIUC-1 standard through the crosswalk at aiuc-1.com/crosswalks. The AIUC-1 crosswalk at aiuc-1.com/crosswalks maps these pillars to NIST AI RMF, OWASP Agentic Applications, ISO/IEC 42001, and the EU AI Act simultaneously, so one control set produces cross-framework evidence. The Practical AI episode 312, a deep dive on the Model Context Protocol, lays out the foundational mechanics of how MCP connects models to tools and external systems, the same architecture that makes system-level, cross-tool audit logging necessary once these workflows move into regulated production environments.

NIST AI RMF control mapping table

The NIST AI RMF implementation playbook on the Prediction Guard blog details how to operationalize each function across your AI system inventory.

Mapping controls to OWASP Agentic AI

The OWASP Agentic Applications 2026 standard identifies two risk categories that apply directly to MCP server deployments.

ASI02 (Tool Misuse and Exploitation) covers scenarios where agents use legitimate tools in unsafe ways or where attackers exploit tool interfaces to gain unauthorized access. A compromised server can redirect tool calls to malicious endpoints without the agent or the policy layer detecting the substitution. Runtime controls that enforce permitted tool call patterns on every invocation are the primary ASI02 mitigation.

ASI04 (Agentic Supply Chain Vulnerabilities) covers risks from third-party tools, plugins, MCP servers, or external components admitted to agent workflows. Your MCP server registration process, producing an AIBOM in CycloneDX format, is the mechanism that provides the continuously maintained asset inventory ASI04 mitigation requires. The Prediction Guard EP04 video on OWASP implementation walks through how to map these items to system-level controls.

ASI03 (Identity and Privilege Abuse) is the third relevant category: when an MCP server operates with broader permissions than its assigned task requires, it creates the same access escalation risk that ASI03 addresses. Granular, role-based permission scoping at registration is the documented control.

Validating MCP server compliance at onboarding

The onboarding phase is where most compliance gaps originate. Follow this five-step process for every MCP server admitted to a governed AI System.

1. Verify server origin and authentication. For remote MCP deployments, the baseline standard is OAuth 2.1 with PKCE (Proof Key for Code Exchange). Per the CSA's MCP authorization analysis, access tokens should be short-lived and scoped to reduce blast radius in the event of a compromise. Reject connections that present only static API keys.
2. Authenticate cryptographic signatures. Download the vendor's public key from a trusted channel, compute a SHA-256 (Secure Hash Algorithm 256-bit) hash of the server binary or container image, and verify the hash against the vendor-signed signature. A verification failure means the server binary has been modified since signing. Log this verification step to support ISO/IEC 42001 Annex A Control A.6.2.8 event log requirements.
3. Document the data access scope. Define in writing what data the server is authorized to touch: specific database schemas, file system paths, API endpoints, and data classifications. This permission inventory is what an OCC examiner, FDIC examiner, or AIUC-1 assessor will review line by line. Any scope not documented at onboarding is an uncontrolled exposure.
4. Register the server in your centralized asset registry. In the Prediction Guard Admin Console, register the MCP server as part of a governed AI System. Capture the server name, version, vendor, signing key fingerprint, the tools it exposes, scoped permissions for each tool, and the AI agents it serves. Record the approver name and UTC timestamp. Every subsequent update or retirement must be timestamped in the same record. The Prediction Guard EP12 video on self-hosted sovereignty demonstrates how this centralized registry produces an AIBOM (AI Bill of Materials) in CycloneDX format on demand.
5. Tag the framework mapping at registration. Link each MCP server record to the AIUC-1 pillars, NIST AI RMF functions, and OWASP Agentic AI items it addresses. This cross-framework tag becomes the anchor for every subsequent audit artifact, eliminating manual reconciliation when examiners request evidence against different standards simultaneously.

Compliance gatekeeper: MCP server AIBOM onboarding checklist

Use this template to document each MCP server at registration. Export the completed registry as an AIBOM in CycloneDX format for AIUC-1 assessor or procurement reviewer evaluation.

• Server name, version, and vendor
• Cryptographic signing key fingerprint verified
• OAuth 2.1 or equivalent authentication method confirmed
• Tool inventory: list each exposed tool with read/write scope
• Data classification of accessible resources (PII (Personally Identifiable Information), regulated data, proprietary IP)
• Approved use case and owning AI agent or workflow
• Registration approver name, title, and UTC timestamp
• Linked AIUC-1 pillar mapping (Security, Accountability, Data and Privacy)

Defining least privilege for MCP tool access

An agent that can call write-enabled tools when its task requires only read access is an open compliance exposure under AIUC-1's Accountability pillar, NIST AI RMF's Manage function, and OWASP ASI03. Follow this five-step process to document and enforce least-privilege access.

1. Map tool functions to NIST controls. Align each tool's permission level to a NIST AI RMF Manage function mitigation. Document the rationale for each permission level in the Admin Console registration record.
2. Define field-level data access per tool. Restrict the specific data fields and schemas each MCP tool can access. A tool ingesting customer records for a financial services agent should be limited to the fields required for the task, not the full table. Document field-level scope in the same registration record as the tool's permission level. This scope minimization reduces the data exposure surface when a server is compromised, a lesson reinforced by the CVE-2025-6514 disclosure discussed above.
3. Configure role-based access policies in AI System Configuration. In the AI System Configuration in the Prediction Guard Admin Console, your GRC (Governance, Risk, and Compliance) team defines which agents, users, and applications are permitted to call which MCP servers. You configure permissions once and the control plane enforces them uniformly at runtime on every call. Developers do not manage access logic inside application code, and only the base_url changes to point existing OpenAI-compatible or Anthropic-compatible SDK calls at the governed endpoint.
4. Define the examiner evidence package for access control. When an OCC examiner, FDIC examiner, or AIUC-1 assessor requests proof that least-privilege is enforced, provide: the documented permission inventory for each tool, the access policy configuration records from the Admin Console, and audit log entries showing blocked calls (where an agent attempted to use a tool outside permitted scope) enforced at the control plane before the call completed. Retrospective log analysis does not satisfy this requirement. The enforcement must happen at call time and the log must be the record of it.
5. Establish the baseline compliance requirement. Across all primary frameworks, the baseline is the same: every MCP tool invocation must be subject to a documented access policy, enforced at runtime, and logged in a format a named examiner can retrieve and evaluate. Document this baseline before any MCP server is admitted to a production AI System.

Implementing third-party risk controls for MCP

Every MCP server sourced from a third party is a supply chain risk item under OWASP ASI04 and AIUC-1's Accountability pillar. The governance burden falls entirely on the enterprise consuming the server, because the MCP specification does not enforce security at the protocol level.

• Audit digital signatures on a recurring cadence. Each time a vendor ships a new server version, re-verify the cryptographic signature before admitting the update to your environment. Log the verification result as part of the server's asset record.
• Trace third-party dependency provenance. Request a software bill of materials (SBOM) from each vendor and verify that no upstream dependency carries known vulnerabilities above your organization's accepted CVSS threshold.
• Embed contractual controls in vendor agreements. Include three baseline requirements: mandatory vulnerability disclosure within a defined SLA (Service Level Agreement) (specify CVSS thresholds and notification channels in the contract), written confirmation that the server does not transmit governed data to external systems outside the agreed architecture, and liability clauses assigning remediation responsibility for supply chain compromises that originate in vendor code.
• Export AIBOM records in CycloneDX format. When you register MCP servers in your AI System inside the Prediction Guard control plane, the registration captures models and MCP servers. The AIBOM export in CycloneDX format includes component names, versions, vendor information, license data, and provenance metadata. EU AI Act Article 11 and Annex IV require detailed technical documentation of a high-risk AI system's development elements, data, dependencies, and risk management processes. The Act does not name AIBOM or CycloneDX as required formats, but an AIBOM export in CycloneDX format is a practical mechanism for organizing and producing the component-inventory portion of that documentation obligation. The AIBOM is the audit export that AI System registration produces, not a standalone capability.
• Map third-party risk mitigations to framework controls. Document every mitigation against its AIUC-1 Accountability pillar control, NIST AI RMF Manage function, and OWASP ASI04 mitigation in your compliance documentation. This cross-framework trace allows an AIUC-1 assessor to evaluate your vendor risk program without requiring separate documentation packages for each standard.

Establishing runtime controls for MCP compliance

A policy that exists in a document but is not enforced at the system level is a liability waiting to surface in the next audit cycle. The table below illustrates the operational difference between document-based compliance and system-level enforcement.

The scaling agentic AI article on the Prediction Guard blog covers cost, governance, and compliance considerations at enterprise scale.

Operationalizing runtime controls for MCP compliance requires four steps.

1. Map AUP (Acceptable Use Policy) clauses to system-level controls. An AUP clause prohibiting PII transmission to external MCP tools maps to a runtime PII detection and masking control enforced by the Prediction Guard control plane on every call. An AUP clause prohibiting write access to production databases is operationalized as a runtime access policy configured in the AI System Configuration in the Admin Console: agents authorized only for read operations have write-enabled tool calls blocked by the control plane at the point of invocation, before the call reaches the database.
2. Enforce policies on every call, not sampled calls. Prediction Guard validates every model and tool call against active policies at runtime, before execution. The control plane checks the call, allows it, blocks it, or rewrites it, then generates the audit log as the record of that enforcement. This is not retrospective log analysis. It is active enforcement, and the distinction matters to an OCC or FDIC examiner who asks whether your controls are preventive or detective. The Prediction Guard secure control plane overview video explains this architecture in concrete terms.
3. Block data exfiltration before it reaches an MCP tool. Runtime policy enforcement detects and masks PII and proprietary IP before transmission to external MCP tools or model endpoints. This applies to the full input scope: prompts, retrieved documents, database query results, and tool call arguments. An agent operating on a financial services dataset should never transmit raw customer account numbers to a third-party MCP tool, regardless of what the agent's reasoning layer decided.
4. Validate injection defense controls. Prompt injection attacks targeting MCP tools map to ASI01 (Agent Goal Hijack), where attackers manipulate an agent's objectives through malicious artifacts or forged agent-to-agent messages. Runtime injection detection validates inputs to the MCP call chain before the model processes them, and blocks calls where input contains patterns consistent with an attempt to redirect the agent's decision pathway.

Generating audit-ready MCP security evidence

Prediction Guard generates structured audit logs as a byproduct of active runtime enforcement. The customer configures their SIEM to consume those logs through their own ingestion pipeline.

1. Capture required log fields. ISO/IEC 42001 Annex A Control A.6.2.8 requires event log recording throughout the AI system lifecycle, spanning initial deployment through real-time inference. For MCP server compliance, each log entry must capture: timestamp (UTC), user or agent identity, the specific tool invoked, call arguments (or a hash if classified), the policy decision (allowed, blocked, or rewritten), and the governing policy identifier. This produces a replayable trace bound to users, sessions, and data sources.
2. Define retention in your SIEM, not in the control plane. Prediction Guard formats audit log output and forwards it to the customer's SIEM or observability platform ingestion pipeline (including Grafana). Retention, storage, and search are handled entirely by your SIEM or observability platform. Set retention consistent with your existing records retention schedule for regulated data, applying the specific periods required under your applicable framework obligations.
3. Configure native SIEM formatting on the Monitor page. The four-step workflow in the Prediction Guard Admin Console: open the Monitor page and select the target SIEM integration (Splunk, Datadog, CrowdStrike, Grafana, or generic syslog), click Configure under the chosen integration, confirm to make the integration live, and the control plane formats audit log output using the field structure your SIEM expects natively. Your existing ingestion pipeline (HEC (HTTP Event Collector) endpoint, Datadog agent, Grafana agent, or syslog collector) handles delivery under your own controls.
4. Pre-build SIEM queries for examiner access. Structure your SIEM or Grafana dashboards so that an OCC examiner, FDIC examiner, or AIUC-1 assessor can retrieve, within the timeframe they specify, all tool invocations for a named agent over a specified time window, all policy enforcement events for a specific MCP server, and all access denial events by user or agent identity. If your SIEM or Grafana instance requires a custom query to produce that output, pre-build and test it before your next examination cycle, not after the request arrives.

Detecting and remediating MCP configuration drift

A control that passed your last formal review may not reflect current operational reality. Engineers add tools, expand permissions, or connect new MCP servers outside the governance workflow, and the drift is invisible until the next scheduled review cycle. Close that gap with this four-step process.

1. Automate quarterly baseline comparisons. Configure your SIEM or Grafana to run automated checks against the registered MCP server baseline on at least a quarterly cadence. Work with your security operations team to build queries that compare current tool permission scopes to the registered baseline, flag any server version that changed without a new signature verification log entry, and surface any agent calling tools outside permitted scope. Automate report delivery to your compliance team lead with a fixed SLA for remediation.
2. Identify servers operating outside the control plane. Reconcile your registered MCP server inventory against the enforcement log output in your SIEM or Grafana on a recurring cadence. Any server that appears in the asset registry but is absent from recent enforcement log records requires investigation: the server may be inactive, the integration may be misconfigured, or calls may be reaching the server through a path that bypasses the control plane entirely. Document the outcome of every investigation in the Admin Console registration record for your next AIUC-1 assessor review.
3. Refine threat impact models from drift data. Update your risk model each quarter based on drift detection data. A server that has triggered multiple access denial events in the prior quarter warrants a higher risk rating than one with a clean record. Adjust tool permission scope and access controls accordingly, and document the rationale for every change in the Admin Console registration record.
4. Document drift remediation as framework evidence. Record every drift detection and remediation event in your compliance program as evidence of NIST AI RMF Manage function execution and AIUC-1 Accountability pillar compliance. Each remediation closes a control gap and produces a timestamped record that demonstrates continuous monitoring, not point-in-time assessment.

Audit-ready offboarding for MCP server assets

Decommissioning an MCP server without a documented retirement process creates a persistent compliance exposure. Orphaned asset records, unrevoked tokens, and missing final log exports are among the most common findings when examiners review AI asset lifecycle controls. Follow these five steps.

1. Revoke all active authentication tokens. At the moment of decommissioning, revoke all OAuth tokens issued to the server, rotate or destroy all associated API keys, and document the revocation with UTC timestamps in the Admin Console retirement record. Use secure deletion tools appropriate to your data classification requirements to erase cryptographic material rather than archiving it.
2. Export and archive the server's interaction log history before decommissioning. Compile the full enforcement log record for the server from your SIEM and archive it in an immutable format before removing the server from the asset registry. Retention periods vary by framework, sector, and jurisdiction. Confirm the applicable retention period with your legal team before initiating decommissioning, and document that confirmation in the retirement record.
3. Update the asset registry. Mark the server as "Decommissioned" in the Prediction Guard asset registry with the UTC timestamp, the name and role of the team member authorizing retirement, and the reference to the final AIBOM export confirming removal from the active inventory.
4. Compile the retirement evidence package. A complete package for an AIUC-1 assessor or procurement reviewer includes:
   • Token revocation log with UTC timestamps
   • Final SIEM log export archived per your retention schedule
   • Admin Console retirement record with approval chain
   • Data purge attestation confirming secure deletion of cached context and temporary files
   • Dependency impact assessment listing every affected agent or workflow and re-routing details
   • Final AIBOM export confirming the server is absent from the active asset register
5. Map retirement steps to framework controls. Token revocation maps to AIUC-1 Security pillar controls. Log export maps to ISO/IEC 42001 A.6.2.8 event log requirements. Registry closure maps to NIST AI RMF Manage function lifecycle controls. The retirement evidence package is your proof that the asset's lifecycle was governed from registration through decommissioning.

Validated security requirements for MCP servers

Securing MCP servers in a regulated enterprise requires a self-hosted AI control plane that enforces policies on every tool call before execution, generates structured audit logs formatted natively for your SIEM or observability platform (including Grafana), and maintains a complete, exportable asset inventory in CycloneDX format. External gateways that route telemetry outside your perimeter fail the data sovereignty requirement. Document-based policies that rely on developer adherence fail the continuous enforcement requirement.

To operationalize this checklist:

• Run signature verification and permission scope reviews quarterly at minimum
• Build SIEM or Grafana queries that surface tool invocations falling outside the permitted scope defined in each server's registered access policy, and schedule automated delivery of query results to your compliance lead on a recurring cadence
• Schedule periodic AIBOM exports and cross-framework reviews before regulatory examination cycles
• Organize your compliance documentation package with AIBOM, access policy configuration, runtime enforcement evidence, and drift remediation records readily accessible
• Configure SIEM or Grafana retention consistent with your regulatory requirements for AI interaction data A single MCP server registration record, enforced by a self-hosted control plane, produces cross-framework evidence for AIUC-1, NIST AI RMF, OWASP Agentic AI, and ISO/IEC 42001 simultaneously. You configure governance policy once in the Admin Console, and the control plane enforces it across every call regardless of which SDK the developer used.

Book a deployment scoping call to assess how the self-hosted control plane fits your existing SIEM infrastructure and examination timeline. Download the NIST AI RMF capability mapping whitepaper to review which framework functions Prediction Guard addresses at the system level before your next examiner review.

FAQs

What is CVE-2025-6514 and why does it matter for MCP server security?

CVE-2025-6514 is a critical OS command injection vulnerability in the mcp-remote package, carrying a CVSS 3.1 base score of 9.6. It exploits improper sanitization of OAuth flow parameters in unauthenticated MCP proxies. Exploitation is not purely remote: user interaction is required, because the victim must initiate a connection to the malicious server, at which point the attacker can achieve arbitrary code execution on the client system. The package appeared in integration guides from Cloudflare, Hugging Face, and Auth0 before the flaw was disclosed.

Why can't a network firewall or WAF secure MCP server communications?

A network firewall inspects ports and IP addresses, and a WAF inspects HTTP paths and headers, but neither can parse the semantic intent of an AI agent's tool call decision. The MCP specification itself states it "cannot enforce these security principles at the protocol level," and semantic attacks like tool poisoning bypass signature-based tools entirely, requiring a runtime governance control plane inside the trust boundary.

What is the ISO/IEC 42001 A.6.2.8 requirement for MCP server logs?

ISO/IEC 42001 Annex A Control A.6.2.8 requires event log recording throughout the AI system lifecycle, capturing prompts, tool invocations, outputs, and affected resources as a replayable trace bound to users, sessions, and data sources. The requirement is not limited to the operational phase and applies from initial deployment through real-time inference.

What OWASP Agentic AI categories apply directly to MCP server deployments?

ASI02 (Tool Misuse and Exploitation), ASI03 (Identity and Privilege Abuse), and ASI04 (Agentic Supply Chain Vulnerabilities) are the three primary categories per the OWASP Agentic Applications 2026 standard. ASI02 covers unsafe tool use and compromised server redirects. ASI03 covers over-permissioned agents that operate with broader access than their task requires. ASI04 covers risks from third-party MCP servers and registries admitted to the agent workflow.

Does Prediction Guard store SIEM credentials or audit logs?

No. Prediction Guard generates structured audit log output and formats it natively for your SIEM or observability platform (Splunk, Datadog, Grafana, or generic syslog). Storage, retention, and search are handled entirely by your SIEM or observability platform under your own controls. Prediction Guard does not hold HEC tokens, API keys, or endpoint credentials of any kind.

How often should MCP server permission scopes be reviewed?

At minimum, run quarterly reviews against the registered baseline, and re-verify cryptographic signatures and permission scopes whenever a vendor ships a new server version before admitting the update to your environment. Schedule SIEM or Grafana queries that compare active tool permission scopes against the registered baseline on at least a quarterly cadence, with automated delivery of results to your compliance lead on a fixed schedule. Conduct a full AIBOM export and cross-framework review on a recurring schedule that gives your compliance team sufficient lead time to address any gaps before a regulatory examination, with the specific cadence determined by your legal team based on your applicable framework obligations.

What authentication standard applies to remote MCP server deployments?

OAuth 2.1 with PKCE is the baseline standard for remote MCP deployments, per the CSA's MCP authorization analysis. Access tokens should be short-lived and scoped to reduce blast radius in the event of a compromise. Static API keys alone do not meet this baseline.

Key terms glossary

AIBOM (AI Bill of Materials): A machine-readable inventory of every AI component in an environment, including models and MCP servers, exported in CycloneDX format as the byproduct of AI System registration in a governed control plane.

ASI02 (Tool Misuse and Exploitation): An OWASP Agentic AI Top 10 (2026) risk category covering scenarios where agents misuse legitimate tools due to prompt injection, misalignment, or unsafe delegation, including tool output manipulation and workflow hijacking.

ASI03 (Identity and Privilege Abuse): An OWASP Agentic AI Top 10 (2026) risk category covering scenarios where agents operate with broader permissions than their task requires, enabling access escalation through manipulation of delegation chains and role inheritance.

ASI04 (Agentic Supply Chain Vulnerabilities): An OWASP Agentic AI Top 10 (2026) risk category covering risks introduced through third-party MCP servers, plugins, model registries, or update channels that are malicious, compromised, or tampered with in transit.

AIUC-1: A voluntary AI agent standard comprising six pillars (Security, Safety, Reliability, Accountability, Data and Privacy, and Society) with crosswalks to NIST AI RMF, OWASP, EU AI Act, ISO/IEC 42001, and regional U.S. regulation, maintained at aiuc-1.com.

CycloneDX: An open standard for software, hardware, and AI bill of materials in machine-readable format, used to export AIBOM records from AI System registries for procurement and compliance review.

MCP (Model Context Protocol): A protocol that enables AI agents to connect to databases, local files, APIs, and external services through registered server integrations, granting agents direct tool execution capability.

NIST AI RMF (AI Risk Management Framework): A voluntary standard organized across four functions (Govern, Map, Measure, and Manage) providing a structured approach to identifying, assessing, and managing AI risk across the system lifecycle.

Runtime policy enforcement: Active evaluation of every AI model call and tool invocation against a defined governance policy before the call completes, with the audit log serving as evidence of that enforcement rather than the enforcement mechanism itself.

Sovereign AI control plane: A self-hosted governance infrastructure deployed inside the customer's own environment (on-premises, cloud VPC, or air-gapped) where governance logic, enforcement decisions, and audit logs remain within the customer's trust boundary.