Notifications
Clear all
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.
NHIMG editorial — based on content published by JupiterOne: 5 Essential Tips for Using JupiterOne MCP Server
Questions worth separating out
Q: How should security teams govern MCP server access in AI workflows?
A: Security teams should govern MCP server access as a delegated identity path, not as a generic integration.
Q: Why do MCP servers create risk for IAM and NHI programmes?
A: MCP servers create risk because they let AI clients reach across assets, logs, policies, and actions through one conversational interface.
Q: What do teams get wrong about securing AI tool connectors?
A: Teams often assume that authentication alone is enough, but authenticated access can still be too broad or too fast for safe governance.
Practitioner guidance
- Classify every MCP endpoint by trust level Separate internal-only servers from third-party connectors, and require a review step before any server can access identity, cloud, or log data.
- Enforce OAuth 2.1 scope design for AI clients Bind each MCP client to the narrowest practical token scope, and review whether the scope matches the tool set the client can actually invoke.
- Sanitize prompts and outputs at the MCP boundary Validate both inbound prompt content and outbound data returned to the model, especially when natural language can surface logs, asset inventory, or IAM state.
What's in the full article
JupiterOne's full post covers the operational detail this post intentionally leaves for the source:
- Prompt examples for querying risky Lambda functions, misconfigurations, and asset exposure through MCP
- Step-by-step dashboard creation workflows for tracking risks over time in the JupiterOne interface
- Operational alert-routing examples for Slack, Teams, and severity-based notifications
- Implementation notes on HTTPS, OAuth 2.1, sanitization, and internal-only MCP pilots
👉 Read JupiterOne's tips for using the MCP Server in security workflows →
MCP server security tips: are your AI access controls keeping up?
Explore further
11/07/2026 9:09 pm
MCP creates an identity trust boundary where many teams still see only an integration layer. Once AI systems can query cloud and security data in real time, access control is no longer confined to a login event or a single API token. The governance question becomes whether the tool chain itself is authorised, bounded, and auditable across each context switch. Practitioners should treat MCP as a control plane for identity exposure, not as a harmless connector.
A few things that frame the scale:
- 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to SailPoint.
A question worth separating out:
Q: What is the difference between a secure MCP pilot and a production-ready deployment?
A: A secure pilot proves that endpoints, scopes, and logging work under controlled conditions. A production-ready deployment adds accountability, change control, validated third-party trust, and tested containment for failures. If those pieces are missing, the MCP server may be functional, but it is not yet governed for enterprise use.
👉 Read our full editorial: MCP server security tips expose the governance gap in AI access
