MCP Security
MCP Security: a developer's guide
Last updated: June 2026
Engineers are connecting AI to internal tools at a speed that’s outpacing governance best practices. Claude connects to GitHub, Notion, Snowflake, Slack, and dozens of other services through MCP servers. Agents run in CI pipelines, query production databases, and file tickets on behalf of human users. The question isn't whether to allow it; it’s how to put the right controls in place without creating so much friction that people route around them.
There are several ways to approach this problem. Some teams use endpoint protection and outbound filtering to restrict what AI tools can connect to at the network level. Some rely on platform-native controls in Claude Desktop and Claude Code. Some deploy DLP tooling. Each has genuine tradeoffs: some are too intrusive to survive contact with engineering teams, some don't cover cloud-hosted agents at all, and some address data exfiltration without giving you any visibility into what actions AI is taking.
This guide covers the approach we built and deployed for our own team: a proxy-layer MCP gateway that sits between your AI clients and the upstream servers, enforcing tool-level access controls, logging every tool call, and managing credentials centrally. It's not the only answer, but it's the one we can explain with working code. Where relevant, we cover why we chose this over the alternatives.
What the guide covers
Chapter | What it covers |
|---|---|
The broader challenge of governing AI and agent usage across a team, why the alternatives fall short for different reasons, and why an MCP gateway is where we started | |
How to define role-based grants for specific tools on specific servers, enforced at the proxy layer so restricted tools are structurally unavailable, not just hidden from the client's view | |
What to record, how to store it securely, and how to structure audit data so it's queryable when you actually need it: before an incident, not during one | |
Bearer tokens, OAuth, custom headers, shared and personal credentials, and how to manage the full token lifecycle across a team without creating the credential sprawl you started trying to avoid | |
Why production agents need their own identity rather than borrowing a human's, and how to provision scoped credentials so their tool calls appear in the audit log as agent calls | |
From individual setup to org-wide deployment: server registry, role-based grants, MDM configuration, and the multiplayer advantage of a shared gateway | |
How tool poisoning and confused deputy attacks work in an MCP context, and how the access controls in this guide limit the blast radius when something goes wrong |
Related resources
For regulated industries: The security layer this guide covers sits on top of your HIPAA compliance obligations, not in place of them. If your team is building with PHI, see HIPAA AI security for the regulated industry framing.
For LLM API governance: If you're managing both LLM API access and MCP tool access, Aptible AI Gateway covers the LLM side: logging every prompt and response, scoped keys, BAA coverage, and cost controls. This guide covers the MCP side; both are designed to work together.
MCP Security: a developer's guide
Last updated: June 2026
Engineers are connecting AI to internal tools at a speed that’s outpacing governance best practices. Claude connects to GitHub, Notion, Snowflake, Slack, and dozens of other services through MCP servers. Agents run in CI pipelines, query production databases, and file tickets on behalf of human users. The question isn't whether to allow it; it’s how to put the right controls in place without creating so much friction that people route around them.
There are several ways to approach this problem. Some teams use endpoint protection and outbound filtering to restrict what AI tools can connect to at the network level. Some rely on platform-native controls in Claude Desktop and Claude Code. Some deploy DLP tooling. Each has genuine tradeoffs: some are too intrusive to survive contact with engineering teams, some don't cover cloud-hosted agents at all, and some address data exfiltration without giving you any visibility into what actions AI is taking.
This guide covers the approach we built and deployed for our own team: a proxy-layer MCP gateway that sits between your AI clients and the upstream servers, enforcing tool-level access controls, logging every tool call, and managing credentials centrally. It's not the only answer, but it's the one we can explain with working code. Where relevant, we cover why we chose this over the alternatives.
What the guide covers
Chapter | What it covers |
|---|---|
The broader challenge of governing AI and agent usage across a team, why the alternatives fall short for different reasons, and why an MCP gateway is where we started | |
How to define role-based grants for specific tools on specific servers, enforced at the proxy layer so restricted tools are structurally unavailable, not just hidden from the client's view | |
What to record, how to store it securely, and how to structure audit data so it's queryable when you actually need it: before an incident, not during one | |
Bearer tokens, OAuth, custom headers, shared and personal credentials, and how to manage the full token lifecycle across a team without creating the credential sprawl you started trying to avoid | |
Why production agents need their own identity rather than borrowing a human's, and how to provision scoped credentials so their tool calls appear in the audit log as agent calls | |
From individual setup to org-wide deployment: server registry, role-based grants, MDM configuration, and the multiplayer advantage of a shared gateway | |
How tool poisoning and confused deputy attacks work in an MCP context, and how the access controls in this guide limit the blast radius when something goes wrong |
Related resources
For regulated industries: The security layer this guide covers sits on top of your HIPAA compliance obligations, not in place of them. If your team is building with PHI, see HIPAA AI security for the regulated industry framing.
For LLM API governance: If you're managing both LLM API access and MCP tool access, Aptible AI Gateway covers the LLM side: logging every prompt and response, scoped keys, BAA coverage, and cost controls. This guide covers the MCP side; both are designed to work together.
MCP Security: a developer's guide
Last updated: June 2026
Engineers are connecting AI to internal tools at a speed that’s outpacing governance best practices. Claude connects to GitHub, Notion, Snowflake, Slack, and dozens of other services through MCP servers. Agents run in CI pipelines, query production databases, and file tickets on behalf of human users. The question isn't whether to allow it; it’s how to put the right controls in place without creating so much friction that people route around them.
There are several ways to approach this problem. Some teams use endpoint protection and outbound filtering to restrict what AI tools can connect to at the network level. Some rely on platform-native controls in Claude Desktop and Claude Code. Some deploy DLP tooling. Each has genuine tradeoffs: some are too intrusive to survive contact with engineering teams, some don't cover cloud-hosted agents at all, and some address data exfiltration without giving you any visibility into what actions AI is taking.
This guide covers the approach we built and deployed for our own team: a proxy-layer MCP gateway that sits between your AI clients and the upstream servers, enforcing tool-level access controls, logging every tool call, and managing credentials centrally. It's not the only answer, but it's the one we can explain with working code. Where relevant, we cover why we chose this over the alternatives.
What the guide covers
Chapter | What it covers |
|---|---|
The broader challenge of governing AI and agent usage across a team, why the alternatives fall short for different reasons, and why an MCP gateway is where we started | |
How to define role-based grants for specific tools on specific servers, enforced at the proxy layer so restricted tools are structurally unavailable, not just hidden from the client's view | |
What to record, how to store it securely, and how to structure audit data so it's queryable when you actually need it: before an incident, not during one | |
Bearer tokens, OAuth, custom headers, shared and personal credentials, and how to manage the full token lifecycle across a team without creating the credential sprawl you started trying to avoid | |
Why production agents need their own identity rather than borrowing a human's, and how to provision scoped credentials so their tool calls appear in the audit log as agent calls | |
From individual setup to org-wide deployment: server registry, role-based grants, MDM configuration, and the multiplayer advantage of a shared gateway | |
How tool poisoning and confused deputy attacks work in an MCP context, and how the access controls in this guide limit the blast radius when something goes wrong |
Related resources
For regulated industries: The security layer this guide covers sits on top of your HIPAA compliance obligations, not in place of them. If your team is building with PHI, see HIPAA AI security for the regulated industry framing.
For LLM API governance: If you're managing both LLM API access and MCP tool access, Aptible AI Gateway covers the LLM side: logging every prompt and response, scoped keys, BAA coverage, and cost controls. This guide covers the MCP side; both are designed to work together.
548 Market St #75826 San Francisco, CA 94104
© 2026. All rights reserved. Privacy Policy
548 Market St #75826 San Francisco, CA 94104
© 2026. All rights reserved. Privacy Policy
548 Market St #75826 San Francisco, CA 94104
© 2026. All rights reserved. Privacy Policy