Notifications
Clear all
Topic starter
20/08/2026 5:26 pm
TL;DR: MCP adoption is moving into funded enterprise programmes while only 11% of organisations report production use, and Obot’s analysis argues that the largest exposure sits in pre-production systems where authorization, logging, and runtime guardrails are still being defined. The security question is no longer whether MCP needs a framework, but whether teams can govern model-to-tool trust before exposed servers and shadow deployments create open paths into downstream systems.
NHIMG editorial — based on content published by Obot: MCP Security Is No Longer a Thought Experiment
By the numbers:
- Half of organizations are actively experimenting with MCP servers, but only 11% have reached production, creating a 39-point governance gap.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: What breaks when an MCP server is compromised?
A: When an MCP server is compromised, the agent may still trust its response as if it were internal policy or approved guidance.
Q: Why do conversational AI systems create new identity and access risks?
A: Because they can combine data retrieval, decision-making, and execution in a single interaction.
Q: How should security teams contain prompt injection in agentic systems?
A: Containment should start with delegated identity, not prompt wording.
Practitioner guidance
- Inventory every MCP endpoint and gateway Build a live register of all MCP servers, clients, and exposed HTTP endpoints, then classify each one by authentication state, tool scope, and downstream reach.
- Enforce policy at the gateway layer Move authentication, authorization checks, tool inventory control, and audit logging into a centralized gateway or client-layer control plane.
- Sanitize context before model execution Scan tool metadata, parameter fields, returned files, and retrieved content for hidden instructions before the model consumes them.
What's in the full article
Obot's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step MCP gateway design patterns for authentication, authorization, and audit logging
- Practical examples of tool-level scope design for agents that need database, SaaS, and internal service access
- Detailed breakdowns of the six attack vectors with mechanics and defensive checkpoints
- Implementation guidance for centralized governance without slowing developer workflows
👉 Read Obot's analysis of MCP security risks and defence layers →
MCP security is no longer theoretical for IAM and SOC teams?
Explore further
20/08/2026 6:15 pm
MCP security is really identity and authorization governance for AI toolchains. The protocol matters because it gives models the ability to act through tools, not just generate text. That makes the trust boundary about who or what can invoke which action, under what context, and with what audit trail. For IAM and PAM teams, MCP should be treated as a new class of privileged access surface, not a simple integration layer.
A question worth separating out:
Q: Who is accountable when a compromised AI agent misuses delegated access?
A: Accountability usually spans the business owner of the workflow, the team that issued or approved the credential, and the vendor if a third-party integration was involved. The critical governance question is not who logged in, but who allowed the delegation chain to exist and remain valid. That chain must be documented before incidents occur.
👉 Read our full editorial: MCP security is closing fast on the enterprise risk window
