Short version: Fictor treats model output as untrusted text. The model receives no shell, host tools, or filesystem access. Candidate code runs in Chrome’s sandbox behind a restrictive Content Security Policy. The Build path is not additionally confined by a Linux kernel sandbox.
Model boundary
- The model returns code; Fictor writes the returned files.
- The model is not given a shell, package installer, host tools, or direct filesystem access.
- Local Ollama is the default. You choose the local model; tested recommendations will be published separately. OpenAI and Anthropic are optional.
- Before every cloud-backed operation, Fictor identifies the provider and data being sent. The server refuses the request without consent for that operation.
Candidate and delivery boundary
- A generated candidate is separate from the currently delivered application.
- Candidate previews use a throwaway loopback origin, Chrome’s sandbox, and a Content Security Policy intended to block network access and dangerous browser capabilities.
- Security and integrity scans fail closed before delivery.
- Applying a candidate requires an explicit user action and a coherent, unchanged baseline.
- Fictor records accepted output as
manually_accepted, never as proof that it works.
Local control plane
The application listens on 127.0.0.1 by default. A user can deliberately bind it to another interface, but doing so exposes it to that network and changes the threat model.
Network and data behavior
- No telemetry, analytics, crash reporting, automatic update check, account service, or remote licence server.
- For model calls, Fictor stores local metadata such as provider, model, token counts, timing, and a locally keyed correlation identifier. It does not store prompt or response text in that call ledger.
- Briefs and generated candidates are stored locally in plain text inside the project run directory.
- Cloud-provider retention and training behavior is governed by the provider’s terms, not Fictor’s.
Known limitations
- No kernel confinement on Build. Candidate execution relies on Chrome’s sandbox and Fictor’s browser policy, not Landlock or seccomp.
- Popup containment is post-hoc. A popup is closed after detection; its first request may complete before closure.
- Offline serving is less restricted. The specialist
serve-verifycommand serves generated code without the normal preview CSP. - Single trusted user. The alpha is not designed for hostile local users or multi-user machines.
- Generated code can be wrong. Security controls do not make the generated application correct, complete, or suitable for deployment.
Release transparency
Each public release is intended to include SHA-256 checksums, a CycloneDX SBOM, third-party licence texts, the applicable Fictor licence, privacy terms, and release limitations. The product source remains proprietary. The three small runtime files embedded in generated applications are licensed under 0BSD so users can distribute their own applications.
Report a vulnerability
Email security@fictor.dev. We target acknowledgement within five working days. There is no bounty program.
We will not initiate legal action against research conducted in good faith under our policy: avoid harm, disruption, and unnecessary access to personal data; access only what is needed to demonstrate the issue; stop and report if sensitive data is encountered; do not exploit the issue or use threats; and allow a reasonable opportunity to respond before public disclosure. This does not authorize unlawful access or bind third parties.
Do not send a complete Fictor run directory. It can contain your brief and generated source. Inspect and redact every artifact before sending it privately.