Teams should treat tool execution as a privileged action path, not a background feature. The client should enforce explicit approval, the server should expose only narrowly scoped schemas, and the organisation should log each call as a distinct authorised event so action cannot drift beyond user intent.
Why MCP Tool Execution Needs Governance, Not Convenience
MCP tool calls are not inert plumbing. They are execution events that can reach data, trigger side effects, or chain into other systems, so the governance question is really about where authority is granted and how far it can travel. Teams should treat the client, server, and logging layers as separate control points, not as interchangeable safeguards.
The client should be the point where intent is checked, because that is where the user or agent decision is still visible. The server should expose only the minimum tool surface needed for the workflow, because schema breadth directly expands the action surface. And the organisation should preserve an audit trail that can distinguish one authorised tool invocation from the next, which is essential when a workflow branches across multiple actions.
That separation matters because MCP failures usually arise when teams assume tool access is just another API call. In practice, the better question is whether each tool invocation is bounded, attributable, and reviewable before it can create downstream state. The MCP authorization specification is useful here because it frames servers as OAuth resource servers and pushes teams away from token passthrough and ambiguous audience handling.
How to Set Boundaries Around Tool Use
Governance starts with the narrowest workable contract between the caller and the tool. If a tool can read, write, or trigger side effects, that scope should be explicit in the schema and visible to the client before approval. Broad, catch-all tools are harder to review, harder to log meaningfully, and easier to misuse when an agent chains actions unexpectedly.
Approval should be tied to the concrete action, not to the existence of the workflow. A team may accept a workflow that needs several tool calls, but each call still needs to be understandable as a separate decision with its own scope and outcome. That is especially important when a tool can cross trust boundaries, modify state, or expose information that the user did not clearly ask for.
Good governance also means distinguishing capability from entitlement. A tool existing in the catalog does not mean every caller should be able to reach it, and a successful call does not mean future calls should inherit the same trust without re-evaluation. In agentic environments, a strong fit is to pair this approach with OWASP Agentic AI Top 10, because tool misuse and identity and privilege abuse are central failure modes when execution is delegated.
What Teams Should Log and Review
Tool governance fails quickly if the organisation cannot reconstruct what was authorised, by whom, and with what result. Logging should therefore capture the tool name, caller, approval state, input summary, output summary, timestamps, and any changed objects or downstream actions. That turns a tool call into a reviewable security event rather than an opaque implementation detail.
The practical standard is whether an investigator can answer three questions later: what was intended, what actually ran, and what changed. If the answer depends on reading application traces, shell history, or agent memory, the control is too weak. Logging should instead produce a distinct event for each authorised action so drift, replay, and quiet privilege expansion are easier to spot.
Review should focus on patterns that reveal misuse rather than on raw volume alone. Repeated approvals for the same sensitive tool, unexpected tool chaining, or calls to tools outside the normal task path often show that workflow boundaries are too loose. A second useful reference point is MCP Security Guide, which covers practical authorisation patterns, token handling, and tool poisoning considerations for MCP deployments.
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 OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Tool execution governance is about preventing unsafe agent tool use. |
| ASI03 — Identity & Privilege Abuse | MCP workflows can expand authority if tool calls inherit excess privilege. | |
| ASI09 — Human-Agent Trust Exploitation | Approval decisions can be manipulated when users over-trust agentic tool actions. | |
| Recommendation — Constrain tool permissions and approvals to prevent misuse of delegated actions. Bind each tool call to least privilege and re-check delegated authority. Require explicit confirmation for impactful actions and verify user intent at the call site. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Each authorised tool call should be recorded as a distinct auditable event. |
| AC-6 — Least Privilege | Tool schemas and execution rights should be narrowly scoped to reduce blast radius. | |
| Recommendation — Log each tool invocation with actor, action, result, and time. Limit tool access to the minimum privileges needed for the workflow. | ||
| NIST Zero Trust (SP 800-207) | AC-6 — Least Privilege Access Enforcement | MCP tool access should be evaluated as bounded, per-request authorisation. |
| Recommendation — Enforce per-request authorisation before every sensitive tool call. | ||
| OWASP ASVS | V8 — Authorization | Tool execution should only happen after explicit authorisation checks. |
| V16 — Security Logging and Error Handling | Reviewable logs are needed to reconstruct tool execution and misuse. | |
| Recommendation — Require explicit authorisation checks before state-changing tool actions. Record security-relevant tool events with enough detail to support investigation. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Tool endpoints can expose privileged functions if execution rights are too broad. |
| API2 — Broken Authentication | MCP tool execution depends on trustworthy caller authentication and token handling. | |
| Recommendation — Restrict sensitive tool functions to callers that are explicitly entitled to use them. Authenticate callers strongly before allowing access to tool execution. | ||
Practitioner Guidance
What to prioritise: Start by classifying every MCP tool by blast radius, then decide which ones require explicit human or client-side approval before execution. High-impact tools should not share the same approval path as low-risk read-only calls.
What to verify: Confirm that logs distinguish each individual tool invocation, not just the parent conversation or session. If reviewers cannot tell which exact call produced a side effect, the governance model is too coarse to trust.
Common mistake: Teams often secure the MCP server and forget the caller experience. That leaves approval ambiguous at the point where intent is formed, which is where misuse is easiest to prevent.
Practitioner takeaway: Treat mcp tool execution as a controlled delegation problem: make approval explicit, keep schemas tight, and preserve per-call accountability so the workflow stays inside the intended authority boundary.
Related resources from NHI Mgmt Group
- How should security teams govern AI connectivity when LLM APIs, MCP tool calls, and agent-to-agent workflows all touch sensitive data?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?
- How should security teams govern non-human identities in Salesforce?