For agentic AI vendors
Pass customer review before your agents act.
Your buyer wants the agent. Their security team asks what stops a payment release, loan escalation, prior auth, claim update, MCP data write, or case change before it runs. Veto gives each tenant a policy check, approval route, and decision record at the governed tool path.
ScalePer-tenant policy, embedded review, and multi-region managed cloud
import { Veto } from 'veto-sdk'
const veto = await Veto.init({ apiKey: process.env.VETO_KEY })
// Per-tenant scoping at the call site.
const guardedTools = veto.wrap(rawTools, {
context: {
tenant: session.customerId,
actor: session.userId,
},
})
await agent.run({ tools: guardedTools })
Same SDK. Tenant and actor context travel with each governed call.
Two shapes, one meter
Internal agents and customer-facing products use the same control model.
Internal agents are the default shape: your team runs a handful of named production agents against your own systems. Teams land on Core or Growth.
Multi-tenant platforms are the other shape. Your customers run agents through your product, often on their own users, data, and tools. Same SDK and meter, with per-tenant scoping at the call site.
The winning wedge is not a governance program. It is the first risky workflow your customer cannot ship without approval, denial, and a record they can inspect.
The base pricing model stays intact. Multi-tenant shape lands on Scale when it needs per-tenant policy scoping, embedded human review, and multi-region managed cloud. BYOC, on-prem, and isolated-network deployments move to Enterprise. Past 10M governed actions per month, overage is $0.20 per 1,000.
Primitives
Four primitives for vendor trust.
The product story is simple: your agent can act, but every governed action has tenant-aware policy, review, and evidence before execution.
Governed calls, not seats.
Each allow, deny, and review-required verdict is a governed action. The meter follows the checks Veto performs before execution, not your seat count or tenant count.
Per-tenant policy at the action.
Each customer gets its own policy boundary. Policies, approvals, decision records, API keys, and rate limits stay tenant-aware so one tenant's rule never becomes everyone else's control.
Review inside your product.
Approval links can live in your surface: your theme, your auth, your domain. Veto stays in the control path while decision records remain available for evidence review.
Multi-region, pinned per tenant.
Pin tenants to the managed region their contract requires. BYOC, dedicated, and isolated-network deployments move through Enterprise review.
Built for the shape of
AI products that touch money, records, and customers.
The common shape: your customer buys the agent surface, but the agent acts for that customer's users, data, and tools. Veto gives each tenant its own policy boundary without forcing a separate control stack per customer.
- Payment, banking, lending, and wealth agents sold into regulated financial workflows
- Prior-auth, claims, revenue-cycle, and insurance agents that submit or update records
- MCP and workflow platforms where customer agents can write tenant data
- Voice, browser, and task agents that trigger customer-facing operations
- Public-sector and regulated SaaS products where each tenant needs its own evidence trail
First risky workflows
The buyer question is usually this concrete.
Start with the action that would pause procurement if it ran without policy: money movement, loan workflow, MCP data write, payer submission, claim update, customer message, or case change.
Your end users should not need to meet Veto. Approval flows live in your product. Policies are scoped to your tenants. Decision records can stay under your compliance boundary. Veto is plumbing. Your brand is the surface.
Customer review packet
What your buyer can inspect before rollout.
The product is not a new dashboard to sell. It is evidence for the one risky workflow blocking a pilot, procurement review, carrier review, bank review, or agency rollout.
Action map
The exact tool call your customer worries about, with tenant, actor, and system context.
Policy path
The allow, review, and deny rules that decide what happens before execution.
Review route
Where the approval lives in your product, with the human or team who can say yes.
Decision record
The exportable record: tool, arguments, policy, verdict, tenant, actor, and reviewer.
Pricing
Same ladder. Multi-tenant lands on Scale.
One structure covers internal agents, embedded platforms, and enterprise. The meter is governed actions; tenant count, seats, and product surfaces do not become hidden meters.
Scale
- Per-tenant policy scoping
- White-label human review on your domain
- Multi-region managed cloud
- SSO (SAML/OIDC) and SCIM provisioning
- Decision records per tenant
Past 10M governed actions per month or procurement-led: Enterprise adds custom volume tiers, BYOC, isolated-network deployment terms, and a named founder plus engineering owner.
Platform intake
Bring the action your buyer is worried about.
Send the exact action blocking one customer: what the agent can do, who the tenant is, where review belongs, and which record the buyer needs. We will respond within 24 hours.
Prefer async? Share a one-paragraph shape note and the nearest reference product.