Your team just got asked to support AI agents that use Model Context Protocol (MCP). You've got hundreds of existing APIs. Now what?
This guide walks through the technical decisions you'll face when integrating MCP alongside your current API infrastructure, focusing on access control, governance, and compliance requirements.
Scope - What This Guide Covers
This guide addresses:
- How MCP differs from REST APIs in authentication and authorization patterns
- Where APIs remain the better choice for controlled data access
- Governance structures needed to manage MCP integrations safely
- Compliance mapping for SOC 2 Type II and ISO 27001
What this guide doesn't cover:
- LLM prompt injection defenses (separate topic)
- General API security hardening
- MCP server implementation details
Key Concepts and Definitions
Model Context Protocol (MCP): A standard that lets AI agents discover and use tools dynamically without documentation. The agent queries available resources and tools at runtime.
Dynamic discovery: Unlike REST APIs where you document endpoints in OpenAPI specs, MCP servers advertise their capabilities when the agent connects. The agent decides what to call based on its task.
MCP Gateway: A control layer between AI agents and your backend systems. Functions like an API gateway but handles MCP-specific concerns like retry storms and context leakage.
Deterministic vs. non-deterministic access: REST APIs follow predictable request patterns. AI agents using MCP make unpredictable sequences of calls based on their reasoning process.
Requirements Breakdown
Access Control Requirements
ISO/IEC 27001:2022, Control 5.15 (Access Control)
Your existing APIs likely implement role-based access control. MCP adds complexity because the agent, not a human user, decides what resources to access.
Implementation approach:
- Maintain authentication at the agent level (which agent is making requests)
- Add authorization at the resource level (what data can this agent access)
- Don't rely on the agent to self-limit based on instructions
SOC 2 Type II, CC6.1 (Logical Access)
You need audit trails showing which agent accessed what data and why. MCP's dynamic discovery makes this harder than traditional API logging.
Required logging fields:
- Agent identifier
- Requested resource or tool
- Context that triggered the request
- Data returned
- Whether the access violated policy (even if blocked)
Data Classification Requirements
ISO/IEC 27001:2022, Control 5.12 (Classification of Information)
AI agents have been shown to overcall endpoints, retrieve sensitive data, or retry APIs until they accidentally break something. Your data classification strategy must account for this.
Decision matrix for exposure method:
| Data Classification | Expose via MCP? | Expose via API? | Rationale |
|---|---|---|---|
| Public | Yes | Yes | Low risk |
| Internal | Yes, with gateway | Yes | Requires access control either way |
| Confidential | No | Yes, with strict RBAC | MCP's dynamic discovery increases leak risk |
| Restricted/PII | No | Yes, with tokenization | Requires deterministic access patterns |
Implementation Guidance
When to Use APIs Instead of MCP
Keep using traditional APIs when you need:
Precise rate limiting: An agent might retry an endpoint repeatedly while reasoning through a task. APIs let you set exact per-endpoint limits tied to business logic.
Compliance audit requirements: If you need to demonstrate that a specific user action triggered a specific data access (PCI DSS v4.0.1 Requirement 10.2.2), deterministic API calls provide clearer audit trails than agent-driven MCP requests.
Sensitive data access: For PII or payment data, you want the application logic to control exactly what gets retrieved. Don't let the agent discover that a /customers/:id/payment-methods resource exists.
When MCP Makes Sense
Use MCP for:
Tool execution: Let agents discover and use internal tools (code formatters, test runners, deployment checks) without maintaining separate integrations for each AI platform.
Read-only operational data: Metrics, logs, system status - data where overcalling doesn't create compliance risk.
Sandboxed environments: Development and staging systems where you're testing agent capabilities.
Implementing an MCP Gateway
An MCP Gateway sits between your agents and MCP servers. Core functions:
Request validation: Check that the agent's requested tool or resource matches its authorized scope. Block discovery of resources the agent shouldn't know exist.
Rate limiting: Apply per-agent, per-resource limits. MCP servers don't enforce this themselves.
Context filtering: Strip sensitive context from agent requests before they reach your systems. An agent debugging a customer issue doesn't need the customer's payment token in its context.
Audit logging: Capture the full request chain - what the agent asked for, what context it provided, what your systems returned.
Example policy rule:
Agent: customer-support-bot
Allowed MCP servers: customer-data, order-history
Blocked resources: payment-methods, internal-notes
Max requests per minute: 50
Context filtering: remove fields matching /token|key|secret/
Common Pitfalls
Pitfall: Treating MCP like another API
You can't just wrap your REST API in an MCP server and call it done. Agents will call endpoints in sequences you didn't anticipate.
Fix: Design MCP resources around agent tasks, not your database schema. Create composite resources that return exactly what an agent needs for a specific job.
Pitfall: No resource-level authorization
Authenticating the agent isn't enough. The agent will discover and attempt to use every resource the MCP server advertises.
Fix: Implement authorization checks inside each MCP tool. Just because an agent can call the tool doesn't mean it should access all data that tool can reach.
Pitfall: Assuming agents will follow instructions
You can't rely on prompt engineering to prevent an agent from accessing sensitive data if the MCP server exposes it.
Fix: Don't advertise sensitive resources to agents that shouldn't access them. Control this at the MCP Gateway, not in the agent's instructions.
Pitfall: Inadequate logging for compliance
Standard API logs don't capture why an agent made a request or what context influenced its decision.
Fix: Log the agent's stated goal, the full context it provided, and the reasoning chain if available. You'll need this for SOC 2 Type II access reviews.
Quick Reference Table
| Question | API | MCP | Both |
|---|---|---|---|
| Need deterministic access patterns? | ✓ | ||
| PCI DSS or HIPAA data involved? | ✓ | ||
| Agent discovering capabilities at runtime? | ✓ | ||
| Rate limiting per business operation? | ✓ | ||
| Read-only operational data? | ✓ | ||
| Need detailed compliance audit trail? | ✓ | ||
| Internal tool execution? | ✓ | ||
| Customer-facing production system? | ✓ | ✓ (with gateway) | |
| Development/staging environment? | ✓ |
Your existing APIs aren't obsolete. They're your control layer for sensitive data access. Use MCP where its dynamic discovery adds value, and keep using APIs where you need predictable, auditable access patterns. The key is knowing which tool solves which problem.
