Resources are read-only data endpoints exposed through MCP for retrieving context from systems such as databases, knowledge bases, or operational platforms. They separate data access from action execution, which helps preserve auditability and reduce unintended side effects in AI-driven workflows.
Expanded Definition
In MCP, resources are read-only endpoints that expose context from systems such as databases, knowledge bases, ticketing platforms, and operational telemetry. They are distinct from tools and actions because they return data without granting execution authority, which helps preserve auditability and limit unintended side effects.
For NHI and agentic AI governance, that separation matters. A resource can safely inform an AI Agent’s reasoning while still keeping write paths, approval flows, and privileged operations behind explicit controls. In practice, resources often carry sensitive business context, so “read-only” does not mean “low risk”; it means the primary risk is disclosure, over-broad retrieval, or indirect inference rather than direct mutation. The industry is still evolving on how finely resources should be scoped, tagged, and policy-checked, so definitions vary across vendors even though the architectural intent is consistent. The MCP specification and the NIST Cybersecurity Framework 2.0 both reinforce the value of separating access, governance, and traceability.
The most common misapplication is treating a resource like a harmless data feed when it actually exposes overly broad context to an agent with weak query controls.
Examples and Use Cases
Implementing resources rigorously often introduces access-design overhead, requiring organisations to weigh faster agent context retrieval against tighter scope, monitoring, and data minimisation.
- An internal support agent reads customer entitlement data from a knowledge base resource while a separate tool handles ticket updates after human approval.
- A security copilot queries configuration history from an operational platform resource to explain drift, without being able to remediate it directly.
- A finance assistant pulls invoice metadata from a database resource to summarise spend trends, while payment execution remains isolated in a controlled workflow.
- A developer assistant retrieves build logs and dependency facts through a resource endpoint, then uses an approval-backed tool for any deployment action.
- A governance team maps sensitive data exposure patterns using resources and compares them with incident examples such as ASP.NET machine keys RCE attack and Gladinet Hard-Coded Keys RCE Exploitation, where weak separation between data exposure and execution became a security problem.
Resources are most useful when an AI Agent needs context continuity but must not inherit write permissions from the same integration path.
Why It Matters in NHI Security
Resources are central to the NHI security model because they shape what an AI Agent can see before it decides what to do. If resource access is too broad, the agent may assemble sensitive context from multiple systems, increasing exposure of secrets, personal data, or operational details even when no action is taken. If resource access is too narrow, the agent loses the context needed for accurate decisions and teams compensate by granting unsafe shortcuts elsewhere.
This is why resource governance must be paired with identity controls, logging, and least privilege. NHIMG reports that only 5.7% of organisations have full visibility into their service accounts, and that lack of visibility makes it difficult to know which identities can reach which resources. The problem is not just access, but inherited trust across integrations, connectors, and shared API surfaces. Mapped correctly, resources support safer retrieval patterns aligned with NIST CSF 2.0 and stronger non-human identity governance. The most common failure mode appears after a data exposure or agent misuse incident, at which point resource scope becomes operationally unavoidable to review and contain.
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, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Resources define what an agent may read before it acts, a core agentic security boundary. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Resource exposure depends on non-human identity scope and access boundaries. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access applies directly to who and what can query resources. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires explicit enforcement of access decisions for each resource request. |
| CSA MAESTRO | MAESTRO distinguishes contextual data access from agent tool execution in governed workflows. |
Design resource retrieval as a controlled observation plane, separate from any executable action.
Related resources from NHI Mgmt Group
- How should security teams prioritise NHI controls when resources are limited?
- How should security teams govern API clients that manage cluster resources?
- What do teams get wrong about tools versus resources in MCP?
- How should security teams govern authorization when applications add nested resources?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
