Veefore documentation

Identity, authority, policy and enforcement for autonomous AI agents. Give an agent real power without giving it unlimited power.

An AI agent that can only talk is safe and not very useful. An agent that can issue a refund, write to a database or call a partner API is useful and no longer safe by default. Veefore is the layer in between: it gives every agent a cryptographic identity, a bounded grant of authority, a policy that is evaluated on every single action, and a record of what was decided and why.

The boundary is the gateway, not your code

Enforcement happens server-side, in a process your agent does not control. The SDK is a convenience. Deleting it does not widen what an agent may do, because the credentials the tool needs are held by the broker and released only after a request has been permitted. An agent that bypasses the SDK finds it has nothing to call with.

#Start here

Quickstart

One command in your agent project, then a real decision, in about ten minutes.

How it works

The twelve stages a protected action passes through, in order.

Self-host Veefore

Run the control plane, the gateway and the console on your own infrastructure.

What Veefore is not

The deliberate exclusions. Worth reading before you design around it.

#Get started in one command

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

The CLI opens your browser to sign in or create an organization, finds your agent's framework and tools, registers them after you confirm, and wraps each tool so Veefore decides every call. Nothing to deploy: it connects to hosted Veefore. If your organization runs its own, see Self-host Veefore.

#What you get

A real identity per agent. Each agent holds an Ed25519 key pair and signs every request. The private half can stay on your machine and never reach Veefore at all. Revocation is immediate and terminal; a revoked key cannot be un-revoked. See Agent identity.

Authority that is bounded and provable. Capabilities say what an agent is for. Delegations narrow that further, and a child grant can never exceed its parent — attempts are refused with DELEGATION_ESCALATION, not silently clamped. See Delegated authority.

Policy that is deterministic and explainable. Rules test a closed set of fields with a fixed set of operators. The same input always produces the same decision, and every decision names the rule that produced it. Policies are versioned, diffable, testable and roll back cleanly. See Policy.

Three enforcement modes, in a deliberate order. OBSERVE records what enforcement would do while letting everything through. SIMULATE runs the full pipeline without touching an external system. ENFORCE refuses. You walk them in order so nothing surprising happens in production. See Enforcement modes.

Humans in the loop where it matters. A policy can require approval, and the approval is bound to that specific request — approving once does not grant a standing permission. See Approvals.

Credentials the agent never holds. The agent asks Veefore to perform an action. Veefore decides, then brokers a short-lived, scoped credential to the tool runtime. An agent that leaks its prompt leaks nothing usable. See Credential broker.

An audit trail you can prove is intact. Events are hash-chained, exports are watermarked and taking an export is itself an event. See Audit.

#The shape of the system

Two request-serving processes and a worker over one private database. Agents reach the gateway and nothing else.

Described in text

People, the console, the CLI and CI reach the control plane on /v1. Agents reach the gateway on /gateway/v1, and nothing else — the crossed path in the diagram is the one that must not exist in your ingress configuration. Both planes are stateless and share one PostgreSQL database that is private to them. A worker runs the job queues.

The split is not cosmetic. The gateway is the only process agents can reach, it has a smaller surface, and it can be scaled and hardened independently of the management API. See Request path for the full walkthrough, or Gateway architecture for why it was built this way.

#Pick your path

I am adding Veefore to an agent

Run veefore, review the tools, write your first policy, go to enforce.

I am operating Veefore

Day-to-day controls, runbooks and, for self-hosted installs, deployment.

I am reviewing the security model

The boundary, the threat model, fail-closed behaviour and tenant isolation.

I need an exact signature

Every endpoint, error code, permission, policy field and CLI flag.

#A note on reading this

Pages under Reference marked as generated are built from the product's own registries at build time — the API catalogue the console reads, the error table the HTTP layer throws from, the permission list RBAC is computed from. They cannot drift from the running system, because the build fails if the source and the page disagree.

Every page is also available as plain Markdown at /_llms/<slug>.md, and the whole site is indexed in llms.txt. If you are pointing a coding agent at these docs, point it there.