Topic starter
22/01/2026 2:55 pm
TL;DR: MCP standardises how AI agents discover tools and request scoped access, but the protocol still leaves object-level authorisation, ephemeral context handling, and downstream enforcement to the enterprise, according to SGNL. That means MCP changes the control problem for IAM and NHI teams more than it changes the risk model itself.
Editorial analysis by NHI Mgmt Group, based on content published by SGNL: “What is MCP and why enterprises need to secure it”.
Key questions
Q: What breaks when MCP scopes are treated as enough for enterprise access control?
A: Object-level authorisation breaks first.
Q: Why do AI assistants and MCP servers create new access-control risks?
A: They are not just productivity tools.
Q: How do organisations know whether MCP enforcement is actually working?
A: The clearest sign is that every meaningful agent action produces a consistent attestation trail and can be blocked when the session lacks provenance.
Practitioner guidance
- Map MCP scopes to object-level entitlements Do not rely on the tool name or declared scope alone.
- Preserve user identity through downstream processing Ensure the MCP server carries the original user identity, request parameters, and decision context into every downstream service call so later results can be denied if permissions change.
- Constrain tool discovery by user role Limit which tools appear to a given user or agent so the model cannot pivot into adjacent functions that recreate the same sensitive answer through alternate paths.
Bottom line: MCP improves how AI agents find tools and request access, but it does not eliminate the need for object-level authorisation or downstream enforcement.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
07/10/2026 7:57 am
MCP introduces a new authorization boundary, but it does not redefine enterprise identity governance. The protocol helps standardise how agents discover tools and request scopes, yet the enterprise still owns object-level authorisation, context preservation, and downstream enforcement. That means MCP should be treated as an integration pattern that inherits IAM obligations, not as a substitute for them.
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.
A question worth separating out:
Q: Should IAM teams treat MCP as a replacement for existing authorisation controls?
A: No. MCP is a transport and discovery pattern with some authorization guidance, not a complete governance model. IAM teams still need object-level checks, token expiry discipline, user-context propagation, and controls that stop alternate tool paths from reconstructing restricted data.
👉 Read our full editorial: MCP security guardrails for enterprise AI agents and tools