Veefore docs

Build with Veefore

Everything you need to protect an agent, wire up its tools, and ship it behind enforcement.

This section is the developer path. All you need is an agent you want to put behind Veefore. The CLI connects to hosted Veefore on its own; if your organization runs its own, it gives you the address once (Self-host Veefore).

#The shortest route

bash
npm install -g veefore
cd your-agent-project
veefore

One command signs you in through the browser, scans the project, registers the agent and its tools, and wraps each tool in guard(). Every step asks first. Automatic setup explains exactly what it does.

#Pick your language

#The integration, in order

  1. Install the CLI with npm install -g veefore.
  2. Run veefore in the agent project. It signs you in, registers the agent and its tools, and wraps each tool in guard().
  3. Review the tools it registered, and add any it missed.
  4. Move the credentials into the broker so the agent no longer holds them.
  5. Write a policy from what you observed, not from what you assumed.
  6. Handle refusals properly — this is the step that gets skipped.
  7. Gate CI so a policy regression fails the build.
  8. Promote to ENFORCE.

#Everything else

Delegate authority Sub-agents and bounded grants
Handle approvals Waiting on a human without blocking a worker
MCP Register servers, authorize discovered tools
A2A Verified connections to agents you do not own
API keys Programmatic access for your own services and CI
Webhooks Signed delivery, and why a webhook is not an authorization
Errors and retries Which refusals to handle, which never to retry
Idempotency Safe retries on mutating requests
Local development Fast loop, fake downstreams, real decisions
Examples Four working programs in examples/

#Two things worth internalising first

The SDK is not the boundary

Every decision is computed server-side by the gateway, on every call. The SDK formats requests, signs assertions and gives you typed errors. It cannot grant authority and it does not cache a permission.

The practical consequence: do not build logic that depends on the SDK having checked something. It has not. Branch on decision.allowed, which is the server's answer.

A refusal is an answer, not a failure

BLOCK, REQUIRE_APPROVAL, AUTHORITY_EXCEEDED, APPROVAL_DENIED — these are decisions. Retrying produces the same decision and burns your rate limit.

Retry transport errors and 503s with backoff. Never retry a 403. The SDK already follows this rule: it retries transport failures and never retries a decision. Full table.

Identity, authority, policy and enforcement for autonomous AI agents.