How A2UI Shapes the Future of UX — and What Next.js Reveals About Security
A2UI is an approach in which AI declares the state and actions of the UI, and the screen renders those declarations as-is. Because this model has the potential to become the future of user interaction, UX should be designed and planned with A2UI as an underlying assumption. At the same time, it is essential to recognize the risks introduced by this simplified UX structure and to consider security from the design stage, along with a solid understanding of relevant security practices.
🧩 Concerns That Started with ActionCard
While building my personal portfolio site, I first defined a concept called ActionCard.
As I worked on a chatbot-based UI, a natural question began to emerge.
After a conversation progresses to a certain point,
continuing to leave everything to the user with “feel free to type anything”
started to feel counterproductive.
Instead, I felt that the UI should clearly indicate the action required at that specific moment.
Especially in situations such as deciding whether or not to make contact,
- where the choices are clear, and
- the outcome directly affects what happens next,
I concluded that free-form input often makes the UX more ambiguous.
From that point on, I shifted to a Guided UX approach and designed the interface so that, instead of a text input field, an ActionCard containing buttons and explicit actions would be displayed.
💡 ActionCard Was Not a “Button UI,” but a State Representation
ActionCard was not simply a component that grouped buttons together.
What I intended was the following idea:
“This conversation is currently in a state that requires an explicit action from the user.”
For that reason, ActionCard:
- appeared only at specific moments in the conversation flow,
- was clearly distinguished from ordinary messages, and
- was structured so that the user’s choice directly influenced the subsequent AI response flow.
Personally, this approach was heavily inspired by
the conversational UX of Apple Siri—
a model where the conversation flows naturally, but clear options are presented at critical moments.
At the time, I was not organizing this as a formal or systematic concept.
It was closer to a pragmatic implementation chosen to quickly resolve UX friction I was experiencing.
🤖 Discovering A2UI
Later on, when I encountered the concept of A2UI (Agent-to-UI) proposed by Google,
I realized that there were many structural similarities to the flow I had already built.
A2UI can be summarized in a single sentence as follows:
An Agent (LLM) declares the current state and required actions,
and the UI renders those declarations without interpreting them.
The core of this concept lies in the fact that
the UI’s role shifts away from being a “decision-maker” and becomes purely a “presenter.”
🤖 What Is A2UI?
A2UI does not simply mean “AI generates the UI.”
Its essence lies in clear separation of responsibilities.
| Role | Responsibility |
|---|---|
| Agent (LLM) | State evaluation and next-action decisions |
| UI | Rendering declared states as-is |
| Server | Authorization validation and execution control |
When compared to conventional UI architectures, the difference becomes clear.
| Category | Traditional UI | A2UI |
|---|---|---|
| State judgment | Frontend logic | Agent |
| UI branching | if / switch | Declaration (JSON) |
| UI responsibility | Rendering + decision | Rendering only |
| Extension model | Add components | Extend schema |
Looking back, ActionCard—though unintentionally—was implemented in a direction quite similar to this structure.
🔁 Similarities Between ActionCard and A2UI
1️⃣ A Structure Where the UI Does Not Make Decisions
if (answerType === "promptTextMessage") {
return <ActionCard />
}
The frontend does not know
why this UI is required.
It simply renders the state provided by the Agent.
This aligns exactly with one of A2UI’s core principles:
Decisions are made by the Agent; the UI only presents them.
2️⃣ ActionCard Was a “State,” Not a Component
ActionCard was
a visualization of a state that required user action.
As a result:
- it appeared only at specific moments, and
- once that state passed, it did not reappear.
This way of thinking closely aligns with A2UI’s state-driven UI model.
3️⃣ User Actions Flow Back to the Agent
metaMessage = {
type: "ACTION_RESULT",
action: "SEND_MESSAGE",
result: "CONFIRMED",
};
The user’s choice is passed back into the LLM context
and used as input to determine the next UI state.
This flow forms an Agent-driven feedback loop.
🔐 Security Considerations Highlighted by Declarative UI and Next.js RSC Vulnerabilities
A2UI is fundamentally built on a declarative UI pattern.
While this structure simplifies the UI, it also shifts responsibilities such as state evaluation, action decisions, and authorization checks
into the server and the Agent—areas invisible to the user.
As a result, the more logic that runs backstage, the larger the attack surface becomes.
The recent Next.js RSC (React Server Components) security vulnerability incidents serve as a useful reference point here.
RSC also adopts a declarative, server-driven UI model,
and in practice, it exposed risks such as unintended server execution paths
and scenarios where user input could influence server-side logic.
The key takeaway is that this was not merely a flaw in a specific framework,
but rather an illustration of the inherent risks shared by declarative UI architectures with server-centric execution.
Since A2UI likewise processes Agent-declared UI states and actions based on trust,
similar security risks can arise if proper validation is not enforced.
Therefore, A2UI should not be viewed as
“a technology that just needs a bit more security awareness,”
but rather as a structure that cannot function properly without security as a design prerequisite.
The more UX is simplified, the more clearly teams must define
which declarations can be trusted and which executions must remain strictly controlled by the server from the outset.
1️⃣ UI Declarations Must Be Validated via a Whitelist
const ALLOWED_TYPES = [
"plainMarkdown",
"promptTextMessage",
"confirmSendTextMessage",
] as const;
function validate(type: string) {
if (!ALLOWED_TYPES.includes(type as any)) {
throw new Error("Invalid UI schema");
}
}
👉 LLM outputs must always be treated as untrusted and validated.
2️⃣ Execution Authority for Actions Must Reside on the Server
// UI only sends the request
POST /api/action
// Server validates state and authorization
if (!session.user || !isValidState(ctx)) {
return res.status(403).end();
}
👉 Buttons are merely triggers; final authority belongs to the server.
3️⃣ Information Passed into the LLM Context Should Be Structured
metaMessage = {
type: "ACTION_RESULT",
action: "CONFIRM",
result: true,
};
👉 Structured metadata is safer than free-form strings.
4️⃣ Recognize A2UI as a Form of Declarative SSR
const COMPONENT_MAP = {
ActionCard,
MarkdownView,
} as const;
const Component = COMPONENT_MAP[schema.type];
👉 Avoid dynamic execution and allow only explicit mappings.
🚀 Final Takeaways
1️⃣ The future of UIs that require user interaction is likely to move closer to A2UI.
It can expand beyond text-based input toward voice- and environment-driven interactions.
2️⃣ Developers should design UI structures with the assumption that A2UI may be introduced in the future.
Even if it is not used today, architectures that make future adoption impossible should be avoided.
3️⃣ While A2UI significantly improves productivity,
failing to incorporate security into the design increases risk proportionally.
🧾 In One Sentence
A2UI has the potential to define the future of user interaction,
and developers must take on the responsibility of pairing that potential with structural design and security considerations from the start.