Policy Packs

Veto ships with 11 built-in policy packs. A pack is a YAML policy you can extend, then override or append rules in your own veto/rules/*.yaml files.

version: "1.0"
extends: "@veto/coding-agent"

rules:
  # Override an inherited rule by reusing its id.
  - id: coding-agent-block-dangerous-shell-commands
    name: Override shell command block
    action: block
    tools: [run_shell]
    conditions:
      - field: arguments.command
        operator: contains
        value: shutdown

  # Add a new rule alongside inherited rules.
  - id: custom-prod-path-guard
    name: Block writes to prod path
    action: block
    tools: [write_file]
    conditions:
      - field: arguments.path
        operator: starts_with
        value: /prod

Use a pack

Short names and scoped names both work:

npx veto init --pack soc2-lite

Equivalent scoped form:

npx veto init --pack @veto/soc2-lite

For new TypeScript apps, pass the same pack name to create-veto-app when scaffolding rules:

npm create veto-app -- my-agent --template node-ts --pack soc2-lite --yes
npm create veto-app -- my-agent-scoped --template node-ts --pack @veto/soc2-lite --yes

The current TypeScript SDK enforces the live policy configured in Veto Cloud. It does not accept a pack option in protect(); initialize or upload the pack first, then wrap tools with the SDK:

import { protect } from "veto-sdk";

const guardedTools = await protect(tools);

Merge behavior

When extends is set:

1. Veto loads the parent pack first.
2. Veto merges your rules and output_rules on top.
3. If your rule ID matches a pack rule ID, your rule fully replaces the pack rule.
4. New rule IDs are appended after pack rules.

If the pack name is invalid, Veto logs an error and skips that policy file.

Available packs

@veto/coding-agent

Purpose: block dangerous shell behavior and sensitive file writes.

Themes:

• destructive command blocking
• sensitive system path write restrictions
• path traversal write protection

@veto/crypto-trading

Purpose: conservative defaults for crypto exchange and prediction market agents.

Themes:

• allow read-only market, portfolio, position, and history tools
• cap leverage, single-position size, and prediction market bet size
• block withdrawals, margin borrowing, and unsafe stop-loss removal
• require approval for larger trades, bets, leverage changes, position closure, mass cancellation, internal transfers, and redemptions
• require research before action, including price/portfolio or market-detail checks
• apply session budget defaults and night-time leverage restrictions

@veto/financial

Purpose: enforce transfer limits, currency controls, and cumulative transfer caps.

Themes:

• per-transaction approval thresholds
• currency allowlists
• cumulative transfer caps within a session window

@veto/browser-automation

Purpose: reduce browser automation abuse from risky URLs, password field input, and automatic submissions.

Themes:

• block dangerous URL schemes and loopback targets
• block automated typing into password fields
• block direct form submission tools

@veto/data-access

Purpose: protect database access and sensitive query outputs.

Themes:

• block common SQL injection payload patterns
• limit requested row counts
• redact email addresses and US Social Security numbers from outputs

@veto/communication

Purpose: protect messaging and email flows.

Themes:

• require approval for mass recipients
• block credential-like content in messages
• redact phone numbers and emails from messaging outputs

@veto/deployment

Purpose: enforce review for production changes.

Themes:

• require approval for production deploy, publish, release, and rollback operations
• block force or skip-check deployment flags

@veto/economic-agent

Purpose: add cost-aware authorization defaults for agents that spend money.

Themes:

• require approval for high-value tool calls
• block unrestricted financial tools such as transfers and withdrawals
• configure session budgets, approval thresholds, cost extraction, payer validation, and denial reasons

See Economic Authorization for the full guide.

Compliance starter packs

The compliance starter packs are guardrails operators must review, tune, and map to their own controls, policies, risk classifications, and approval processes. They do not make an app compliant and are not SOC 2, HIPAA, or EU AI Act certification.

@veto/soc2-lite

Starter guardrails inspired by SOC 2 control themes:

• require approval for destructive shell, file, and database operations
• require approval for production release actions
• block audit log and evidence export tampering
• require review before exporting audit logs or control evidence
• redact common API keys, tokens, passwords, and private key material from outputs

Example:

npx veto init --pack soc2-lite

@veto/hipaa-lite

Starter guardrails inspired by HIPAA privacy and security themes:

• require approval before external PHI-like email, upload, export, or HTTP transfer
• block unapproved PHI network sends when context does not indicate approval
• require context for patient or medical record access
• require approval for bulk patient or clinical record exports
• redact patient identifiers, SSNs, and date-of-birth values from outputs

Example:

npx veto init --pack hipaa-lite

@veto/eu-ai-act-starter

Starter guardrails inspired by EU AI Act operational themes:

• require human oversight for high-risk or consequential decisions
• preserve audit, model, risk, and incident logs
• require approval for autonomous consequential actions
• require transparency review before user-facing notifications or final decisions
• log high-risk decision outputs for audit review
• redact unsupported legal compliance claims until reviewed

Example:

npx veto init --pack eu-ai-act-starter

Runtime behavior

protect() and veto.wrap() do not auto-apply packs or silently fall back to allow-all behavior. They call Veto Cloud before executable tools run. If you need a pack, initialize it with the CLI or configure it in the dashboard before deploying the wrapped tools.