-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
A self-hosted internal knowledge base for AI-generated content. It stores, versions, searches, and previews two kinds of untrusted material: Markdown and wiki pages (with inline Mermaid diagrams), and single-file HTML artifacts. The headline capability is running untrusted AI-generated HTML in containment, isolated from your authenticated application.
AI assistants generate runnable HTML (dashboards, prototypes, runbooks) constantly, but that output is untrusted code. Opening it on a page that carries your login cookie is unsafe, and keeping it in a folder of loose files is unmanageable. ArtifactFlow gives those artifacts a home where they stay searchable, versioned, permissioned, and still runnable.
It is an alpha (0.x). The security model and features are implemented, tested, and internally reviewed, but the product is young and still evolving. Read the Roadmap for the alpha boundary, and pin a specific revision for anything you depend on.
Containing it is the whole design goal, though no browser sandbox is ever claimed to be perfectly safe. Untrusted HTML executes only on a separate, cookieless origin, inside a sandboxed iframe, under a strict Content Security Policy that blocks the ordinary network APIs, forms, top navigation, and same-origin access. Because the origin is opaque and carries no cookies or session, hostile code has nothing local to steal. Residual, browser-dependent egress vectors are enumerated in the threat model rather than claimed impossible. See the Security model.
Sanitization tries to guess which markup is dangerous and strip it, which is a losing game against a determined author. ArtifactFlow does not rely on scrubbing. It assumes the code is hostile and runs it inside a browser sandbox on a throwaway origin. The browser enforces the box; the separate origin makes escaping the box pointless.
Cookies and same-origin access are scoped by origin. If artifacts ran on your application origin, even in an iframe, a sandbox escape would reach your session. A physically separate host means there is no application cookie, no session, and no other tenant data present where the artifact runs, so even a full escape gains nothing worth having.
No, and this is deliberate. The sandbox blocks external scripts, styles, and network calls, so an artifact that links a CDN renders as a partial shell. Artifacts must be a single self-contained HTML file with every dependency inlined. Ask your AI to produce one self-contained file. This keeps every artifact self-contained and immutable, which is the point of the vault.
It can run its own inline JavaScript, render its own UI, use data and blob URLs for images and fonts, and be fully interactive. It cannot use the ordinary network APIs, set cookies, escape the opaque origin, open popups, submit forms off-origin, or navigate the top window (the threat model documents the residual, browser-dependent egress vectors that remain). Those limits are a product boundary, not a bug.
Not by an external third party. It has been through repeated internal, AI-assisted adversarial review, static analysis at maximum strictness, full type coverage, and a broad automated test suite that includes browser-level security tests on Chromium (cross-engine Firefox and WebKit coverage is planned). Treat it accordingly, and report suspected sandbox escapes through the security policy.
See SECURITY.md in the repository. Note that the sandbox is meant to execute script, so report escapes (untrusted code reaching the app origin, cookies, network, or another tenant), not the fact that an artifact ran JavaScript.
ArtifactFlow exposes a Model Context Protocol server on the application origin. Approved AI clients use scoped, expiring bearer tokens to list, search, read, create, update, and revert pages through the same handlers, policies, scanners, and audit trail as human users. Read content is delivered as explicit untrusted-data envelopes.
No. Tokens are hard-capped at Editor authority (administrative power is removed at the code level), can be limited to read-only or to specific workspaces, and expire. A token can only reach what its principal can already reach, and reading a page never authorizes a later write.
No. It is self-hosted software for one internal installation. It is not designed as a public, hostile-internet, multi-tenant service.
The supported unit is the production image built from the repository, run with PostgreSQL, Caddy, and FrankenPHP. A real deployment needs two HTTPS hostnames (one for the app, one for the artifact host), PostgreSQL with verified TLS, persistent private storage, a replica-shared cache backend (PostgreSQL, Redis, Memcached, or DynamoDB) so login, 2FA, and MCP rate-limit counters hold across app instances, and a secret manager. The production boot process fails closed when its security contract is incomplete, and before the database schema is applied the app serves a safe "installation required" page (and a retryable error to MCP clients) rather than leaking setup state. See the operations guide in the repository.
No. Coarse database visibility is always followed by an exact per-page authorization check, on both the human and MCP paths, so a result you are not allowed to see is filtered out before anything about it is returned. Registered human names, emails, and UIDs are intentionally discoverable inside one installation, but an identifier never grants authority: every membership and grant is authorized server-side.
AGPL-3.0-or-later. If you modify it and run it for users over a network, the AGPL requires you to offer them the corresponding source. A separate commercial license is available for proprietary use, closed forks, or managed-service deployments that cannot comply with the AGPL.
Contributions are welcome under the AGPL with a Developer Certificate of Origin sign-off and a one-time Contributor License Agreement signature that keeps the dual-licensing model viable. Contributors keep their copyright. See CONTRIBUTING.md.
The CLA check requires a human signature, and automation accounts like Dependabot cannot sign, so their pull requests can report the CLA as failing. That is expected and does not indicate a code problem. Bot actors are allowlisted so their maintenance pull requests pass, without relaxing the signature requirement for human contributors.