Teams often treat HTTP verbs as the deciding factor, but the real question is whether the model is fetching context or doing work. A known object such as a plan, profile, or inventory usually belongs in a resource, while a search, update, or workflow belongs in a tool. That distinction materially changes the agent's reliability.
Why This Matters for Security Teams
The mistake is not just semantic. In MCP, calling something a tool instead of a resource changes the access model, the audit trail, and the blast radius when an agent misbehaves. Resources are for retrieval of known context, while tools initiate action. That means a “profile” or “policy” should usually be read-only context, but a “search,” “approve,” or “provision” operation belongs in a tool with explicit authorization. The distinction matters because autonomous systems do not follow human usage patterns. Guidance from OWASP Agentic AI Top 10 and NHIMG’s analysis in OWASP Agentic Applications Top 10 both point to the same issue: overly broad execution paths create agentic risk faster than teams expect.
Security teams also underestimate how quickly a misclassified MCP capability becomes an identity problem. If a resource can quietly mutate state, it is no longer just context. If a tool returns durable secrets, it is no longer a clean action boundary. That is why the question is tied to workload identity, JIT credentialing, and intent-based authorization rather than HTTP syntax alone. In practice, many security teams encounter this only after an agent has already combined a harmless-looking read with an unintended write path.
How It Works in Practice
Current guidance suggests mapping MCP capabilities by function and trust impact, not by endpoint shape. Start by asking whether the model needs a known artifact it can inspect repeatedly, or whether it needs to trigger a change in the environment. If it is context, expose it as a resource with narrow read scope and no hidden side effects. If it is action, expose it as a tool and require policy checks at request time. That is the operational logic behind the distinction in both OWASP Top 10 for Agentic Applications 2026 and NHIMG’s Analysis of Claude Code Security.
For autonomous agents, best practice is to pair this with workload identity and just-in-time secrets. A model should not hold long-lived credentials simply because it can call MCP. Instead, issue short-lived tokens per task, bind them to the workload identity, and revoke them when the job completes. That reduces the chance that a single misrouted prompt or chained tool call turns into persistent access. Where possible, enforce intent-based authorization so the policy engine evaluates what the agent is trying to do, the data it wants, and the current context before each call.
- Keep known objects such as inventories, policies, and profiles as read-only resources.
- Treat searches, approvals, writes, and workflow steps as tools with explicit authorization.
- Issue ephemeral secrets with short TTLs and automate revocation after completion.
- Log resource reads separately from tool invocations so audits show intent and effect.
These controls tend to break down when teams expose “convenience” tools that both retrieve context and perform side effects in the same call, because the agent can chain them without a clean policy boundary.
Common Variations and Edge Cases
Tighter classification often increases implementation overhead, requiring organisations to balance cleaner security boundaries against developer convenience. That tradeoff becomes visible in workflows where the same MCP operation can look like a resource to one team and a tool to another. For example, a document lookup may be harmless as read-only context, but if the returned payload can trigger downstream automation, current guidance suggests treating it as an action surface. There is no universal standard for this yet, so teams should document their own decision rules and review them regularly.
The hard edge case is mixed-mode capabilities. If a capability fetches a plan, then silently updates state, the security design becomes ambiguous and fragile. That is where real-time policy evaluation matters more than pre-defined RBAC, because autonomous agents do not keep stable access patterns. The risk is amplified in environments with shared prompts, multi-agent orchestration, or broad connector access, which are highlighted in NHIMG’s ASP.NET machine keys RCE attack as a reminder that secret exposure and execution paths can compound quickly. For control design, align the MCP model with OWASP Agentic AI Top 10, CSA MAESTRO, and NIST AIRMF so the boundary is governed by behavior, not naming. In practice, the exception is any environment where a “resource” can mutate state indirectly through callbacks, embedded workflows, or cached credentials.
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 | Covers unsafe agent actions and tool misuse in autonomous workflows. |
| CSA MAESTRO | Control 2.2 | Focuses on agent identity, intent, and runtime authorization decisions. |
| NIST AI RMF | GOVERN | Addresses governance and accountability for autonomous AI behavior. |
Classify each MCP capability by side effect and require policy checks before any action call.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
