Architecture / System design

Changelog

What shipped, and what changed in the documentation.

#1.0.0 — 4 October 2026

The Veefore starting product, available hosted or self-hosted.

#Setup

• veefore, run in an agent project, does the whole integration: browser sign-in, a local scan, one confirmation, then the code change. The hosted service is found with no address; a self-hosted one is named once and remembered.
• Browser sign-in for the CLI with PKCE, and a device code flow for SSH. The terminal never handles a password.
• Project scanner for the Vercel AI SDK, OpenAI function tools, the OpenAI Agents SDK, LangChain, CrewAI and MCP servers, in TypeScript and Python. Reads code, never runs it, never opens .env.
• guard() in both SDKs, and veefore integrate to add it: a diff first, backups, your own typecheck, automatic rollback, and veefore undo.
• Tools the rewrite cannot change safely: exact manual instructions, AI with your own Anthropic or OpenAI key, or Veefore AI. Secrets are redacted before sending and the reply is validated before it is shown.
• CLIENT tools: Veefore decides and records, your code executes. Re-register as HTTP with a brokered credential to close the gap, with no code change.

#Identity and authority

• Agent identity: one Ed25519 key pair per agent, generated locally by default so the private half never crosses the network. Generation counters, so a rotated key is refused with a specific code rather than a generic failure.
• Agent Passport: signed, versioned, exportable. Identity, never the authorization decision.
• Capabilities, with tool authorization as a deliberately separate step.
• Delegated authority with the hard invariant that a child can never exceed its parent — refused, not clamped — and revocation that cascades at every depth, immediately.

#Policy and enforcement

• Deterministic, total policy evaluator over a closed field set, with a visual builder, versioning, structured diff, recorded test cases, simulation and rollback.
• Strictness precedence: BLOCK > REQUIRE_APPROVAL > STEP_UP_AUTH > LIMIT > MASK > ALLOW. Effects merge conservatively.
• Rego export, for teams already running OPA. The TypeScript IR stays authoritative.
• Gateway with OBSERVE / SIMULATE / ENFORCE, and complete action lineage on every decision.
• Twelve-stage pipeline with the credential broker at stage 10 — after everything that can refuse.

#Risk, approval, trust

• Risk engine with thirteen named signals, each contributing a weighted amount and a human-readable explanation. No opaque model.
• Human approval with SINGLE / GROUP / QUORUM / SEQUENTIAL routing, quorum, escalation, expiry, and binding to the specific request that created it.
• Trust evidence: typed, expiring, and testable from policy.

#Credentials

• Credential broker issuing short-lived, scoped leases to the tool runtime, never to the agent.
• Seven credential types. No endpoint returns material.
• Material validation at registration and rotation, so a secret under an unrecognised key is refused rather than failing two layers away.

#Protocols

• MCP gateway with discovery and per-tool authorization as separate steps.
• A2A gateway with passport verification against a registered key, and immediate blocking.
• Private agent registry for internal discovery.

#Audit and security

• Tamper-evident audit: keyed hash chain, localised break detection, watermarked and hashed exports.
• Security Center with seven emergency controls, each with a side-effect-free blast radius preview and confirm_blast_radius on execution.
• Incidents that policy can react to through trust.active_incidents.

#Interfaces

• TypeScript and Python SDKs with identical wire behaviour and byte-identical canonicalisation.
• TypeScript SDK @veefore/sdk (ESM and CommonJS) and Python SDK veefore-py.
• veefore CLI (npm package veefore): scan, init, integrate, undo, dev, doctor, status, test, agents, policies, logs, audit, deploy, login, logout.
• REST API, webhooks with HMAC signing, SSO, SCIM, IP restrictions.
• Console: 10 navigation groups, dark mode designed rather than inverted, no purple.

#Operations

• Three processes over one PostgreSQL. Both planes stateless.
• Prometheus metrics, OpenTelemetry traces with one span per pipeline stage, structured logs with redaction applied on ingest.
• Row-level security as an independent second isolation layer.
• npm run verify: 23 stages including a scope audit and a quality audit that fail the build on out-of-scope or faked functionality.

#Deliberately absent

Wallet, marketplace, agent commerce, payment processing, settlement, money movement, financial transaction ledger, smart contracts, merchant acquiring, payouts, agent purchasing, marketplace reviews.

Not gaps. Enforced by npm run scope:audit, which checks naming and schema shape — no balance column may exist, and an amount column may only appear on a policy or decision table. → Scope

#Documentation

#4 October 2026

First release of this site. Static, and partly generated from the product's own registries.

Generated from source — these cannot drift:

The build is the check. npm run docs:check fails on a broken internal link, an anchor pointing at a heading that does not exist, a page missing from the navigation, a page in the navigation with no file, an API group added to the catalogue without an explanation, or an error code with no documented status group.

The last two are the ones that matter: a new API surface cannot ship undocumented, and a new error code cannot ship unexplained.

For agents as well as people. Every page is available as plain Markdown at /_llms/<slug>.md, and the whole site is indexed at llms.txt with a description per page.

Thirteen decision records, each with the context, the decision, the alternatives considered and the consequences accepted — including why a TypeScript policy IR rather than OPA, which is the decision most likely to be questioned.

#Release policy

Semantic versioning. Within v1 the wire contract does not break: new fields are added, existing fields keep their meaning. A breaking change would arrive as v2, served alongside v1, with v1 supported through a deprecation window.

There is no silent change to the meaning of an existing field, which is the one thing a client cannot defend against.

Security releases may bypass the normal feature cadence, and still carry full audit and change documentation — the same step-up, reason and CRITICAL auditing as any other authorization change.