Compare/Veto vs Airlock

Veto vs Airlock: MCP gateway or embedded authorization?

Name: Veto
Availability: InStock
Author: Veto

Airlock and Veto both protect tool-calling agents before dangerous actions run. Airlock is an MCP gateway with tool visibility control, allowlists, approvals, audit logs, middleware, and sandbox variants. Veto is an embedded authorization SDK and platform for governing the specific action your product or buyer cares about.

Short answer

Choose Airlock when MCP is the center of your stack and you need a gateway to shape the tool surface. Choose Veto when the buyer-reviewed risk is one production action that must be authorized with policy, approval, and retained evidence before it changes a real system.

What each product is built for

Veto

A runtime authorization SDK and platform for governed tool calls. Veto sits inside the application or agent execution path, evaluates policy on the tool and arguments, routes review-required actions to humans, and keeps decision records for buyer review.

Product workflows where the tool call changes money, data, customers, claims, or cases
Non-MCP agents and app-native tool execution paths
Regulated buyers that ask for policy IDs, reviewers, records, retention, and exports
Teams that want one risky workflow under policy before broad gateway adoption

Airlock

An open-source MCP gateway that sits between agents and their tools. It filters which tools agents can see, applies allow or ask rules, pauses sensitive calls for approval, logs to SQLite, and adds middleware for injection, PII, rate limits, and sandboxing.

MCP-heavy stacks where the gateway is the natural control point
Coding agents that need shell, git, HTTP, and tool allowlists
Teams that want Slack, Telegram, terminal, or menu-bar approvals around MCP calls
Local developer workflows that benefit from command policies and sandbox variants

Feature comparison

Capability	Veto	Airlock
MCP gateway	optional	Yes
In-process SDK	Yes	No
Tool visibility filtering	partial	Yes
Per-tool-call authorization	Yes	Yes
Policy on tool arguments	Yes	Yes
Human approval workflow	Yes	Yes
Slack or Telegram approvals	custom	Yes
Decision records for customer review	Yes	SQLite logs
Policy evidence exports	Yes	custom
Command and shell sandboxing	No	Yes
Works without MCP	Yes	hook endpoint
Open-source core	Yes	Yes

Decision framework

Choose Veto when

The agent action lives inside your app or framework, not only behind MCP
A buyer asks how this specific workflow is approved and evidenced
You need decision records that map to tenants, policies, reviewers, and exports
You want a narrower authorization layer before adding a broad local gateway

Choose Airlock when

Most tools are already exposed through MCP servers
Tool hiding, command allowlists, and sandbox presets are the immediate need
Approvals around coding-agent tools are the primary workflow
You want a local gateway with SQLite audit logs and configurable middleware

Scenario

You need to secure Claude Code, Cursor, OpenClaw, or another MCP client locally.

Start with

Airlock

Why

Airlock's gateway model is built for MCP clients. It can hide tools, gate commands, route approvals, log calls, and apply sandbox variants without changing every downstream tool.

Scenario

Your SaaS product has one high-risk action that blocks customer rollout.

Start with

Veto

Why

The buyer cares about whether that exact action can run, who reviewed it, which policy applied, and whether evidence is retained. That maps directly to Veto's runtime authorization workflow.

Scenario

You need broad command policies for developer agents.

Start with

Airlock

Why

Airlock has built-in exec and HTTP tooling, deny lists, command-level approval, sandbox presets, and approval channels that fit local developer-agent governance.

Scenario

You have LangChain, OpenAI, Vercel AI SDK, or app-native tools outside MCP.

Start with

Veto

Why

Veto does not require MCP to be the control plane. It wraps the tool call in the runtime you already use and can still integrate with MCP when that path is present.

Where Veto gets pulled in

Coding agents

Risk: The agent can push code, run shell commands, install packages, edit files, or call internal endpoints.
Veto fit: Use Veto for the product or deployment actions where approvals and decision records must survive beyond a local dev session.

MCP tool catalogs

Risk: A client sees too many tools, including write tools that should be hidden or gated.
Veto fit: Pair gateway-level tool shaping with Veto on the highest-risk downstream actions that need tenant-aware policy and buyer evidence.

Customer-facing AI operations

Risk: The agent can update customer records, send messages, change account state, or trigger external workflows.
Veto fit: Put those actions behind allow, deny, or require-review decisions even if the rest of the tool surface is managed elsewhere.

Regulated workflow pilots

Risk: A buyer will not approve the pilot unless risky actions have review, records, and an export path.
Veto fit: Use Veto as the buyer-facing control evidence layer around the production action.

Public references checked

Airlock home page

Public positioning reviewed for MCP gateway architecture, allowlists, approvals, SQLite audit logs, middleware, sandboxing, and approval channels.

Model Context Protocol specification

Referenced to validate the MCP gateway search intent and the role of MCP clients and servers in tool-calling stacks.

Veto MCP authorization page

Internal source for Veto's MCP-layer positioning and the distinction between gateway identity and per-call authorization.

Frequently asked questions

Does Airlock replace Veto?

Not usually. Airlock is strongest as a gateway around MCP tool surfaces. Veto is strongest as the runtime authorization and evidence layer around a specific governed action. If all tools run through MCP and local approvals are enough, Airlock may be sufficient. If the buyer needs product-level evidence, reviewers, policies, and exports, Veto addresses a different layer.

Can Veto run behind Airlock?

Yes. Airlock can shape which MCP tools are visible and which calls require gateway approval. Veto can still sit inside the downstream tool or app and evaluate the actual business action with tenant, policy, argument, and reviewer context.

Which is better for coding agents?

Airlock is the better first fit for local coding-agent command control because it includes MCP gateway behavior, exec policies, HTTP policies, approval channels, and sandbox variants. Veto becomes relevant when the coding agent can trigger production product actions that need durable buyer-facing evidence.

Which is better outside MCP?

Veto is the more direct fit outside MCP because it wraps the tool execution path in the application or framework. Airlock has a hook endpoint, but its public product shape is still the MCP gateway.

Related comparisons

Veto vs Pomerium for MCP

Identity-aware MCP gateway versus per-call authorization.

Veto vs OpenLeash

Local sidecar authorization versus SDK-native product workflows.

Browser agent security

Authorization patterns for web and browser automation agents.

Tool-call authorization

Definition and examples for per-call policy enforcement.

Put the risky action under policy before it runs.

Open source SDK. Local evaluation. Human review when policy requires it.