MCP tool governance is the policy system that controls which external tools an AI agent can discover, call, and retry. It should enforce per-tenant allow-lists, approval modes, scoped credentials, payload validation, and immutable audit logs.
Governance model
Tool access should be explicit. An agent that can summarize a ticket does not automatically need permission to refund an order, update a CRM record, or send an email.
Treat tools like APIs with authorization, schema validation, rate limits, and audit logs. The model can propose an action, but the governance layer decides whether it is allowed.
- ->Expose the smallest useful tool catalog per workflow.
- ->Use scoped credentials instead of shared service tokens.
- ->Require approval for irreversible actions.
- ->Trace every tool request and response.
Approval modes
Approval should match risk. Read-only tools can usually run automatically. Tools that mutate customer data, spend money, or contact external users need stronger controls.
The most practical setup uses three modes: auto-approve for safe reads, policy-approve for constrained writes, and human-approve for sensitive actions.
| Mode | Use for | Example |
|---|---|---|
| Auto | Low-risk read operations | search_docs |
| Policy | Constrained writes | tag_ticket |
| Human | High-impact actions | issue_refund |
| Blocked | Unavailable in workflow | delete_account |
Tool schemas
Schemas protect the tool from malformed model output. They also make failures explainable: the system can say exactly which field failed validation and which span introduced the bad payload.
Write schemas for inputs, outputs, and side effects. Output schemas matter because downstream agents often treat tool responses as facts.
const refundTool = defineTool({
name: "orders.issue_refund",
approval: "human",
input: {
order_id: "string",
amount_usd: "number",
reason: "enum:duplicate|damaged|late"
},
limits: {
max_amount_usd: 250,
per_customer_daily_count: 1
}
});Audit logs
Audit logs should record the tool name, caller, tenant, approval mode, input hash, output hash, policy decision, and trace ID. This lets compliance teams inspect behavior without exposing raw sensitive payloads by default.
In Vektor, the operating model is explicit: agents call tools, policies authorize calls, traces record execution, and evaluations check whether the tool result was used correctly.
Runtime policy decisions
Tool policy should evaluate the request context at runtime. The same tool can be safe for one workflow, blocked for another, and require approval for a third based on tenant, user role, amount, destination, or prior conversation state.
Vektor stores the policy decision beside the tool span so reviewers can see whether an action was auto-approved, policy-approved, human-approved, or blocked before execution.
| Context | Policy decision | Trace field |
|---|---|---|
| Read-only lookup | Auto-approve | approval_mode=auto |
| Low-value update | Policy-approve | approval_mode=policy |
| Refund or external message | Human review | approval_mode=human |
| Unavailable workflow tool | Block | policy_decision=blocked |
Evaluation coverage
Governance does not stop when the tool call succeeds. The downstream answer still needs to use the tool result correctly, avoid leaking raw tool output, and explain uncertainty when the tool returns incomplete data.
A complete evaluation suite checks both sides of the tool boundary: whether the call was allowed and whether the model used the response faithfully.
- ->Evaluate whether the selected tool was necessary for the task.
- ->Check that required approvals happened before execution.
- ->Validate that the final answer reflects the tool output accurately.
- ->Flag answers that expose sensitive raw tool fields unnecessarily.
Common questions
What is MCP tool governance?
MCP tool governance controls which tools an AI agent can use and under what authorization, validation, and audit requirements.
Do all MCP tool calls need human approval?
No. Low-risk read tools can be auto-approved, while high-impact actions should require human approval or stricter policy checks.
What should an MCP tool audit log include?
It should include the tool, caller, tenant, policy decision, approval mode, input and output references, timestamps, and trace ID.
How does Vektor show blocked tool calls?
Blocked calls appear as policy decisions on the trace, with the attempted tool name, caller, tenant, decision reason, and no executed side effect.
What should be evaluated after a tool call?
Evaluate whether the tool was appropriate, whether approvals were satisfied, whether the output was used accurately, and whether sensitive fields were handled safely.