Skip to content
On this page

A2UI Trust and Security Model

A realistic threat model for declarative agent-generated interfaces, including remaining XSS, phishing, action, privacy, and availability risks.

Updated: 8/6/2026 Reviewed by: HIA2UI editorial team v0.9.1 production baseline

Trust and security model

A2UI sends declarative data instead of agent-generated executable code. This narrows the attack surface, but it does not make an agent, message, catalog, component property, URL, or action trusted.

Security boundaries

BoundaryControlRemaining risk
ProtocolVersioned schema validationResource exhaustion, parser defects, replay, partial delivery
CatalogAllowlisted component and function definitionsA permitted component may expose unsafe capabilities
RendererHost-owned native implementationsURL, Markdown, navigation, WebView, and dependency vulnerabilities
ActionServer-side authentication and authorizationStale state, confused deputy, duplicate execution
UserConfirmation and clear provenancePhishing, misleading content, coercive design

What declarative rendering improves

An agent cannot directly ship arbitrary JavaScript through the A2UI schema. The host chooses which catalog entries exist and how they render. Invalid component names and properties can be rejected before display. These properties make the boundary more auditable than rendering untrusted HTML or JSX.

They are not absolute guarantees. The official project has fixed URL-opening XSS/tab-nabbing and DataModel prototype pollution, demonstrating that renderer code and dependencies remain part of the trusted computing base.

Required controls

  • Validate the exact negotiated protocol version.
  • Restrict catalogs, component counts, depth, update rate, URLs, and data-model paths.
  • Sanitize Markdown and disable raw HTML by default.
  • Treat navigation, iframe, clipboard, download, authentication, payment, and file components as elevated capabilities.
  • Authorize every consequential action against current server state.
  • Keep credentials, tokens, private prompts, and unnecessary personal data out of UI payloads.
  • Preserve accessible text fallback and test failure paths.

Use the production security checklist for release review and the security deep dive for the complete threat model.