Security

This page describes how Sextant is built and delivered, written for a security or procurement reviewer. Every claim below is checkable in the source you install. If you need anything more — a signed questionnaire, an SBOM, or a deeper walkthrough — email hello@sextant.sh.

1. Client-side-only by design

Sextant widgets are pure React + Recharts components. They render the data you pass them, inside your application, on the client. A widget makes no network calls of its own: it sends no telemetry, phones no home server, and requires no Sextant API key or account at runtime. Data you hand to a widget never leaves the browser — there is no Sextant backend in the rendering path to leave it to.

• No telemetry. Widgets contain no analytics, beacon, or usage-reporting code. You can confirm this by grepping the source you install.
• No data egress. The chart geometry and the narrative are derived locally from the props you provide; nothing about your data is transmitted by the widget.
• Optional, you-controlled networking only. Two helpers can make requests, and only when you opt into them and point them at your own endpoints: the MCP data-binding hook (useBoundData) fetches from a route in your app (default /api/sextant/bind), and the PNG export helper fetches images referenced by your own DOM. Neither targets a Sextant server, and neither is required to render a chart.

2. Deterministic narratives — no LLM, no AI runtime

The “intelligence” in Sextant — the one-sentence explanation of a chart (runway in months, the biggest variance driver, NRR, and so on) — is computed in pure TypeScript from your data. There is no LLM, no inference call, no external API, and no hallucination surface. The same input always produces the same narrative, which means there is no runtime AI dependency to review, budget, or rate-limit, and no prompt path through which your data could be sent to a third party.

3. The source boundary for paid widgets (CI-enforced)

Sextant is a paid registry, so the procurement-critical question is: what source actually ships to the public, and what is gated behind a license? The answer is enforced mechanically, not by convention.

• registry.json → files[] is the boundary. It declares which source is associated with each widget. Each item is tagged tier: "free" or tier: "paid".
• The public preview bundle ships empty source for paid widgets. The browser-facing index (registry/__index__.ts) is generated from the catalog tier; paid widgets are emitted with source: "" and gated: true. The generator fails safe — a widget is only un-gated if the catalog explicitly marks it free.
• The runtime registry route returns 401 without a valid license. Requests to /r/<name>.json for a paid item with no key return 401 Unauthorized; an invalid key is rejected; only a key validated server-side returns the source.
• CI fails the build if the boundary is ever broken. A leak-boundary check (scripts/check-leak-boundary.ts) runs in CI and fails the build if a paid widget’s source is ever present in a public bundle. A paid leak is a red build, not a silent regression.

4. Supply chain and dependencies

Sextant keeps a small, inspectable dependency surface. Widgets install as plain source through shadcn — you own the code in your repo and can audit, pin, and review it like any first-party file. Because installation is source-vendoring rather than a package with lifecycle hooks, there are no Sextant postinstall scripts executing in your environment.

The runtime dependencies a widget can rely on are deliberately mainstream:

• Rendering & framework: react, react-dom, next, recharts.
• Utilities: zod (schema validation), clsx, tailwind-merge, class-variance-authority, date-fns, lucide-react, next-themes.
• Build / docs only (not shipped into your runtime path): shiki and the MDX toolchain power the documentation site.

Deterministic narratives mean no runtime AI/LLM dependency, no external API, and no data egress are introduced by adopting Sextant. Because every widget is vendored source, you can generate an SBOM from your own lockfile and review the exact tree you ship.

5. Delivery, licensing, and integrity

Source is delivered over HTTPS from the registry. Paid tiers require a license key, issued and validated server-side through Keygen; the runtime route verifies the key before returning any paid source. Purchases are processed by our Merchant of Record, Paddle, which handles billing, tax, and payment data under its own terms — Sextant does not receive your full payment-card details. For how purchase, license, and technical data are handled, see our Privacy Policy and Terms.

6. Procurement checklist

Short answers to the questions a fintech security review usually asks:

7. Reporting a vulnerability

If you believe you have found a security issue, please email hello@sextant.sh with details and steps to reproduce. We will acknowledge your report and work with you on a fix.