Because MCP turns an assistant into a delegated data consumer, which means the trust boundary extends beyond the original user and application. If the model is not covered by the same contractual and technical controls, regulated data can leave the approved boundary even when the source system itself is configured correctly.
Why This Matters for Security Teams
MCP changes the compliance conversation because the assistant is no longer just a user interface. It becomes a delegated data consumer that can retrieve, combine, and act on information across systems, which expands the trust boundary in ways many SaaS governance models were not built to handle. That matters for identity teams because access approvals, data residency, logging, and contractual controls now have to cover both the human requester and the model-mediated workflow.
The practical risk is not that SaaS controls disappear, but that they become incomplete if the model, connector, or agent is outside the same security and legal scope. Current guidance from the NIST Cybersecurity Framework 2.0 still applies, yet MCP adds an additional layer of authorization and accountability that must be explicit. Identity teams also need to consider whether a delegated action is still covered by the original user’s purpose, consent, and retention obligations.
In practice, many security teams discover the gap only after an assistant has already accessed regulated SaaS data in a way that was technically permitted but operationally out of scope.
How It Works in Practice
In a standard SaaS model, identity controls focus on the user, their session, and the application’s own authorization model. MCP introduces a second decision point: the model or agent asks for context, tools, or data on the user’s behalf, and that request may traverse separate services, runtimes, and audit paths. That makes the control problem less about a single login and more about chain-of-custody for identity, data, and intent.
Identity teams should map the full delegation path. Who authenticated, what scope was granted, which connector was used, what data was returned, and whether the model can persist or re-share it all need to be visible. A useful baseline is to treat MCP-enabled workflows as privileged integrations and review them with the same rigor used for service accounts, API keys, and admin automation. The control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls are helpful here, especially around access enforcement, auditability, and data handling.
- Define whether the MCP client, model host, and connector are in scope for the same policy set as the SaaS tenant.
- Restrict tool access by data classification, not just by user role.
- Log delegated actions separately from human actions so reviews can distinguish intent from execution.
- Require explicit approval for high-risk operations such as export, delete, invite, or privilege changes.
- Validate vendor claims about retention, training use, and prompt or tool telemetry before permitting sensitive workloads.
Best practice is evolving, but the security pattern is clear: identity governance must extend to the agent path, not stop at the human login. These controls tend to break down when MCP brokers are added quickly to existing SaaS stacks because connectors inherit broad scopes before governance and logging are redesigned.
Common Variations and Edge Cases
Tighter delegation controls often increase operational overhead, requiring organisations to balance workflow speed against review depth. That tradeoff is especially visible when teams want to enable assistant-driven search, summarisation, or ticketing without opening the door to overbroad SaaS access.
There is no universal standard for this yet, so organisations should label risk by use case. A read-only reporting assistant is not the same as an agent that can change records, send messages, or create accounts. Where regulated data is involved, identity teams should also verify whether the SaaS provider, the model provider, and any MCP infrastructure sit under the same contractual terms, regional processing rules, and incident obligations. The control logic in OWASP Top 10 for Agentic Applications 2026 is particularly relevant when tool use can be manipulated through prompt injection or indirect instruction.
Edge cases also appear in third-party integrations, where an agent can pivot from one SaaS product to another and accumulate data across boundaries that were never meant to be joined. In those environments, ISO/IEC 27001:2022 Information Security Management and ISO/IEC 27002:2022 Information Security Controls support a governance model built around scope, supplier assurance, and documented risk acceptance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF, NIST SP 800-53 Rev 5 and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-1 | MCP adds supplier and platform risk across the delegated data path. |
| NIST AI RMF | GOVERN | This is an AI governance problem as much as an access-control problem. |
| OWASP Agentic AI Top 10 | Tool Misuse / Prompt Injection | MCP workflows are exposed to tool abuse and indirect prompt manipulation. |
| NIST SP 800-53 Rev 5 | AC-3 | Delegated access must still enforce least privilege and authorization. |
| ISO/IEC 27001:2022 | MCP increases the need for documented scope, supplier, and risk controls. |
Map MCP providers and connectors into supplier governance and review their control scope regularly.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
