Artifacts permissions and lifecycle

Artifacts is an authenticated, org-less private-document viewer. Access belongs to one user account and one artifact; organization roles and copied links are not access grants.

Routes

Purpose	Current route
List artifacts visible to the signed-in account	https://artifacts.infra.one/
View one artifact	https://artifacts.infra.one/a/:slug
Load the authorized document inside the viewer	https://artifacts.infra.one/a/:slug/content

The content route is the viewer’s internal frame source, not a public or shareable document URL. Artifacts routes are host-specific and do not become available on another Infra One host.

Access model

Account state	Supported behavior
Artifact owner	List and view the owned artifact. The underlying owner workflow may create versions and manage explicit grants, but no customer grant-management procedure is exposed on the viewer pages.
Explicit per-user grantee	List and view that artifact while the grant is active. A grantee cannot manage the artifact or its grants.
Organization Admin or member without a grant	No artifact access. Organization membership and role do not participate in the Artifacts permission check.
Platform administrator without ownership or a grant	Administrator status does not grant access to another owner’s artifact and does not bypass artifact-level authorization.
Signed-out visitor	Redirected through the standard sign-in flow before any artifact content is returned.

The host exists for an ordinary signed-in user only while that account owns or is granted at least one artifact. A user with no visible artifact receives a not-found response for the host.

For an individual URL, owner or active-grantee access is checked against stored data. An unknown slug, an existing but ungranted artifact, and a revoked grant all return the same not-found boundary, including the response body. This prevents a URL from confirming whether a private artifact exists.

Grant lifecycle

An artifact has one owner and may have a unique grant for each additional active user account. The approved internal operation looks up that account and requires explicit confirmation before creating a grant. Grant creation and revocation are owner-authorized internal operations; the customer viewer does not expose controls for either action. Creating a grant does not notify the grantee or deliver a link, so the approved operator shares the viewer link separately through a private channel.

When a grant is revoked:

• the artifact is removed from subsequent visible-list queries for that account;
• a fresh page or content request returns the same not-found boundary as an unknown artifact;
• the latest payload is re-authorized in the same database statement that reads it, so a revoked grant cannot pass an earlier check and receive the payload from a later read; and
• if it was the account’s last visible artifact, a new visit to the host is also denied.

Revocation does not erase content that a person already viewed, copied, or retained outside Infra One. Close an already open page, do not forward its content, and use the approved private incident process if access was granted to the wrong account.

Versions and payload boundaries

Each published artifact version is immutable. Publishing new content appends a higher version position; it does not edit the prior row. The viewer selects the newest stored version and updates the artifact’s list ordering when new content is added.

Contract	Current behavior
Publication input	The approved internal boundary accepts one self-contained .html or .htm file. This is not a customer viewer action.
Maximum HTML payload	5 MiB (5,242,880 bytes). A larger payload is rejected by the internal publication boundary.
Text validity	Only approved, self-contained HTML may cross the internal publication boundary. It must be valid UTF-8 and cannot contain null bytes; approval does not make the document code trusted.
Full HTML document	Served byte-for-byte as stored when System applies no explicit theme.
HTML fragment	Wrapped in a minimal HTML document with the artifact title before it is served.
Explicit theme	Light or Dark can add a root theme marker, so the served response can differ from the stored bytes. The document’s CSS must implement the requested state.
Artifact with no version	The content request returns not found; a viewer cannot create or repair a version.

The stored checksum, where an approved internal workflow displays it, verifies the uploaded bytes rather than every wrapped or themed response. The payload limit describes the stored document boundary, not a customer upload allowance. Artifacts exposes no customer upload or ingestion procedure.

Themes

The viewer offers exactly three controls:

• System omits an explicit theme and leaves the document’s own system-color behavior in control.
• Light requests theme=light and adds data-theme="light" to a recognized document root.
• Dark requests theme=dark and adds data-theme="dark" to a recognized document root.

Any other theme value falls back to System. A document without a recognized root may safely ignore an explicit theme instead of being rewritten into an invalid document. Theme selection does not guarantee a visible color change because the document owns its styles.

Isolation and response headers

The viewer frame uses sandbox="allow-scripts" without allow-same-origin and uses the artifact title as its accessible name. Document-owned scripts can run inside an opaque origin, but they cannot inherit the Artifacts host’s cookies, storage, or parent DOM.

The document response replaces the platform CSP with a restrictive policy:

• sandbox allow-scripts and default-src 'none' are the baseline;
• style-src 'unsafe-inline' https://fonts.googleapis.com, font-src https://fonts.gstatic.com, and script-src 'unsafe-inline' allow only the document’s inline styles and scripts plus Google Fonts;
• img-src data: permits embedded data images while ordinary connection, media, and image subresources remain denied by default; the two Google Fonts origins above are explicit external exceptions;
• base-uri 'none', object-src 'none', and form-action 'none' disable base URLs, embedded objects, and form submissions; and
• frame-ancestors https://artifacts.infra.one allows only the exact Artifacts origin to frame the document.

The response also sets X-Robots-Tag: noindex, nofollow, Referrer-Policy: no-referrer, X-Content-Type-Options: nosniff, and Cache-Control: private, no-store. These controls reduce unintended disclosure and reuse, but they do not make document code trusted or guarantee zero outbound requests: inline document scripts still run, an artifact can contact the permitted Google Fonts services, and it can navigate its own frame. Never enter credentials, secrets, or customer data into the document. Use an approved non-artifact workflow when the confidentiality requirement forbids external requests.

The controls also do not revoke information that was already displayed or copied.

Related pages

• Open and review a private artifact
• Troubleshoot Artifacts