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
bashnpm 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.
What veefore finds, creates and changes, and how to do any part by hand.
The full integration: config, guard(), errors, approvals.
A real policy built one rule at a time, from real traffic.
Make your system something an agent can be authorized for.
Take the secret out of the agent entirely.
#Pick your language
@veefore/sdk. guard(), the client surface, typed errors.
veefore-py. Same model, same wire format, same guarantees.
The wire protocol in full. Any language that can sign Ed25519.
#The integration, in order
- Install the CLI with
npm install -g veefore. - Run
veeforein the agent project. It signs you in, registers the agent and its tools, and wraps each tool inguard(). - Review the tools it registered, and add any it missed.
- Move the credentials into the broker so the agent no longer holds them.
- Write a policy from what you observed, not from what you assumed.
- Handle refusals properly — this is the step that gets skipped.
- Gate CI so a policy regression fails the build.
- 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.