Skip to main content

​
What is Veto?

Veto is a runtime authorization layer that sits between your AI agents and the tools they can call. Before any tool executes, Veto evaluates the request against policies you define and returns a decision: allow, deny, or escalate — in under 10ms.

​
The problem Veto solves

AI agents are gaining access to powerful tools: file systems, APIs, databases, external services. Protocols like MCP and OAuth can prove who an agent is, but identity is not authorization. Knowing that a request comes from your support bot doesn’t tell you whether it should be allowed to send emails, delete records, or write to arbitrary file paths. Veto fills that gap. Every tool call is evaluated against explicit rules before it runs — so your agents can only do what you’ve said they’re allowed to do. 
Agent → Veto (authorized?) → Tool execution
         ↓
       Blocked

​
How it works

  1. You register an agent with Veto and get back a unique agent ID.
  2. You define one or more policies for that agent — rules that specify which tools it can call, what parameter values are permitted, and when access is allowed.
  3. Before your code executes a tool, it calls veto.authorize() with the agent ID, tool name, and parameters.
  4. Veto evaluates the request against your policies and returns a result. If the result is not allowed, you block execution.
  5. Every decision — allowed or denied — is written to the audit log.

​
Key concepts

Agents

An agent is a registered AI system — your support bot, coding assistant, or autonomous workflow. Each agent has a unique ID and a status that controls whether it can act at all.

Policies

Policies are collections of rules that govern what an agent can do. Rules cover tool allowlists and denylists, parameter constraints, rate limits, and time-based windows.

Authorization

The authorization check is the core of Veto. Pass an agent ID, tool name, and parameters — get back allowed, denied, or escalated with a human-readable reason.

Audit trail

Every authorization decision is logged with the agent, tool, parameters, outcome, matched policy, and latency. Query the audit log to understand what your agents are doing.

​
Default-deny model

Veto uses a default-deny model. If no policy explicitly allows a tool call, it is blocked. There is no implicit access — you always opt in to what an agent can do, never opt out. This means a newly registered agent with no policies cannot call any tools. Access must be granted explicitly through a policy.
This is intentional. The default-deny model ensures that gaps in your policy coverage result in blocked actions, not unintended access.

​
Next steps

Quick start

Install the SDK, create an agent, and run your first authorization check.

Authentication

Create an API key and learn how to authenticate your requests.

Concepts: agents

Learn how agents are registered and managed.

API overview

Explore the REST API endpoints directly.