---
title: Veefore documentation
description: Identity, authority, policy and enforcement for autonomous AI agents. Give an agent real power without giving it unlimited power.
label: Introduction
---

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.

:::security 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

:::cards

:::card Quickstart | /quickstart | ▶
One command in your agent project, then a real decision, in about ten minutes.
:::

:::card How it works | /how-it-works | ◎
The twelve stages a protected action passes through, in order.
:::

:::card Self-host Veefore | /install | ⬒
Run the control plane, the gateway and the console on your own infrastructure.
:::

:::card What Veefore is not | /scope | ⊘
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](/install).

## 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](/concepts/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](/concepts/delegation).

**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](/concepts/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](/concepts/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](/concepts/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](/concepts/credentials).

**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](/concepts/audit).

## The shape of the system

:::diagram planes | Two request-serving processes and a worker over one private database. Agents reach the gateway and nothing else.
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](/architecture/request-path) for the full
walkthrough, or
[Gateway architecture](/architecture/adr/0002-gateway-architecture) for why it
was built this way.

## Pick your path

:::cards

:::card I am adding Veefore to an agent | /build | ⌨
Run `veefore`, review the tools, write your first policy, go to enforce.
:::

:::card I am operating Veefore | /operate | ⚙
Day-to-day controls, runbooks and, for self-hosted installs, deployment.
:::

:::card I am reviewing the security model | /secure | ⛉
The boundary, the threat model, fail-closed behaviour and tenant isolation.
:::

:::card I need an exact signature | /reference | ≡
Every endpoint, error code, permission, policy field and CLI flag.
:::

:::

## A note on reading this

Pages under [Reference](/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](/llms.txt). If you are pointing a coding
agent at these docs, point it there.