-
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 safely, sealed away 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.
That is the whole design goal. Untrusted HTML executes only on a separate, cookieless origin, inside a sandboxed iframe, under a strict Content Security Policy that blocks network access, forms, top navigation, and same-origin access. Because the origin is opaque and carries no cookies or session, hostile code has nothing to steal and nowhere to send it. 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 offline, immutable, and sealed, 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 reach the network, set cookies, escape the opaque origin, open popups, submit forms off-origin, or navigate the top window. 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. 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, and a secret manager. The production boot process fails closed when its security contract is incomplete. 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.