Unknown server control
Review or block tool calls from MCP servers your team has not approved yet.
For MCP builders
Guard MCP tools before they execute
MCP connects agents to tools. Veto decides whether a given tool call should run, whether it needs human review, and which decision record to keep afterward.
Sensitive operations
Hold delete, payout, export, production, and data-access calls before the tool runs.
Tenant-aware policy
Apply different rules by customer, environment, workflow, or reviewer authority.
The runtime path
Authorization decides who connects. Veto decides what runs.
OAuth and server authorization are necessary, but they do not answer whether this agent should call this tool with these arguments right now. Veto sits at the tool-call boundary, where the risk becomes concrete.
That makes MCP security review less abstract. You can show approved servers, blocked paths, review queues, and decision records for the exact actions your agent attempted.
For implementation detail, use the full MCP integration guide and the MCP policy guide.
MCP FAQ
What does Veto add to MCP?
MCP connects agents to tools. Veto governs the wrapped moment before a tool runs: allow the call, block it, or pause it for human review, then write a decision record for review.
Is this the same as MCP authorization?
No. MCP authorization identifies clients and protects access to servers. Veto is runtime authorization: it evaluates the specific tool name, arguments, server, tenant, and context after identity is known.
Does Veto help with tool poisoning?
Yes. Tool descriptions and annotations are hints, not guarantees. Veto evaluates the actual call against policy, so a misleading tool description does not by itself grant permission on the governed path.
Where should an MCP team begin?
Begin with one server that can touch sensitive data or change state. Put review-required tools behind allow, review, or deny rules; run in shadow mode if needed; then export the first decision record for security review.