TL;DR: An MCP gateway removes credential sprawl, unscoped tokens, and audit blind spots by centralizing credential storage with AES-256 encryption, enforcing policy-as-code in the request path before model interaction, and logging every tool call including denied actions. It cannot remove prompt injection in content, malicious server logic, third-party MCP supply chain compromise, or local endpoint misconfiguration. Those remain application-layer responsibilities. Security reviewers should demand architecture diagrams, SOC 2 Type II and ISO/IEC 27001:2022 certification evidence, and documented credential isolation before approving any gateway vendor.
Security reviewers and IT leaders approving MCP rollouts face a recurring problem: gateway vendors describe their products as handling security, but a threat model assigns some risks to the gateway and others to the application layer. Approving a gateway without knowing which is which leaves gaps that surface during audits or incidents.
The Model Context Protocol lets AI agents call external tools through servers that often hold OAuth tokens, database credentials, or cloud access. The MCP specification states that the protocol "cannot enforce these security principles at the protocol level," which means every security decision falls to the implementation team unless a gateway absorbs some of that burden.
For IT leaders and engineering teams assessing MCP infrastructure, this article maps each security risk to its remediation owner: the gateway's infrastructure layer or the application layer. This article assigns control ownership without overstating what a gateway can do.
Mapping MCP risks to infrastructure defense
Where governance ends and apps begin
The boundary between what a gateway controls and what your team controls is not arbitrary. It is architectural. A gateway sits in the request path between the agent and the MCP server. It sees the tool call, the identity making the call, and the action being requested. It does not see the content the model processes, the internal logic of the MCP server, or the configuration of local endpoints.
NIST SP 800-37 Rev. 2 defines control inheritance as receiving protection from security controls implemented and managed by another entity. The same distinction applies directly to MCP gateways: a gateway can provide credential management, policy enforcement, and audit logging, while your team remains responsible for application content, server logic, and local configuration.
This boundary matters because misallocating controls creates audit findings. If your threat model assumes the gateway handles prompt injection, and it does not, the gap surfaces during a penetration test or an incident review.
Gateway vs. application security boundaries
A prompt instruction telling your agent “do not delete records” is a sign on a door. Policy-as-code is the lock. A sufficiently creative input bends the prompt, but the policy does not bend because it is evaluated in the request path before execution. Composio applies this model by evaluating each action against admin-defined policy before the call reaches the MCP server.
The gateway enforces controls at the infrastructure layer: it checks whether this identity may perform this action on this tool, evaluates any data-masking rules, and either permits, masks, or blocks the call. Application-layer controls address what happens inside the model's reasoning and inside the server's execution: prompt injection, output manipulation, and business logic vulnerabilities.
The OWASP MCP Security Cheat Sheet identifies confused deputy attacks, supply chain compromise, and prompt injection as distinct risk categories that MCP introduces. A gateway addresses some of these directly. Others it cannot touch.
Why realistic security modeling matters
Overstating gateway coverage costs more than understating it. When a security team allocates controls to the wrong layer, the gap does not surface until an audit or an incident. By then, remediation is reactive and expensive.
Risk management frameworks like NIST RMF treat documented control ownership as good practice, separating controls inherited from infrastructure providers from system-specific responsibilities. Applying this to MCP deployments means documenting which risks the gateway absorbs and which your team must address with application-layer controls. Without that documentation, your next audit cycle will find the gap before you do.
How gateways mitigate specific MCP exposures
Securing non-human identity secrets
Credentials scattered across developer environments, CI/CD secrets, and configuration files leave security teams with no single place to enumerate, rotate, or revoke them. Composio centralizes connected-account credentials, auth configurations, and API keys in a single vault with AES-256-GCM encryption at rest and TLS in transit.
This architecture directly addresses the non-human identity governance gap that CISOs flag as a top concern. Instead of tracking tokens across dozens of environments, you have one governed location with a queryable inventory.
Risks of excessive permission scopes
In practice, OAuth tokens can carry broader permissions than an agent actually needs. For example, a token with read-write access to Salesforce might be issued because it is easier to configure, allowing the agent to modify records it was only supposed to read.
An over-scoped token lets an agent do anything the token permits, and a prompt instruction cannot reliably restrict that access. Policy-as-code in the request path closes the gap. An admin configures which actions are permitted for authorized users or roles, and when the agent attempts a tool call, Composio evaluates the requested action against the policy before any model interaction occurs. If the policy disables delete operations for a Slack integration, the agent cannot delete regardless of what the prompt contains or what the model reasons.
This is structurally different from prompt-based guardrails, which rely on the model's interpretation of the prompt instruction. Gateway-side authorization can check the requested action against configured policies independently of the model's instructions.
Addressing visibility blind spots
Without a gateway, audit trails fragment across individual integrations. Each MCP server logs differently, if at all, and denied calls often go unrecorded entirely. When your security team needs to reconstruct what a specific agent did across 15 integrations last Tuesday, the evidence may not exist.
Fragmented logs mean a denied call or a cross-integration sequence of actions can disappear from the record, leaving security teams without a complete chain of custody. NIST SP 800-92 provides guidance for developing and maintaining enterprise log-management processes and infrastructure, and centralizing logs is the step that makes that guidance practical across MCP integrations. Composio centralizes audit logging across tool calls through its gateway, logging user, team, tool, action, and outcome for every call, including denied actions. This creates a complete chain of custody rather than a partial activity summary.
The practical outcome: when an auditor asks who accessed what through your MCP deployment, you produce a queryable chain of custody rather than a manual reconstruction.
Defending against deputy attacks
A confused deputy attack occurs when an agent is tricked into performing an action outside its intended permission scope. The OWASP MCP Security Cheat Sheet identifies this as a core MCP risk: the server executes actions with its own privileges rather than the requesting user's permissions.
Composio prevents unauthorized tool execution by evaluating policy in the request path before execution, not after. If a prompt injection attempt tries to escalate the agent’s privileges, the gateway blocks the call because the policy does not permit that action for that identity. The enforcement point is the gateway, not the model’s interpretation of the prompt.
This is where the architectural distinction between gateway and prompt-based controls becomes concrete. A prompt filter reduces surface area but does not prevent over-permissioned access. The gateway's policy engine does.
Build vs. buy: Engineering time as the real cost
Approach | Initial implementation effort | Ongoing maintenance | Security controls included | Total cost of ownership |
|---|---|---|---|---|
In-house gateway logic | Varies by integration and OAuth requirements | Ongoing engineering ownership | Credential storage, policy enforcement, and logging must be implemented and maintained | Engineering time + infrastructure and maintenance |
Composio MCP Gateway | Configuration depends on integration requirements | Managed integration infrastructure | AES-256 encryption, policy-as-code, centralized audit logs, SOC 2 Type II + ISO 27001 certified | Platform fees + integration configuration |
Building OAuth integrations in-house requires engineering time for credential storage, token refresh, API changes, and ongoing maintenance. Composio's authentication documentation explains how the platform stores and refreshes connected-account tokens, reducing the authentication infrastructure teams need to maintain themselves.
Beyond the gateway: Risks you must mitigate
Mitigating prompt injection at runtime
Prompt injection is listed as LLM01:2025 in the OWASP Top 10 for LLM Applications. It occurs when user inputs or untrusted data sources manipulate how an LLM interprets or responds to prompts.
A gateway cannot inspect or sanitize all content flowing through the model. Your application layer must handle input sanitization, schema validation, and output filtering. The gateway ensures the agent cannot exceed its permissions even if an injection succeeds, but it does not prevent the injection from altering the model's behavior within those permissions.
Managing server logic security gaps
The gateway proxies requests to MCP servers but does not validate the server's internal behavior. The MCP tools specification allows servers to expose tools that invoke external systems and requires clients to treat tool annotations as untrusted unless they come from trusted servers. A vulnerable or malicious MCP server can return crafted responses designed to manipulate the agent, exfiltrate data through side channels, or exploit the agent's trust in tool outputs. Application-layer responsibilities include server code review, dependency scanning, and runtime monitoring of MCP server behavior.
Mitigating third-party MCP supply chain risk
A malicious MCP server package or a compromised upstream dependency introduces risk that no gateway can detect. Supply chain risk requires vendor assessment, software bill of materials (SBOM) review, and continuous monitoring of the MCP servers your agents connect to.
For security and IT leaders already managing third-party risk assessment across a growing vendor roster, MCP servers represent a new category of supply chain exposure that requires the same rigor as any other software dependency.
Securing local MCP endpoint settings
Locally deployed MCP servers introduce configuration risk that a gateway does not govern. Misconfigured local servers, exposed endpoints, or overly permissive network access create entry points that bypass the gateway entirely if they are not properly segmented.
Application-layer responsibilities include endpoint hardening, network segmentation to isolate MCP servers from sensitive systems, and configuration management to prevent drift. If your deployment includes local MCP servers alongside cloud-hosted ones, the gateway secures the calls it proxies. The local configuration remains your team's responsibility.
Categorizing MCP threats by remediation owner
The table below maps each MCP security risk to its remediation owner, the control that addresses it, and the evidence you should demand.
Risk category | Remediation owner | Control mechanism | Evidence required |
|---|---|---|---|
Credential sprawl | Gateway | Centralized vault, AES-256 encryption | Architecture diagram, encryption standard documentation |
Excessive scopes | Gateway | Policy-as-code, request-path enforcement | Policy engine documentation, denied call logs |
Audit blind spots | Gateway | Centralized logging, denied call capture | Log sample, SIEM integration docs |
Confused deputy | Gateway | Identity-scoped permissions, pre-execution evaluation | Policy evaluation flow diagram |
Prompt injection | Application | Input sanitization, schema validation | Application-layer security testing results |
Malicious server logic | Application | Code review, dependency scanning | SBOM, code audit reports |
Supply chain compromise | Application | Vendor assessment, continuous monitoring | Third-party risk assessment documentation |
Local endpoint misconfiguration | Application | Endpoint hardening, network segmentation | Configuration management policy, network architecture diagram |
Preventing unauthorized MCP tool execution at the gateway layer
At the gateway layer, policy-as-code enforcement evaluates every tool call against admin-defined permissions before the request reaches the MCP server. Denied calls are logged with the same fidelity as permitted ones, which means your audit trail captures both what happened and what was attempted.
Preventing unauthorized tool execution in the application layer
Application-layer unauthorized execution results from prompt injection that manipulates the agent into attempting actions it should not. Composio blocks calls that exceed configured permissions, but preventing the injection attempt itself requires application-layer input validation and output filtering controls under OWASP LLM01.
Constraining non-human identity access
Non-human identities (OAuth tokens, API keys, service accounts) accumulate faster than most security teams can inventory them. A gateway enforces least privilege by scoping each connected account to the minimum permissions required for its operational function.
Composio lets administrators configure permitted actions per user or role. The agent cannot self-escalate because policy evaluation happens in the request path, not in the model's reasoning. This is the infrastructure-layer enforcement that distinguishes a gateway from a prompt-based guardrail.
Redefining your threat surface with MCP gateways
Centralizing MCP security controls
Centralization reduces attack surface by consolidating what was previously scattered. Without a gateway, credentials live in developer environments, CI/CD secrets, and configuration files across multiple systems. Policies exist as prompt instructions, which are inconsistent by nature. Audit trails fragment across individual integrations.
With a gateway, one location governs credentials, one engine evaluates policies, and one log records every action. The Composio MCP Gateway provides this centralization across 1,500+ app connectors, which means adding a new integration does not multiply your security review surface.
The trade-off is documented control versus distributed credential management. Centralization introduces a dependency on the gateway vendor's availability, which is why redundancy and failover mechanisms matter.
Automated controls for MCP security
Policy-as-code replaces manual access reviews with automated enforcement. Rather than quarterly access reviews that rely on human judgment, the gateway evaluates every call against the current policy in real time.
Manual access reviews rely on human judgment and lag behind real-time changes, so a permission that should be gone can stay usable until the next review cycle. Composio evaluates every tool call in the request path, which means policy changes take effect immediately. When an admin revokes an action permission, the next tool call that attempts that action is denied and logged. No deployment cycle, no configuration drift, no reliance on the model to comply.
This is the difference between a control that is documented and a control that is enforced. For CISOs preparing for audits, the distinction matters because auditors evaluate enforcement evidence, not policy documents.
Framework control mappings for audit documentation
MCP security risk | NIST RMF control family | SOC 2 Type II criterion | Composio control |
|---|---|---|---|
Credential sprawl | IA-5 Authenticator Management | CC6.1 Logical and physical access controls | Centralized vault with AES-256-GCM encryption |
Excessive scopes | AC-6 Least Privilege | CC6.3 Removal of access | Policy-as-code evaluated in request path |
Audit blind spots | AU-2 Event Logging | CC7.2 System monitoring | Centralized logging including denied calls |
Confused deputy | AC-3 Access Enforcement | CC6.1 Logical and physical access controls | Pre-execution policy evaluation per identity |
NIST RMF control inheritance divides responsibility between the infrastructure provider and the system owner. Composio inherits IA-5, AC-6, AU-2, and AC-3 controls at the gateway layer, which reduces your team's documentation burden during NIST 800-53. The SOC 2 Type II report maps these same controls to the Trust Services Criteria, so a single architecture review satisfies multiple framework requirements.
How to verify vendor security promises for MCP
Documenting credential isolation layers
Ask the vendor directly: where are credentials stored, who can access them, and are they isolated from LLM context and application code? The answer should reference a specific architecture, not a marketing claim.
Composio's architecture stores credentials with AES-256-GCM encryption and isolates them from both the LLM context and your application code. The credential is decrypted inside an isolated runtime and injected into the outbound HTTP request. Provider credentials are isolated from the LLM context and application code when Composio handles the execution. Composio documents encrypted storage and default redaction of connected-account tokens in API responses.
If a vendor cannot produce an architecture diagram showing this isolation, that is your answer.
Evidence for vendor risk assessment
SOC 2 Type II evaluates controls across the five Trust Services Criteria over a defined observation period. ISO/IEC 27001:2022 certifies the information security management system.
Composio holds both certifications, with documentation available at the Composio trust center. Pre-filled compliance packs cover common frameworks, which means your vendor risk assessment starts with structured evidence rather than a questionnaire waiting for responses.
Defining mandatory MCP security gates
Before production deployment, enforce four security gates:
Architecture: Request a diagram showing credential storage, isolation boundaries, and policy enforcement points.
Certifications: Verify SOC 2 Type II and ISO/IEC 27001:2022 evidence in the vendor's trust center, including the scope of the reports.
Proof of concept: Test credential isolation, policy enforcement, and denied-call handling against defined exit criteria in your environment.
Audit evidence: Request a log sample showing user, team, tool, action, and outcome, including denied calls.
Book a call to walk through your security requirements before the next enterprise review.
FAQs
Does an MCP gateway eliminate all credential risk?
No. A gateway centralizes credential storage and isolates tokens from LLM context with AES-256 encryption, but application-layer risks such as prompt injection and malicious server logic remain your team's responsibility.
Can a gateway prevent prompt injection attacks?
No. Prompt injection operates in content the gateway does not inspect. Application-layer input sanitization and schema validation are required to address OWASP LLM01.
What MCP security risks require application-layer controls?
Prompt injection, malicious server logic, third-party supply chain compromise, and local endpoint misconfiguration all require application-layer controls that a gateway cannot provide.
How do I validate gateway security claims during procurement?
Request architecture diagrams showing credential isolation, verify SOC 2 Type II and ISO/IEC 27001:2022 certifications against the vendor's trust center, and run a structured POC with defined exit criteria that tests policy enforcement and audit log completeness.
Key terms glossary
MCP gateway: Infrastructure layer that proxies agent tool calls, enforcing policy and managing credentials before requests reach MCP servers.
Policy-as-code: Access restrictions defined administratively and evaluated in the request path as code, not by the model's interpretation of prompt instructions.
Credential isolation: Architecture where tokens are stored separately from LLM context and application code, typically with AES-256 encryption, so the credential never reaches the model or the application layer.
Confused deputy attack: When an agent is tricked into performing an action outside its permission scope through prompt manipulation or crafted inputs.
Non-human identity: Machine credentials such as OAuth tokens, API keys, and service accounts used by agents and integrations, distinct from human user accounts.
Get started
