Because they turn read access into decision context. If roots are broad or resource sets are poorly segmented, the model can infer sensitive operational detail without ever calling a tool. Identity teams should govern resource exposure like data access, because the resulting model context can be as sensitive as an active credential.
Why This Matters for Security Teams
MCP roots and resource sets are not just plumbing for retrieval. They define what the model can see before a tool call ever happens, which means they shape decision context, not only execution access. That makes them a governance issue for identity teams, because broad roots can expose operational data, system topology, tickets, logs, or secrets-adjacent information that the model can reason over and later use in prompts, plans, or downstream actions.
This is where traditional access reviews often miss the real risk. Teams may validate who can invoke an agent or which connector is enabled, while overlooking what the agent can infer from connected resources. Current guidance from the OWASP Agentic AI Top 10 and NHI governance research such as Top 10 NHI Issues both point to the same operational reality: exposure paths matter as much as credentials.
That matters especially because NHIs already dominate enterprise attack surfaces, and the Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises. In practice, many security teams discover MCP overexposure only after an agent has already surfaced sensitive context into a prompt, a log, or a shared workflow rather than through intentional data classification.
How It Works in Practice
In MCP, roots define the top-level scope the client or agent can traverse, while resources are the specific files, datasets, endpoints, or context objects exposed within that scope. If those boundaries are too broad, the model can read enough operational detail to form plans, answer questions with hidden context, or infer data relationships that would normally require human review. That is why identity teams should treat MCP exposure like a data access problem and not merely a connector inventory problem.
A practical governance model usually starts with segmentation. Separate roots by environment, application boundary, sensitivity tier, and tenant where possible. Then align each root to a named business purpose, a designated owner, and an explicit review cadence. For agentic systems, best practice is evolving toward runtime policy evaluation rather than static allowlists alone, because the risk is not only “can the agent connect” but “what context is appropriate for this task right now.”
- Limit each root to the smallest coherent dataset or service boundary.
- Classify resources by sensitivity, including metadata that could reveal architecture or incident details.
- Prefer per-task authorization and short-lived access over persistent broad roots.
- Log resource reads separately from tool execution so context exposure can be audited.
- Review whether the agent needs full retrieval or only summarized, filtered outputs.
For identity teams, this maps cleanly to Zero Trust thinking in the NIST Cybersecurity Framework 2.0 and to workload governance patterns discussed in Ultimate Guide to NHIs. These controls tend to break down when a single MCP root spans mixed-sensitivity sources, because the model can combine benign and sensitive context into a more privileged picture than any individual resource intended.
Common Variations and Edge Cases
Tighter root segmentation often increases operational overhead, requiring organisations to balance least exposure against connector sprawl and maintenance burden. That tradeoff becomes sharper in fast-moving agentic environments, where teams want broad retrieval to reduce friction but still need to prevent accidental context leakage.
There is no universal standard for this yet. Current guidance suggests treating shared roots, inherited directory trees, and “catch-all” resource bundles as high-risk patterns, especially where the same agent serves multiple business functions. Multi-tenant platforms, sandbox environments, and developer preview spaces need extra care because low-friction experimentation can quietly become production-like access. In those cases, the question is not whether the agent is authenticated, but whether the context it can read is appropriately bounded for the task.
This is also where policy decisions should be explicit about exceptions. Some teams will allow broader roots for debugging, incident response, or controlled analysis, but those exceptions should be time-bound, ticketed, and reviewed. The 52 NHI Breaches Analysis reinforces a recurring pattern across incidents: overbroad identity scope and weak lifecycle controls often show up together, not in isolation. Where MCP resources expose operational context that can influence action, the governance bar should be closer to privileged data access than to ordinary application configuration.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Resource exposure shapes what agents can infer before tool use. |
| CSA MAESTRO | T1 | MAESTRO addresses agent context, autonomy, and tool governance. |
| NIST AI RMF | GOVERN | MCP root governance needs accountable AI risk ownership. |
Define explicit task boundaries and monitor context exposure across agent workflows.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
