> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rixxui.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Threat model

> Trust boundaries, security objectives, controls, failure behavior, and deferred risks for Rixx UI.

# Rixx UI Threat Model

## Scope

This document covers model output, streamed protocol records, catalogs, data
bindings, component rendering, emitted action requests, and URL policy. It does
not assume that model output, protocol records, tool data, catalog extensions,
or network input are trustworthy.

The initial target is a first-party React web renderer. Executable third-party
applications and MCP Apps are a separate, higher-risk trust tier.

## Security objectives

* Model output remains declarative data and cannot execute code.
* Generated UI cannot grant itself capabilities.
* Invalid or interrupted streams cannot corrupt committed state.
* Sensitive actions require host authorization and appropriate confirmation; the
  renderer never provides that authorization.
* Tool data and user input cannot escape their data channels.
* Rendering has predictable CPU, memory, network, and DOM budgets.
* Diagnostics and telemetry do not leak secrets or personal data.

## Trust boundaries

```text theme={null}
model/provider or host source
  -> language parser
  -> compiler
  -> protocol schema validator
  -> graph and catalog validator
  -> committed runtime graph
  -> renderer URL/action policy
  -> trusted React component registry

tool/server data -> data validator -> runtime data store
user interaction -> inert/commit guard -> host callback
external URL -> HTTPS/credential checks -> optional host urlPolicy -> navigation
external image -> syntax/HTTPS checks -> timing + imagePolicy -> browser fetch
```

Crossing one boundary never implies permission to cross the next.

## Protected assets

* Authentication credentials, API keys, cookies, and server secrets.
* User-entered values, host context, and personal data.
* Host application state and navigation.
* Tool execution permissions.
* Financial, destructive, privacy-sensitive, and irreversible actions.
* Renderer availability and responsiveness.
* Catalog integrity and version history.
* Private Studio logs and saved local development snapshots.

## Threats and controls

| Threat                               | Primary controls                                                                                                          |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| Arbitrary script or markup injection | Grammar excludes executable code, raw HTML/DOM, CSS, generated SVG, and event handlers                                    |
| Unknown component loading            | Static registry lookup; no model-controlled dynamic imports                                                               |
| Prototype pollution                  | Closed schemas, unsafe key rejection at every depth, null-prototype parser maps                                           |
| Prompt injection in tool data        | Separate data channel and no conversion of tool strings into DSL                                                          |
| Unauthorized tool execution          | Renderer only emits registered names; production authorization and confirmation are host-owned                            |
| Malicious URLs                       | HTTPS/credential checks, external-link review dialog, and optional narrowing host policy                                  |
| Stale or reordered updates           | Sequence numbers, base revisions, atomic commit, discard/reconnect handling                                               |
| Partial-stream effects               | Staging graph, disabled actions before commit, atomic UI commit; progressive image requests are explicit and irreversible |
| Resource exhaustion                  | Byte, record, node, depth, fan-out, string, table, chart, and update-rate budgets                                         |
| Accessibility denial                 | Semantic host components, required labels, focus restoration, WCAG 2.2 AA tests                                           |
| Deceptive confirmation UI            | Sensitive confirmations are trusted host chrome outside the generated tree                                                |
| Data exfiltration through actions    | No execution in renderer; payload remains untrusted input to host policy                                                  |
| Asset-based attacks                  | Images are HTTPS-only, credential-free, no-referrer, lazy, host-restrictable, and governed by explicit timing policy      |
| Catalog supply-chain compromise      | Closed schemas, static registry, host review; signed third-party distribution remains future work                         |
| Telemetry leakage                    | Core renderer emits no telemetry; private Studio logging is development-only                                              |

## Capability model

Rixx UI does not calculate production permissions. Effective permission is a
host-application decision combining authenticated user grants, registered
actions, current consent, and browser policy.

Capabilities are classified as:

| Class             | Examples                       | Default policy                                |
| ----------------- | ------------------------------ | --------------------------------------------- |
| Read              | Search records, read analytics | Allowed only when registered and authorized   |
| Reversible write  | Update a draft, add a label    | Preview or undo where practical               |
| Destructive write | Delete, publish, revoke        | Trusted confirmation required                 |
| Disclosure        | Copy, download, share          | Explicit scope and user intent required       |
| Navigation        | Internal route, external link  | URL policy and host mediation required        |
| Device            | Camera, microphone, location   | Browser permission plus host consent required |

The generated tree may request an action by name. `defineRUI` can describe known
actions to the model, but the current core does not execute them. It cannot
define an endpoint, HTTP method, credential, header, or trusted confirmation UI.

## Runtime invariants

* Never render an unvalidated component or prop.
* Never apply an operation after a sequence gap.
* Never mutate the committed graph while validating staging state.
* Never enable fields or custom effectful components before commit.
* Never use array positions as persistent node identity.
* Never auto-submit or trigger a consequential action on render.
* Never treat client validation as authorization.
* Never fetch a model-provided JSON Schema reference.
* Never treat navigation approval as image/resource approval.
* Never attach an image URL before its Markdown syntax or Image statement is
  complete and policy-valid.
* Never log raw model context, tool secrets, or user values in core rendering.

## Sandboxing

The native renderer executes only first-party React components and receives
data-only payloads, so an iframe is not its primary security boundary.

Any extension that executes third-party HTML or JavaScript must use a dedicated
origin, sandboxed iframe, restrictive CSP, Permissions Policy, audited message
bridge, capability negotiation, and host-mediated actions. A Web Worker is a
performance boundary, not a DOM security boundary.

## Failure behavior

* Syntax error: reject the statement and return a bounded diagnostic.
* Catalog or policy error: reject the complete transaction.
* Render exception: isolate the trusted component subtree and report telemetry.
* Repeated repair failure: use the trusted host fallback.
* Security-policy denial: explain the denial without exposing policy internals.
* Source/transport failure: discard provisional state and retain only committed
  host state.

## Verification

* Parser fuzzing across arbitrary UTF-8 and chunk boundaries.
* Property-based graph operation tests.
* Malicious fixture corpus for references, keys, URLs, SVG, HTML, and actions.
* Cross-browser keyboard and screen-reader testing.
* Automated WCAG checks plus manual interaction testing.
* Dependency review, provenance, lockfile integrity, and secret scanning.
* External security review before executable extensions or production writes.

## Deferred risks

These features remain disabled or outside the renderer boundary until separately
designed and reviewed:

* Executable third-party catalogs.
* Raw HTML, MDX, and executable rich content. Sanitized CommonMark/GFM inside
  `RichText` is supported.
* Video/audio fetching and cross-origin embeds. Static HTTPS images are
  supported; security-sensitive hosts should narrow them with `imagePolicy`.
* Renderer-owned action execution, authorization, or persistent drafts.
* Model-defined queries and mutations.
* Public catalog marketplace.
* Payments and other regulated actions.
* Cross-origin app embedding.