MCP security best practices: A production checklist

TL;DR: Securing MCP deployments in production requires moving beyond basic API key management. The core requirements are enforcing action-level RBAC so agents can read but not delete records, managing token custody through VPC or on-prem deployment to reduce blast radius, and maintaining verifiable audit logs mapped to human identities for NIST AI RMF and ISO 42001 compliance. A centralized MCP gateway meets all three requirements by enforcing policy-as-code at the request path, managing token custody within your network boundary, and generating a structured, queryable audit log per tool call. Individual MCP servers require each team to rebuild these controls independently, without a shared control plane.

When an AI agent connects to your CRM, it doesn't just read data. It can delete records, reassign accounts, and trigger outbound communications. If you treat agent credentials like standard API keys, a single misconfigured scope or prompt-injection attack can cause a data exposure incident that takes weeks to reconstruct from incomplete logs.

Shadow AI is already driving real incidents. IBM's Cost of a Data Breach Report directly links shadow AI (unsanctioned AI tools operating outside IT visibility) to higher breach costs and longer incident response timelines, a pattern that applies directly to unmanaged AI agent deployments. The governance gap is real and measurable.

This guide gives IT and security leads a production-ready framework for Model Context Protocol (MCP) deployments, covering auth, RBAC, data handling, and deployment models.

Why production readiness secures MCP deployments

Most MCP security conversations focus on the protocol itself. The real exposure is in the credential management, access control, and audit logging that the protocol leaves to implementers.

Solving the token custody challenge

MCP's HTTP transport uses OAuth 2.1 for authentication, but the specification makes authorization optional and does not formally define tool-level scopes in the base standard (a proposal to formalise this, SEP-1880, was raised and closed as not planned in November 2025). You must decide independently how to handle credential storage, token rotation, and expiry across every connected application, and that decision compounds with every new tool you add.

In a two-middleman chain, credential risk compounds quickly. If the middle layer is breached, every downstream connection is compromised. Without a VPC or on-prem deployment, those credentials traverse public internet paths on every tool call.

The operational overhead of solving this in-house is significant: a credential rotation engine, distributed rate limiting, OAuth 2.1 state management, and circuit breakers, plus the ongoing maintenance cost as the MCP spec evolves. For most teams, that is a sustained engineering drain with no defined end state.

Standardizing AI regulatory compliance

NIST AI RMF 1.0 Govern and Map functions emphasize traceability: the ability to reconstruct the sequence of events that led to an AI-driven outcome. ISO/IEC 42001, the first international management system standard for AI, addresses maintaining records of AI system performance and decision-making, with requirements for audit logs.

If your organization operates in financial services, healthcare, or regulated cloud environments, audit-ready compliance documentation is expected today, not next quarter.

Enforcing granular access for AI agents

Centralize identity management via SSO

Shadow AI starts the moment an agent connects to a production system without an IT-approved identity provider in the path. More than 80% of workers use unapproved AI tools (per UpGuard's State of Shadow AI research), and IBM found that one in five organizations has already experienced a breach linked to unsanctioned AI.

The fix is integrating MCP access with existing identity providers (Okta, Azure Entra ID, Google Workspace via SAML 2.0 or OIDC) so that every agent session is tied to an authenticated human identity. Composio built SSO integration into the MCP Gateway so that each team gets a unique MCP endpoint authenticated through your existing IdP, with no additional credential management overhead.

Enforce least-privilege access by default

Teams make the same mistake in MCP deployments: granting blanket platform access instead of scoping permissions to specific actions. An agent that needs to read HubSpot contact records doesn't need permission to delete them. Granting access at the platform level creates an unnecessary blast radius.

The MCP Gateway enforces toolkit-level access: admins whitelist or blacklist entire toolkits per team, so a Sales agent cannot reach a Finance toolkit regardless of prompt content. For action-level enforcement within a toolkit (approving GITHUB_GET_PR and GITHUB_CREATE_COMMENT while blocking GITHUB_DELETE_REPO on the same MCP server), Policy-as-Code Enforcement sets permitted actions per user or role through the admin dashboard.

Control toolkit access with approvals

Admin-approved toolkit access prevents unauthorized tool connections before they reach production. The workflow:

1. Request: A team submits a request to connect a new toolkit (for example, Salesforce or Jira).

2. Review: The IT admin inspects the requested permission scopes and approves or rejects it per team policy.

3. Activate: Approved toolkits are added to that team's allow-list within the MCP Gateway.

4. Log: Rejected requests are logged for audit purposes.

Set recurring schedules for token updates

OAuth tokens from providers like Google, Slack, and Salesforce expire on short intervals, and agents running continuously face race conditions when multiple tool calls attempt to refresh the same token simultaneously. A managed auth layer handles background rotation, provider-specific expiration limits, and scope mismatches without breaking the agent workflow.

For production deployments, set automated token rotation cycles based on each provider's expiration windows, with automatic refresh triggered before expiry. You reduce exposure further by using short-lived session tokens scoped to a single agent run: if the session token is compromised, the blast radius is limited to that session's permissions rather than the underlying long-lived credential.

Scaling access governance for AI integrations

Structure RBAC by department and role

As agent deployments scale, permission management becomes an organizational problem, not just a technical one. The right approach maps agent permissions to the organizational structures that already exist. A practical RBAC structure by department:

This structure means a Sales agent can never accidentally call a Finance toolkit action, regardless of how the underlying LLM interprets an ambiguous prompt.

Apply granular access to MCP toolkits

Action-level RBAC is the difference between governance that satisfies compliance audits and governance that looks good in a diagram. When a compliance auditor asks "what could this agent do?", you need a specific, bounded list of tool calls, not "it had access to the Salesforce toolkit."

Policy-as-Code Enforcement lets IT admins approve or restrict individual actions within a toolkit, not just the toolkit as a whole. For Gmail (63 available methods), this means approving GMAIL_SEND_EMAIL and GMAIL_SEARCH_EMAILS while blocking GMAIL_DELETE_THREAD for a customer support agent — configured through the admin dashboard and enforced at the request path before any model interaction.

Standardize quarterly access recertification

Access recertification cycles catch overprivileged grants before they become audit findings. A practical recertification cadence:

• Quarterly: Review all active agent connections and confirm each has a named owner and active business justification.

• On role change: Revoke agent access immediately when the sponsoring human identity changes roles or departs.

• On project decommission: Trigger automated credential revocation for any agent tied to a project marked complete.

Assign clear owners for each integration

Every active MCP integration needs a named IT owner, a named business unit owner, and a documented escalation path. Without this, you get invisible failure domains: systems running in production with no defined operational owner, no update cycle, and no incident response plan.

The RACI model below establishes a recommended ownership structure across core MCP security tasks:

Establishing verifiable logs for AI activity

Maintain detailed audit logs for tools

Standard API logs capture request and response at the service boundary. They don't capture what agent identity initiated the call, what human session authorized the workflow, or what policy was in effect at the time of execution. For agentic systems, that gap makes it impossible to reconstruct incidents or produce compliance evidence on demand.

Capture request, response, and user identity

A verifiable audit trail for MCP deployments must capture the following fields per tool call:

• Session initiator: The authenticated human identity or upstream system that delegated authority.

• Agent identity and version: Which agent made the call, and which policy bundle was in effect.

• Tool invoked: The specific action called (for example, HUBSPOT_CREATE_CONTACT, not just "HubSpot").

• Input parameters: Exact inputs passed to the tool.

• Response outcome: Whether the call succeeded, failed, or was blocked by policy.

• Timestamp and duration: When the call occurred and how long it ran.

This matches the audit event structure recommended by the NIST AI RMF Playbook, which names model cards, evaluation records, and runtime monitoring logs as the specific artifacts that make traceability real.

Ensure logs are queryable and exportable

Audit logs that can't be queried or exported don't serve compliance purposes. Production deployments need real-time streaming to SIEM tools (Splunk, Datadog, or equivalent) so that security operations teams can run queries against agent activity without waiting for batch exports.

Composio provides complete audit trails for every tool call and auth event, covering what agents did, when they did it, and what triggered the action. These logs are structured for SIEM ingestion, which means audit prep is retrieval rather than reconstruction.

Reducing blast radius in custody workflows

VPC and on-prem deployment models

Cloud-managed MCP gateways offer faster deployment and lower operational overhead, but they introduce shared custody of credentials in transit. Self-hosted or VPC-deployed gateways move credential custody inside your network boundary, which addresses the most common enterprise objection: "Third-party integration layers introduce too much token custody risk."

The tradeoff is real. Self-hosted deployments typically require container orchestration infrastructure, sufficient compute resources for your expected load with auto-scaling, and encryption at rest for all stored credentials. VPC interface endpoints route agent requests through the cloud provider's internal network backbone rather than over the public internet, so credentials never traverse public paths, and VPC endpoint policies create granular access controls that limit which services can reach the gateway.

VPC deployment is available at the Enterprise tier and can address token custody concerns for organizations managing sensitive customer data or operating under strict data residency requirements: confirm current deployment scope with the Composio team before committing to a production architecture. [CONFIRM VPC/ON-PREM DELIVERY STATUS WITH CLIENT BEFORE PUBLISHING: Enterprise tier profile lists self-hosting as available, but the general company profile lists on-prem/VPC deployment under Known Product Gaps as "an active ask." These two sources disagree on current delivery status.] For platform builders where Composio sits between your product and your end-users, VPC deployment also reduces the blast radius of any potential gateway-level incident.

Hardening your token custody chain

Store credentials at rest using AES-256 encryption with keys managed by your organization's key management system, not stored alongside the credentials. Composio holds SOC 2 Type II and ISO 27001 certifications, which satisfy the most common security review requirements and are independently validated by third-party auditors.

Automate AI agent incident playbooks

When a suspicious event occurs, time-to-containment determines blast radius. An agent incident playbook should include:

1. Detect: Alert triggers on anomalous tool call volume, failed auth attempts, or off-hours activity from an agent identity.

2. Isolate: Revoke the specific agent's credentials via the gateway control plane in a single API call or console action.

3. Investigate: Export audit logs for the affected agent identity for the preceding 30-day window. Identify what tools were called, what data was accessed, and what the response payloads contained.

4. Communicate: Notify downstream systems that held trust relationships with the compromised agent identity.

5. Restore: Re-provision the agent with new credentials after root cause is confirmed and policy gaps are addressed.

Automating policy enforcement for MCP agents

Map controls to NIST AI RMF or ISO 42001

The table below maps our MCP Gateway controls to common governance requirements in AI compliance frameworks:

Automate audit evidence collection

Compliance-ready reports should be generated on demand, not assembled manually before each audit. For MCP deployments, this means structuring your gateway logs so that a query for "all tool calls made by agent identity X between date Y and date Z" returns a complete, exportable record without manual cross-referencing.

Harmonic Security research found that 16.9% of sensitive data exposures (98,034 instances) occurred on personal free-tier accounts that were completely invisible to IT. Automated evidence collection needs to cover the full scope of agent activity, not just approved enterprise connections.

KPIs for AI governance success

Governance value is genuinely hard to quantify when the goal is preventing incidents that don't happen. These metrics make the value concrete:

• Unapproved integrations detected per quarter: Measures shadow AI catch rate.

• Time-to-containment on the last agent incident: Measures incident response effectiveness.

• Outstanding access reviews older than 30 days: Measures certification backlog.

• Percentage of agent identities with named owners: Measures inventory completeness.

• Approved vs. total active toolkits per team: Measures governance coverage ratio.

Production readiness: MCP security essentials

Pre-flight security requirements

Before deploying any MCP-connected agent to production, confirm the following:

• Every agent identity is registered in the central identity provider and tied to a named human owner.

• Action-level RBAC is configured per agent role with an explicit allow-list, not a deny-list.

• Token rotation is automated with expiry windows set per provider requirements.

• Audit logging is active, streaming to your SIEM, and validated to capture tool call inputs and outputs.

• VPC or network-level isolation requirements for agents handling sensitive data are confirmed against your selected deployment tier before go-live.

• An incident response runbook exists with named responders and tested credential revocation steps.

• SOC 2 or equivalent third-party attestation is in hand from any managed gateway vendor.

Go-live verification steps

1. Run a test agent session through the gateway and confirm audit logs capture the full event chain: session initiator, agent identity, tool called, inputs, and response.

2. Attempt a tool call outside the agent's approved allow-list and confirm it is blocked and logged.

3. Simulate a token expiry event and confirm automated rotation completes without breaking the agent workflow.

4. Test the credential revocation path: revoke the test agent's credentials and confirm no further tool calls succeed.

5. Confirm log exports reach your SIEM and are queryable within the expected latency window.

Defining ongoing security review cycles

Ready to see how action-level RBAC, VPC deployment, and Zero Data Retention (ZDR) work in a live environment? Contact Composio for a demo of the admin console, audit log viewer, and RBAC configuration. For teams that want to start with the documentation first, the MCP API reference covers how to create, scope, and manage MCP server instances programmatically.

FAQs

What certifications does Composio hold?

Composio holds SOC 2 Type II and ISO 27001 certifications, with AES-256 encryption at rest, TLS in transit, and minimal log retention by default [CONFIRM TRANSIT ENCRYPTION SPEC WITH CLIENT BEFORE PUBLISHING]. These certifications cover data security, availability, and confidentiality controls across the full platform.

What are the requirements for on-premise MCP setup?

On-prem deployment requires container orchestration infrastructure, sufficient compute and memory resources with auto-scaling capabilities, VPC configuration with private subnets, and an identity provider connected via SAML 2.0 or OIDC.

What are the emergency access termination steps?

Call our API to delete the MCP server instance and all associated connected accounts in a single operation, which revokes all active tokens for that instance immediately. Follow up by notifying downstream systems that held trust relationships with the compromised agent identity and exporting the full audit log for the incident window.

What audit logs are available by default?

Composio's audit logs capture key information for each tool call, including the session initiator, agent identity, specific tool invoked, input parameters, response outcome (success, failure, or policy block), and timestamp. Composio provides logs in real-time through the admin console and supports export to common SIEM tools. Zero Data Retention (ZDR), available on Pro tier and above, stops Composio from retaining request and response payloads on our infrastructure.

Does Composio support existing IdPs like Okta or Azure Entra ID?

Yes. Composio supports SSO integration with existing identity providers via SAML 2.0 and OIDC, so every agent session is tied to an authenticated human identity in your existing directory. This prevents shadow AI deployments by requiring all agent connections to pass through the IdP-authenticated gateway rather than connecting directly with static API keys.

Key terms

Non-human identity (NHI): A credential or service account used by an automated system (like an AI agent) rather than a human user. NHIs require lifecycle management, access reviews, and revocation processes distinct from standard employee accounts.

Token custody: Which party holds and manages the credentials that grant access to external systems. In a two-middleman chain, custody risk increases because a breach at any intermediate layer exposes all downstream connections.

Blast radius: The scope of systems, data, or accounts that could be compromised if a single credential or integration is breached. VPC deployment and least-privilege scoping reduce blast radius.

Action-level RBAC: Access control that grants permissions to specific API methods (for example, HUBSPOT_GET_CONTACT) rather than entire platforms, enforcing least-privilege at the tool call level.

Audit trail: A queryable, time-stamped log of every agent action capturing who initiated the session, what tool was called, what inputs were passed, and what data was returned. NIST AI RMF and ISO 42001 require non-repudiable audit trails for AI systems.

MCP Gateway: A centralized control plane that sits between AI agents and external tools, enforcing authentication, authorization, audit logging, and token management across all connected systems. Without a gateway, each agent must implement these controls independently.