Quickstart
From an existing agent project to real, server-side decisions on its tool calls, in one command.
This gets you to a decision you can point at: an ALLOW or BLOCK recorded
against an agent identity you created, for a tool your agent really calls,
visible in the console and in the audit trail.
You need Node 20.10 or newer and an agent project. No account is needed up front: you can create one when the browser opens.
Install the CLI
bashnpm install -g veefore
One CLI for every project. Check it with veefore --version.
Run it in your agent project
bashcd your-agent-project
veefore
The CLI connects to Veefore by itself. Every other address it needs, such as the gateway, comes from Veefore rather than from you.
Self-hosted Veefore
If your organization runs its own Veefore, name it the first time:
veefore --control-plane https://veefore.your-company.com. The CLI remembers
it, and a project that is set up records it in veefore.config.json, so
teammates never type it.
From here veefore walks you through the rest. Each part is below.
Sign in, in the browser
The CLI opens the console. Sign in there (or create an organization), with SSO and MFA if your organization uses them, and approve the terminal after checking that the code on the page matches the one in your terminal.
textSign in to Veefore https://veefore.example.com
Opened your browser to finish signing in.
Confirm the browser shows this code: KX7P-4MRT
✓ Signed in as dev@company.com in Acme (DEVELOPER)
The terminal never handles your password. Over SSH, veefore login --device
prints a link and a code to enter in any browser instead. In CI, use
VEEFORE_EMAIL and VEEFORE_PASSWORD. See Authentication.
Review what it found
The project is scanned on your machine. Nothing is uploaded, .env files are
never opened, and credentials are reported by name only.
text✓ Framework: Vercel AI SDK (typescript)
✓ Found 2 tools:
lookup_order LOW src/agent.ts:6
calls orders.acme.internal
refund_customer HIGH src/agent.ts:14
calls api.stripe.com
! Your code reads 1 credential: STRIPE_SECRET_KEY (names only; values were not read)
Veefore will set up
• Agent support-agent in Development
• 2 tools, each with its own capability, authorized for this agent only
• A starter policy, in OBSERVE mode: decisions are recorded, nothing is blocked yet
Set this up? [y/N]
Answer once. Veefore creates the agent with a key pair generated on your machine (only the public key is sent), registers each tool with its own capability, authorizes it for this agent alone, and adds the starter policy.
It writes veefore.config.json (no secrets, commit it) and .env.local (the
private key, mode 0600, gitignored). Veefore cannot recover the private key;
move it into your secret manager before deploying.
Accept the code change
Each tool's function is wrapped in guard(), so Veefore decides every call
before your code runs. You see the diff first:
diff+import { guard } from '@veefore/sdk';
...
- execute: async ({ amount }) => {
+ execute: guard('refund_customer', async ({ amount }) => {
return stripe.refunds.create({ amount });
- },
+ }),
Your function bodies are not edited. Files are backed up, your own typecheck
runs afterwards, and if it newly fails every file is put back automatically.
veefore undo reverses the change at any time.
Tools the rewrite will not change on its own are yours to choose: exact instructions to do it by hand, AI with your own model key, or Veefore AI. See Automatic setup.
Then install the SDK the change imports:
bashnpm install @veefore/sdk
bashpip install veefore-py
Run your agent and watch
bashveefore dev
Run your agent as you normally do, from the project directory. Every protected call streams in with the decision, the rule that produced it, and the next step.
New environments start in OBSERVE, so calls execute and Veefore records what
enforcement would have decided:
json{
"decision": "ALLOW",
"outcome": "OBSERVED",
"mode": "OBSERVE",
"shadow": { "decision": "REQUIRE_APPROVAL", "reason": "Tool is flagged dangerous." }
}
Read that carefully
decision is the effective decision. shadow.decision is what enforcement
would have done. In OBSERVE the two can disagree, and when they do, the
action still happened. OBSERVE is for learning, never for safety. See
Enforcement modes.
Prove the policy, then enforce
bashveefore policies test
veefore deploy --mode ENFORCE --reason "Refund policy reviewed and approved"
Preflight replays your recent observed traffic and shows exactly which calls
start being refused before anything changes, then asks for confirmation, a
reason and step-up. Under ENFORCE, a refused tool throws in your agent and its
body never runs.
#Check your work
bashveefore integrate --check # every registered tool goes through Veefore
veefore doctor # the whole security posture
doctor audits MFA, TLS, local file permissions, identity and passport
validity, gateway health, dangerous tools permitted only by a default decision,
network restrictions, policy coverage, audit chain integrity, credential age and
SDK version drift. --strict makes warnings fail too, which is what you want in
CI.
#What to read next
What the scan finds, what setup creates, and every option for the code change.
guard() and the full client: errors, approvals, policy inputs.
Take the API key out of the agent, so skipping the SDK gets it nothing.
OBSERVE → SIMULATE → ENFORCE, and how to know you are ready to move.