Read only resources expose data for discovery without changing state, while writable tools perform actions that can modify systems or trigger downstream workflows. That distinction matters because read paths mainly need access control and redaction, whereas write paths also need approval, idempotency, rollback thinking, and stronger audit evidence.
Read-only MCP resources versus writable MCP tools
Read-only MCP resources are meant for inspection, discovery, and context gathering. Writable MCP tools are for taking action: creating, updating, deleting, triggering workflows, or otherwise changing state. That difference is not just architectural neatness; it determines how tightly the capability must be governed, how much blast radius it has, and what evidence you need when the model uses it.
For security teams, the practical issue is that a read path can often be governed with narrower exposure, stronger redaction, and simpler authorization logic, while a write path must be treated as an execution boundary. If a model can only read, the primary concern is what it learns. If it can write, the concern becomes what it can cause.
In mature deployments, that distinction maps to the same separation teams already use between inspection and execution in other systems, which is why writable tools deserve much stronger controls than resources. Read access can still leak sensitive context, but write access can change records, launch downstream jobs, or alter entitlements, so it needs approval logic, scoped credentials, and careful auditability. In practice, many teams discover the real difference only after an agent or integration has already used a writable tool in an unintended way.
How MCP capability boundaries work in practice
MCP resources are typically the safer default when a client needs documents, metadata, schema information, logs, or other data that should be exposed without side effects. They support discovery and reasoning, but they should not be assumed harmless, because even read-only data can contain secrets, personal data, or operational intelligence. A useful security read is not the same as a low-risk read.
Writable MCP tools are different because they carry operational intent. A tool call may update a ticket, send a message, provision access, push code, rotate a secret, or trigger an external system. Once a model can do that, the control problem shifts from simple visibility to constrained execution. The strongest designs separate tool permissions by function, require explicit approval for high-impact actions, and log enough context to reconstruct both the prompt and the resulting action.
A practical rule is to treat writable tools as if they were privileged automation endpoints, not just convenient API wrappers. That means you should think about idempotency, rollback, and failure handling before exposing them to autonomous agents. It also means the authentication model matters: a read-only resource may tolerate broader audience access, but a writable tool should be bound to the minimum non-human identity or service credential needed for the action.
- Use resources for discovery when the model only needs context.
- Use tools only when the model must cause a change in a downstream system.
- Separate read scopes from write scopes so approval and monitoring can differ.
- Record the exact tool arguments and result so you can prove what changed.
Astrix Security’s State of MCP Server Security 2025 found that only 18% of mcp server deployments implement any form of access scoping for tool permissions, which is a strong signal that write-path governance is still immature. For broader agent behaviour and tool abuse patterns, the OWASP Agentic AI Top 10 is a useful companion reference because it focuses on how autonomous systems fail when tool use is too permissive.
These controls tend to break down when the same endpoint is used for both data retrieval and state change, because the permission model becomes ambiguous and the audit trail stops reflecting actual risk.
Where the boundary gets blurred, and why that matters
Tighter separation between read and write capability often improves safety, but it also adds governance overhead, especially in fast-moving agent workflows. The trade-off is that teams sometimes over-grant write access to reduce friction, then rely on monitoring to catch misuse later. That is usually backwards, because writes are the actions most likely to create irreversible business impact.
Best practice is evolving around contextual authorization: a model should not receive write capability simply because it has already read the relevant data. A read result can justify a next step, but it should not automatically confer permission to act. In multi-agent or delegated workflows, the cleaner pattern is to keep resources broadly inspectable where appropriate and to gate tools behind short-lived, task-specific authority.
There is also an important edge case: some operations look read-like but still have side effects, such as exporting data, refreshing caches, or generating reports that trigger downstream processing. Those should be treated as tools, not resources, because the practical risk is defined by the effect, not the label. If a capability can alter state, emit secrets, or initiate external work, it belongs in the writable class.
The OWASP Agentic AI Top 10 is helpful here because it frames tool exposure as a governance and abuse problem rather than a naming problem. When teams blur the boundary, they usually lose the ability to answer a simple question: whether the model merely observed something, or actually changed something.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Separates read access from privileged write paths. |
| 8 — Audit Log Management | Writes need reconstructable evidence of who did what. | |
| Recommendation — Restrict writable MCP tools to the minimum authorized accounts and scopes. Log tool arguments, approvals, and resulting state changes for review. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Capability boundaries depend on least-privilege authorization. |
| PR.DS — Data Security | Read-only resources can still expose sensitive data and secrets. | |
| DE.CM — Continuous Monitoring | Writable tools require monitoring for misuse and unexpected effects. | |
| Recommendation — Apply least-privilege controls to distinguish resource reads from tool actions. Protect resource outputs with filtering, redaction, and data handling rules. Monitor MCP tool calls for anomalous actions and scope creep. | ||
| OWASP Agentic AI Top 10 | A1 — Tool Abuse and Overreach | Writable tools are the core abuse surface in agentic systems. |
| Recommendation — Constrain tool permissions so agents cannot exceed intended action scope. | ||
Practitioner Guidance
What to prioritise: Classify every MCP capability by effect, not by convenience. If the call can modify state, trigger an external action, or change an entitlement, treat it as a writable tool and require a higher control tier than any resource that only returns data.
Decision rule: If a capability can be safely replayed without changing the environment, it may belong in the read path; if replay would create a second real-world effect, it must be governed as write-capable automation.
What to verify: Confirm that write tools have explicit scope boundaries, narrow credentials, and audit records that show who authorised the action, what inputs were supplied, and what downstream effect occurred. Without that evidence, the tool is harder to trust than the model using it.
Common mistake: Do not assume that “read-only” means low sensitivity. Read-only resources can still expose secrets, customer data, or internal system topology, and that visibility can be enough to enable later abuse.
Practitioner takeaway: The most important design choice is not whether MCP is used, but whether the system can prove where observation ends and execution begins.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
