A2UI Production Security: Threat Model and Release Checklist
A practical A2UI threat model covering schema validation, catalogs, URLs, actions, privacy, YMYL workflows, resilience, and accessibility.
A2UI narrows the interface between an agent and an application, but the payload remains untrusted. A component allowlist helps only when its implementations, properties, actions, and dependencies enforce the same boundary.
Threat model
Assume the model can be manipulated by indirect prompt injection, the transport can replay or truncate messages, a catalog can contain unsafe capabilities, URLs can be malicious, and an action can arrive after server state changes. Also assume valid-looking content can mislead a user without exploiting code.
The official project has fixed URL-opening XSS/tab-nabbing and DataModel prototype pollution. Those changes are evidence that declarative architecture still depends on current packages, strict path handling, and renderer hardening.
Rendering boundary
Validate every message against the negotiated version. Reject unknown properties, duplicate IDs, unresolved references, unsupported catalogs, unsafe path segments, excessive depth, oversized lists, and rapid update floods. Constrain URLs by scheme and origin. Sanitize Markdown, keep raw HTML disabled, and treat iframe, WebView, download, clipboard, navigation, payment, and authentication components as elevated capabilities.
Never place secrets, access tokens, session identifiers, or private prompts in component properties or the shared data model. Log identifiers and outcomes needed for audit, but redact confidential content.
Action boundary
The server must authorize every action. Re-check the user, resource, amount, destination, and current state; use idempotency keys for retryable high-impact operations. Require explicit confirmation for deletion, publication, account changes, purchases, payments, and disclosure of sensitive data.
For financial, medical, legal, or safety workflows, generated UI must not imply a guaranteed return, diagnosis, legal conclusion, or completed transaction without authoritative confirmation. Provide escalation to qualified review and make uncertainty visible.
Accessibility and failure behavior
Security includes preventing coercive or inaccessible flows. Preserve names, roles, focus order, keyboard operation, error association, contrast, reduced motion, and live-region announcements. Do not rely on color alone. Provide text fallback for unsupported components, invalid payloads, renderer failure, and timeouts.
Test partial streams, duplicates, reconnects, stale actions, deletion, large payloads, dependency compromise, and unavailable agents. Release only after the complete production checklist is reviewed against the actual catalog and transport.
Frequently asked questions
Does declarative A2UI eliminate XSS?
No. It reduces direct code-generation risk, but renderer components, URLs, Markdown, bridges, and dependencies still require secure implementation.
Is disabling a generated button sufficient authorization?
No. Every consequential action must be authorized against current server state.