Govern them as separate execution surfaces with shared policy enforcement. Prompts, tools, and resources all need input screening, output inspection, logging, and scope review because each can become a path for prompt injection or unsafe model behaviour.
How MCP governance should be structured
Governance works best when teams treat prompts, tools, and resources as distinct execution surfaces rather than one generic “agent” control plane. That matters because each surface introduces a different failure mode: prompts can carry instructions, tools can execute actions, and resources can expose data or context. A single policy layer should still apply across all three, but the control objectives are not identical.
For prompts, the governance question is primarily about instruction integrity, input filtering, and whether the system can be steered into unsafe behaviour. For tools, the focus shifts to action authorization, allowlisting, and blast-radius reduction. For resources, the priority is scope, read access, and preventing data exposure through overbroad retrieval or accidental disclosure.
The practical implication is that MCP governance should be designed around policy consistency, not uniform treatment. Teams should standardize screening, logging, and inspection expectations, then set surface-specific rules for what may be invoked, what may be returned, and what requires human review. That is the difference between having a policy and actually governing execution.
What should be controlled on each surface
Prompts need controls that reduce prompt injection, jailbreak-style instruction conflicts, and unauthorized instruction chaining. The key issue is that a prompt can change model behaviour without changing the application code, so prompt handling must be treated as a security boundary. Inspection should look for malicious instructions, hidden role changes, and attempts to influence downstream tool use.
Tools need explicit scope review because they are the part of the system that can produce external side effects. A tool that sends mail, modifies tickets, queries a database, or runs a command is not just an integration, it is an execution path. Teams should define which tools exist, which identities may invoke them, and which arguments or parameters are acceptable.
Resources need governance around exposure, retrieval scope, and whether the model should be able to see them at all. If a resource can be surfaced to an agent, it should be classified like any other sensitive control point: know what it contains, who can request it, and whether it can be filtered or redacted before it reaches the model.
For MCP deployments, the MCP authorization specification is a useful baseline for understanding how server authorization should be bounded, while RFC 9728 helps explain resource metadata discovery in a way that supports tighter control over what the client can learn and request.
Why shared policy enforcement still needs separate review points
Shared enforcement is valuable because it prevents each team from inventing a different security model for the same deployment. But shared policy does not remove the need for separate review points, because the risks land differently. A prompt review is about intent and instruction safety, a tool review is about action safety, and a resource review is about data exposure and scope.
The strongest governance pattern is to require the same minimum controls across all three surfaces: input screening before the model sees content, output inspection before anything is acted on, logging for traceability, and scope review for every change in privilege or exposure. That gives security teams a common operating model while still letting each surface have stricter checks where the blast radius is highest.
Good governance also means understanding where control failures compound. A benign-looking prompt can trigger a dangerous tool call, and a legitimate tool can return data that should never be placed back into the conversation. The policy therefore has to cover both direct misuse and indirect chaining, not just the obvious first hop.
Risk and Threat Considerations
MCP governance fails when teams assume that prompt safety, tool safety, and resource safety are interchangeable. Attackers do not need to break the whole system if they can compromise one surface and use it to influence the others, especially where tool output is fed back into planning or where resource access is broader than the task requires.
Failure mechanism: Prompt injection, unsafe tool invocation, and overbroad resource scope create a chained trust path in which malicious instructions can be converted into action or disclosure before reviewers notice the problem.
Impact: The result can be unauthorized side effects, data leakage, credential exposure, or unsafe model behaviour at the point where the system has enough authority to do real damage.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | MCP tools can be abused to take unsafe actions through agent execution. |
| ASI03 — Identity & Privilege Abuse | Shared MCP governance must prevent agents from exceeding granted authority. | |
| ASI06 — Memory & Context Poisoning | Prompt and resource inputs can poison agent context and alter behaviour. | |
| Recommendation — Restrict tool invocation paths and validate every action-capable tool call. Bind agent permissions to least privilege and review privilege changes. Screen incoming context and inspect outputs before reusing them downstream. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | MCP governance needs logs across prompts, tools, and resources for traceability. |
| AC-6 — Least Privilege | Tool and resource scope must be minimized to reduce MCP blast radius. | |
| Recommendation — Log prompt, tool, and resource activity with enough detail for review. Limit each surface to the minimum access needed for the task. | ||
Practitioner Guidance
What to verify: Verify that prompts, tools, and resources each have a distinct policy checkpoint, even if they share the same approval framework. If the same control cannot explain how it prevents instruction abuse, unsafe execution, and data exposure separately, it is too coarse to trust.
What to prioritise: Prioritise tool authorization and resource scope before polishing prompt filters. In practice, the highest-impact failures usually come from actions or data access that were broader than the task required, not from the prompt text alone.
Common mistake: Treating MCP governance as an observability problem only. Logging is necessary, but it does not substitute for allowlists, scope limits, or explicit review of which surface is allowed to influence which other surface.
Practitioner takeaway: The safest MCP posture is to keep instruction, execution, and data access under separate scrutiny while enforcing one coherent policy model across all three.