FrootAI — AmpliFAI your AI Ecosystem Get Started

Trust home

Security & Signing

Every artifact FrootAI publishes carries a verifiable signature. This page is the canonical inventory of how each surface is signed, where the signing material lives, and the exact commands to verify a download yourself.

Signing inventory

FrootAI prefers keyless signing wherever the publishing surface supports it — there is no long-lived private key for npm, PyPI, or cosign-signed artifacts. The only persistent signing key is the GPG key used for Linux distro packages, stored as GitHub Actions secrets and verifiable against the public key block below.

npm packages (`frootai-mcp`, `frootai-cli`, `frootai-sdk`)

npm provenance (Sigstore-backed)

Where the signing material lives
Keyless. Signed at publish time by GitHub Actions OIDC token; certificate minted by Sigstore Fulcio CA; signature logged in public Rekor transparency log.
Verify a download
npm audit signatures frootai-mcp
Workflow / spec
npm-publish.yml + publish-orchard-sdks.yml use `npm publish --provenance` with `permissions: id-token: write`. No long-lived key.

PyPI packages (`frootai-mcp`, `frootai-sdk`)

PyPI Trusted Publishing (PEP 740 attestations)

Where the signing material lives
Keyless. Uses `pypa/gh-action-pypi-publish@release/v1` with OIDC trusted-publishing — no `PYPI_TOKEN` secret. PEP 740 attestations enabled.
Verify a download
pip download frootai-mcp --no-deps && twine check *.whl
Workflow / spec
publish-orchard-mcp.yml + publish-orchard-sdks.yml lines ~22-24 document the trusted-publishing flow.

VS Code extension (`frootai-vscode`)

Microsoft Marketplace signature

Where the signing material lives
Marketplace-side. Microsoft signs the .vsix at install time once we publish via `vsce publish`. Author identity is verified via `VSCE_PAT` (Personal Access Token, GitHub repo secret).
Verify a download
VS Code auto-verifies on install; manual verification: download .vsix from marketplace and check signature with `code --verify-extension`
Workflow / spec
vsce-publish.yml uses `secrets.VSCE_PAT` for publish auth. The publisher account is `frootai`.

Linux .deb / .rpm packages (FrootAI CLI binaries)

GPG signature

Where the signing material lives
GitHub Actions repo secrets `GPG_PRIVATE_KEY_B64` + `GPG_KEY_PASSPHRASE` (private key, base64-encoded, AES-encrypted at rest in GitHub secret store). Public key + fingerprint published below.
Verify a download
gpg --verify <pkg>.deb.asc <pkg>.deb (after importing the public key from this page)
Workflow / spec
build-binaries.yml H8.21 step: imports the GPG key into an ephemeral GNUPGHOME, signs each binary, then `gpg --verify` self-tests before publishing.

Orchard play ZIP bundles (`cdn.frootai.dev/orchard/plays/`)

sigstore-cosign keyless OIDC + sha256 sidecar

Where the signing material lives
Keyless. Same model as npm provenance: GitHub Actions OIDC token → Fulcio CA → Rekor log. Each `<play>-<version>.zip` ships with `.zip.sha256` and `.zip.sigstore` sidecars.
Verify a download
cosign verify-blob --certificate-identity-regexp '^https://github.com/frootai/' --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' --signature <play>.zip.sigstore <play>.zip
Workflow / spec
Planned at [H7.14] (`harvest-to-play-masterplan.md`). No new key needed — extends the existing keyless OIDC pattern from npm + PyPI.

Orchard manifest.json (signature record)

Embedded sha256 + cosign signature reference

Where the signing material lives
Keyless (same flow as the ZIP). `manifest.json` carries `{ filename, sha256, cosign_bundle_uri }` so consumers can verify without the ZIP in hand.
Verify a download
node -e "console.log(crypto.createHash('sha256').update(fs.readFileSync('<play>.zip')).digest('hex'))" — compare with manifest.sha256
Workflow / spec
Planned at [H7.15] (`harvest-to-play-masterplan.md`).

GPG release key

This is the FrootAI release-signing key used for Linux distro packages (`.deb`, `.rpm`) and GitHub Release artifacts. Import it once, then `gpg --verify` any signed download.

Fingerprint
TBD — exported from build-binaries.yml run
Public key block
frootai-release.asc
Import + verify
curl -O https://frootai.dev/security/frootai-release.asc gpg --import frootai-release.asc gpg --verify frootai-cli_<version>_amd64.deb.asc frootai-cli_<version>_amd64.deb

First-time setup: the fingerprint + .asc file are populated by the maintainer from the live build-binaries.yml workflow output (one-time admin task). Until that happens, the fingerprint reads TBD — please fall back to npm provenance / PyPI attestations for verifiable downloads.

Secrets custody policy

  • Keyless first. Every new publishing surface MUST attempt keyless OIDC (Sigstore / Fulcio + Rekor) before introducing a long-lived private key.
  • Private keys are GitHub Actions repo secrets only. Never committed, never copied to local dev machines, never shared outside the CI runner.
  • Rotation cadence. GPG release key: 365 days. VSCE_PAT: 90 days. NPM_TOKEN: keyless preferred (no rotation needed).
  • Compromise response. Revoke key → publish revocation cert to this page → re-sign affected releases with new key → notify subscribers via GitHub Security Advisory.

Reporting a vulnerability

Use GitHub Security Advisories for any software vulnerability. For trust-and-safety reports (DMCA, license violations, harassment), use /trust instead.

Engine & Studio — Trust & Safety

FrootAI's engine disclosure and Studio sandbox introduce specific trust & safety considerations. We commit to a 48-hour SLA on initial response for all reports below.

Engine Disclosure Issue — provenance panel shows incorrect data, composed_from references are wrong, or audit trail has gaps.
Studio Misuse — live harvest demo used to scan malicious repos, abuse of free-tier rate limits, or generation of harmful content.
Embed Widget Abuse — partner embed widgets used on unauthorized domains or for misleading purposes.
DMCA Takedown — content on frootai.dev infringes copyright. Include the specific URL and original work reference.

Report to [email protected]. All categories: 48h first-response SLA. Data privacy concerns: 24h SLA.