Customer-owned control for agent tool calls
AI agents already reach money, data, browsers, inboxes, and internal APIs. Identity tells you which actor is calling. Veto answers the harder question at runtime: should this exact action, with these arguments, execute now? Enforcement can run locally. Evidence stays inspectable.
Why we exist
Before Veto, we built security tooling for LLM-generated code. That work exposed the real failure mode: agent risk stops being theoretical when a model-driven system gets a real credential and a real tool.
Broken text is noisy. Unauthorized action is operational risk. Veto exists for the moment between intent and execution: the independent check that decides whether this action should run, records why, and leaves the evidence with the team operating the agent.
What Veto is
Veto is the authorization check between the agent and the tool. Governed calls are evaluated before execution against explicit policy, and returned as allow, block, or review with a decision record.
Policies are declarative YAML, version-controlled alongside your code. They evaluate tool arguments directly: block transfers over a threshold, restrict file paths, require approval for external emails. Deterministic rules set hard boundaries. Optional semantic checks cover ambiguous content. Neither is hidden in the prompt.
The open-source SDK can evaluate policy in-process. The cloud adds review workflows, team approvals, retention, reporting, and an MCP gateway for Claude, Cursor, Windsurf, and MCP-compatible clients. Enterprise deployments can keep enforcement and evidence in your cloud or on-prem environment.
Start where one action can cause real damage. Read docs.
Open source
Authorization belongs in infrastructure, so the core must be inspectable, self-hostable, and not locked to a vendor. The SDK and policy engine are Apache-2.0. The production SDK path is TypeScript today; Python is a preview package for local tool-call checks. Local enforcement stays inspectable.
You own your policies. You own your data. The business model is not a hostage model: we charge for operations around the core, including approvals, review workflows, retention, reporting, MCP access, and hands-on implementation support.
Team
Founder and CEO
Product, company, and policy-engine direction. Turns buyer risk into enforceable boundaries.
Founder and CTO
Runtime, API, infrastructure, and production systems. Owns the SDK-to-verdict path and decision-record pipeline.
COO
Go-to-market and compliance operations. Maps buyer deadlines to evidence, deployment scope, and rollout sequence.
Operating principles
Authorization is not identity
Knowing who the agent is does not decide what it may do. Identity is a prerequisite. The tool-call boundary is where enforcement happens.
Deterministic enforcement, adaptive judgment
Hard rules where certainty exists. Semantic checks where language matters. Trust should not depend on probability alone, and ambiguity should not be forced into brittle static rules.
The agent should be unaware
Governance wraps tools transparently. No policy stuffed into the prompt. The control stays outside model reasoning and visible to the operator.
Can is not may
Whether an agent can perform an action says nothing about whether it should be allowed to. Systems that confuse access with permission create privilege escalation by default.
If an agent can affect money, data, or customers, govern the first action before it executes.