Notifications
Clear all
Topic starter
08/06/2026 4:24 pm
TL;DR: MCP turns LLMs into tool-using agents, but that also creates risks from prompt injection, token leakage, overbroad permissions, unverified endpoints, and replayable sessions, according to WorkOS. The practical lesson is that security teams must treat MCP connections as identity and trust boundaries, not just integration plumbing.
NHIMG editorial — based on content published by WorkOS: The complete guide to MCP security and how to secure MCP servers and clients
Questions worth separating out
Q: How should security teams govern MCP tool access in enterprise environments?
A: Treat each MCP tool as a discrete identity and privilege boundary, not as a generic API extension.
Q: Why do MCP deployments increase identity and access risk?
A: MCP increases risk because it connects untrusted model output to real systems that can act on it.
Q: What breaks when MCP tokens are long-lived or widely reusable?
A: Long-lived or reusable tokens turn a short exposure into persistent access.
Practitioner guidance
- Map every MCP tool to a unique access scope Assign each tool the narrowest feasible permissions and separate read from write operations so a single compromised tool cannot fan out across systems.
- Require cryptographic verification for server discovery Only allow clients to connect to servers that publish signed metadata and can be validated against an approved registry or allowlist.
- Bind tokens to the intended audience and session Use short-lived credentials, sender-constrained tokens, and strict audience claims so a token captured in one place cannot be replayed against another server.
What's in the full article
WorkOS's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step server hardening guidance for authentication, token validation, and consent enforcement.
- Client-side trust verification patterns for discovery, metadata signing, and allowlist enforcement.
- Implementation examples for sandboxing, rate limiting, and session revocation in MCP workflows.
- The article's vendor-specific mapping of controls to WorkOS components for teams already using its stack.
👉 Read WorkOS's complete guide to MCP server and client security →
MCP server and client security: what IAM teams need to tighten?
Explore further
08/06/2026 6:01 pm
MCP security is an NHI problem before it is an AI problem. Once a model can call tools, every connection becomes a non-human identity with scope, trust, and revocation implications. The article’s risks map directly to classic NHI failures: token exposure, overbroad permissions, weak endpoint trust, and poor auditability. Practitioners should stop treating MCP as a new AI feature and start treating it as a new class of machine identity integration.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- In our NHI research, 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: What should teams do when an MCP server cannot prove its identity?
A: Do not trust it. Require signed metadata, verified registries, and explicit allowlisting before any connection is accepted. If a server cannot prove provenance, it should never receive tokens or sensitive requests, because discovery without identity verification creates a direct path to rogue tool use.
👉 Read our full editorial: MCP security guidance shows why AI tool access needs tighter controls
