Topic starter
11/07/2026 8:42 pm
TL;DR: Natural-language access to cloud and security data only works safely when teams enforce HTTPS, OAuth 2.1, rate limiting, I/O sanitization, and strict trust boundaries for third-party MCP servers, according to JupiterOne. The deeper issue is that MCP makes AI access operationally useful before most organisations have defined who can safely use which tools, data sources, and outputs.
Editorial analysis by NHI Mgmt Group, based on content published by JupiterOne: “5 Essential Tips for Using JupiterOne MCP Server”.
Key questions
Q: Where does MCP fail when AI systems can reach sensitive data through natural language?
A: MCP fails when organisations treat connectivity as the main problem and ignore authorisation at the prompt and output layers.
Q: Why do third-party MCP servers create more risk than internal-only connectors?
A: Third-party MCP servers extend trust beyond the organisation's direct control, so they can expand the blast radius of prompts, context, and responses.
Q: What do teams get wrong about AI agent access in MCP environments?
A: Teams often focus on the agent interface and ignore the identity objects that actually authorize actions.
Practitioner guidance
- Define prompt-level access rules Map which prompts may query which datasets, and which prompts must be blocked, before enabling MCP against production security data.
- Treat third-party servers as semi-trusted Limit external MCP endpoints to the smallest viable data scope, review their ownership, and require validation before broadening access.
- Enforce OAuth 2.1 and HTTPS on every endpoint Require secure transport and modern delegated authentication for all MCP connections, including internal-only pilots and test servers.
Bottom line: MCP turns natural-language access into a governance problem because AI can query security data, assemble context, and shape actions before most organisations have defined the policy boundary.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/07/2026 9:09 pm
Promptable access is now an identity control plane problem: MCP moves the control point from query syntax to natural-language intent, which means governance has to decide who may ask for what before the AI resolves the request. That is a different security boundary from traditional dashboards or APIs. Teams should treat promptable access as a policy surface, not a convenience feature.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should teams govern AI agents that use MCP?
A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.
👉 Read our full editorial: MCP server security tips expose the governance gap in AI access