Architecture

fastpace is three things at once: a CLI that runs on your developer machine, a set of hooks that mediate every AI tool call, and a small family of signed artifacts that gives auditors a paper trail.

One control plane, three assistants

Everything below is vendor-neutral by construction. The hook scripts are written once against a canonical event model (hook-manifest.js) and generated into each assistant's native plugin shape by fastpace plugin build — a Claude Code plugin, a Codex plugin, and a Gemini CLI extension. The same write-once pattern covers policy (fastpace plugin policy compiles fastpace.policy.yaml to Claude permissions, Codex requirements.toml, and Gemini Policy-Engine rules, with a native-vs-advisory coverage matrix) and domain context (fastpace plugin context projects fastpace/context/ into CLAUDE.md / AGENTS.md / GEMINI.md). On top sits fastpace posture — provenance coverage, audit-chain integrity, shadow-AI, cross-vendor assistant mix, per-vendor policy conformance — one payload feeding the local UI, org dashboard, and trust portal.

The substrate

Every artifact fastpace produces is signed against one cryptographic identity per install (F0.1: Ed25519, generated locally, private key never transmitted). Every entry in the audit log (F0.2) hash-chains to its predecessor — editing any entry breaks every later entry's signature. This is the substrate that makes everything else above it auditable.

The four layers

Layer 0 — Discovery + identity (Tier 0)

• F0.1 cryptographic identity
• F0.2 hash-chained signed audit log
• F0.3 discovery manifest (per-machine + per-repo)
• F0.4 agent identity manifest with frontmatter scopes
• F0.5 prompt redactor (UserPromptSubmit hook)
• F0.6 fastpace inventory

Layer 1 — Agent governance + access (Tier 1)

• F1.1 run-manifest signing
• F1.2 blast-radius limits
• F1.3 circuit breaker + fleet baselines
• F1.4 fastpace agents log
• F1.5 NHI registry export
• F1.6 least-privilege bootstrap (fastpace grant)
• F1.7 MCP scope mediation
• F1.8 + F1.9 exception workflow + coach agent
• F1.10 sensitivity-tagged context
• F1.11 approved-runtime registry
• F1.12 sanctioned-install attestation (with Sigstore envelope)
• F1.13 standalone @fastpace-ai/org-dashboard
• F1.14 RBAC + SCIM + SAML envelope verifier
• F1.15 validated framework mapping

Layer 2 — Reliability + provenance + governance (Tier 2)

• F2.1 AI reliability score (with LCS-based blame)
• F2.2 explainability bundles
• F2.3 provenance-signed commits
• F2.4 AI-BOM (CycloneDX-AI flavor)
• F2.5 continuous control monitoring
• F2.6 trusted data taps
• F2.7 red-team scenario harness
• F2.8 Drata / Vanta / Secureframe push
• F2.9 pre-merge audit gate
• F2.10 AI risk register
• F2.11 org-wide policy bundle
• F2.12 open audit schema export
• F2.13 SAST / lint required hook
• F2.14 coach feedback loop

Layer 3 — Org-scale + extensions (Tier 3)

• F3.1 hash-chain export bundle for offline verification
• F3.2 air-gapped install bundle
• F3.4 onboarder agent
• F3.5 fastpace me per-developer dashboard
• F3.6 mobile-friendly local UI
• F3.8 self-healing context refresh
• F3.9 per-team budget caps
• F3.10 webhook event bus
• F3.11 audit log replication contract

Trust boundaries

Three boundaries delineate the system. Read the threat model for the STRIDE walk against each.

1. Developer machine ↔ AI runtime. Crossed every time an agent calls the runtime. F0.5 prompt redactor + F1.11 runtime guard mediate.
2. Repo ↔ org dashboard. Crossed when a repo's signed summary is ingested by the org dashboard. Each summary verifies against a configured trusted-keys map.
3. Org ↔ external authority. Crossed when (a) the org admin publishes a signed policy bundle (F2.11) and (b) the SAML IdP issues an envelope (F1.14). Each direction is signed; fastpace verifies against the configured public key.

What runs where

• @fastpace-ai/fp — the CLI binary + local UI server. Runs on the developer machine.
• @fastpace-ai/org-dashboard — optional. Self-hosted HTTP server that aggregates signed summaries from every repo.
• @fastpace-ai/trust-portal — public-facing. Static Astro deploy hosting attestations + sub-processor list + evidence-request flow.
• @fastpace-ai/website — the marketing site at fastpace.net.
• @fastpace-ai/docs — this site.
• @fastpace-ai/license-service — fastpace-operated, runs on api.fastpace.net. Issues + refreshes signed licenses and short-lived bearer access tokens. Verification is offline against the bundled issuer pubkey, so customer org-dashboards never call it on the request path.

There is no fastpace SaaS in the customer data path. The only fastpace-operated infrastructure is the marketing site, the trust portal, this docs site, the npm registry, and the licensing service — and the licensing service is only contacted to mint or refresh credentials, never on per-request reads.

Licensing & access-token gate

fastpace ships under the Elastic License 2.0: source-available, free for all internal commercial / educational / research use, permanently prohibits managed-service offerings and license-key circumvention. Two signed artifacts secure the paid tier (Team and above):

• License file at ~/.fastpace/license.json — long-lived (90 days online, 365 days air-gap), checked locally by every requireTeam() call.
• Access token at ~/.fastpace/access-token.json — short-lived (7 days online, 365 days air-gap), sent as Authorization: Bearer <...> on every CLI/script call to a self-hosted org-dashboard's gated read endpoints. The dashboard verifies offline against the bundled Ed25519 issuer pubkey.

Both share the same issuer key. Revocation is "stop minting" — a cancelled customer keeps their license file working through its remaining ~90 days but loses bearer-token access in ≤ 7 days. Air-gapped enterprise installs receive 365-day tokens alongside their annual license bundle. The dashboard's FASTPACE_ORG_REQUIRE_TOKEN env flag is opt-in for the v0.34 → v0.45 grace window; defaults to on at v0.45.