Trust home
Security & Signing
This page lists independently verifiable release safeguards and active security commitments for supported public distribution surfaces.
Signing inventory
This inventory covers only release evidence that can be checked on the active registry or distribution surface. A package is not described as signed or attested unless its current public release exposes that evidence.
JavaScript package distribution
Registry integrity metadata
- Where the signing material lives
- The public distribution registry exposes integrity information for released files.
- Workflow / spec
- Use the verification information presented by the distribution registry before installation.
Python package distribution
Registry file integrity metadata
- Where the signing material lives
- The public distribution registry exposes integrity information for released files.
- Workflow / spec
- Use the verification information presented by the distribution registry before installation.
Editor extension distribution
Marketplace verification
- Where the signing material lives
- The distribution marketplace verifies published extension packages and publisher identity.
- Workflow / spec
- Publisher identity and release authorization are managed through protected distribution credentials.
External tool connections are policy-controlled
External connections are evaluated against an explicit trust policy before use. Review available integrations in FrootAI MCP Discover. Provider reputation is evidence, not permission: sensitive operations still require applicable policy and user confirmation.
Each connection receives an explicit policy outcome.
- Approved connections may proceed within their assigned permissions.
- Connections requiring review remain blocked until explicit approval.
- Sensitive operations remain subject to separate authorization and confirmation.
- Connections that fail policy are blocked.
Controls are applied before and during use.
- Connection identity and declared capabilities are evaluated before approval.
- Permissions are bounded to the approved connection and operating context.
- Policy changes are reviewed and validated before release.
- Security-relevant failures deny access rather than silently weakening controls.
Connections that require approval are not activated without an explicit user or administrator decision. Customer-specific policy can further restrict or block an integration where supported by the contracted service.
Identity and access posture
FrootAI separates restricted administration from customer accounts and applies server-side authorization at protected boundaries. Authentication services are managed by contracted providers; FrootAI application code does not intentionally store plaintext passwords.
Restricted administration
Restricted administrative routes
- Provider
- Administrative access requires approved identity verification and additional authentication controls.
- Control boundary
- Multiple independent authorization checks protect restricted operations. Security-relevant access events are retained for authorized review.
- Roles
- Administrative authorization is role-based and checked server-side. Role assignments are restricted to operational need.
Customer accounts
Signed-in customer services
- Provider
- A managed identity service handles supported sign-in methods, linked identities, additional authentication factors, and sessions. FrootAI does not receive or store plaintext passwords.
- Control boundary
- Entitlements and authorization are checked by protected services rather than trusted from browser display state.
- Exit path
- Signed-in users can build a JSON export from account settings and schedule account deletion with a 30-day cooling-off period from the deletion page.
Shared security controls
Applied according to the active identity path
- Managed authentication. Customer password handling remains with the configured identity provider; FrootAI application code does not intentionally store plaintext passwords.
- Credential custody. Service credentials use managed secret stores, and committed changes are scanned for exposure.
- Account security events. Authentication, authorization, role, and account-lifecycle paths emit or persist security evidence according to the active service configuration.
- Emergency controls. Operator runbooks and administrative controls support disabling affected access paths during an incident. Response times depend on the incident and provider.
- Provider health. FrootAI monitors application and provider health. Public status history is described only when the corresponding status surface is available.
- Compliance scope. SOC 2 readiness work is in progress. Privacy, DPA, regional, and payment commitments are service-specific and apply only when configured and contracted.
For the data-processing roles each provider plays, see /data-protection §3.1 Authentication and account services.
Secrets custody policy
- Verifiable first. A release surface is listed as signed or attested only after its public registry exposes independently checkable evidence.
- Long-lived publishing keys are avoided. If a future release surface requires one, it must use a managed secret store and publish valid verification material before being listed above.
- Rotation cadence. Marketplace credentials are rotated according to provider policy. Package-upload authentication is not described here as keyless unless the registry evidence confirms that property.
- 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 aim to review reports promptly, but no contractual response-time SLA applies during early access.
Report to [email protected]. Response timing depends on severity, evidence, provider dependencies, and legal requirements.