Generative UI for agents exposes the agent UI governance gap

At a glance

What this is: This recap shows how generative UI lets agents move from tool calls into rendered product experiences, using typed SDKs, component libraries, and deep links.

Why it matters: It matters because once agents can compose UI and execute code, IAM teams must govern not just API access but agent-scoped authorization, traceability, and misuse boundaries across NHI and future autonomous patterns.

👉 Read WorkOS's recap of Rhys Sullivan's MCP Night 4 generative UI demo

Context

Agents already interact cleanly with docs and APIs, but product UI is a different problem because it embeds context, state, and decision cues that tool calls usually strip away. The result is a governance gap as much as a user-experience gap: if an agent can render UI back into a product, identity teams need to understand what the agent can see, invoke, and present to a human.

In this case, the topic sits squarely in NHI governance because the underlying subject is machine identity interacting with application surfaces through MCP and typed interfaces. The architectural question is not whether an agent can produce a chart or deep link, but how access, execution, and logging behave when product actions are mediated by a non-human actor.

Key questions

Q: How should security teams govern agents that can render product UI?

A: Security teams should treat rendered UI as part of the governed access path, not just a frontend convenience. The control question is whether the agent can only display approved views, or whether it can shape what a user sees and does. That means entitlements, logging, and review processes must cover the rendered experience as well as the underlying data source.

Q: Why do agent tool chains create new identity governance problems?

A: Agent tool chains create governance problems because they combine search, execution, and presentation into one runtime flow. Each step may be individually approved, yet the combined path can exceed what the programme intended. Identity teams need to evaluate the whole chain as a single access event, not as separate low-risk calls.

Q: What breaks when code mode gives agents more runtime freedom?

A: What breaks is the assumption that a tool call is a bounded request. Code mode lets an agent translate intent into executable actions, which expands the blast radius if controls only cover authentication and not runtime containment. The practical test is whether the environment constrains what the agent can do after access is granted.

Q: How do teams keep fallback links from weakening access controls?

A: Teams should make sure that native rendering and fallback links enforce the same entitlement checks and audit records. If the same agent request resolves differently depending on client capability, security drift can appear between user paths. Consistency across both paths is essential for traceability and policy enforcement.

Technical breakdown

Generative UI, typed SDKs, and agent-to-product composition

Generative UI in this context means an agent can assemble a product-facing interface from application components rather than returning only text or raw data. The demo pattern combines typed queries, component libraries, and an execution layer that turns API or OpenAPI surfaces into code the agent can call. That shifts the agent from a simple caller into a composer of product experiences. For identity teams, the important point is that the UI becomes part of the callable surface, not just the browser or frontend. The agent is no longer limited to fetching data; it can shape the interaction path that follows.

Practical implication: Treat rendered UI as a governed extension of the agent’s access path, not just a frontend feature.

The execute tool, code mode, and runtime authority

The execute pattern described here lets an agent generate and run code against typed interfaces instead of issuing one-off tool calls. That matters because code mode can improve reliability while also widening the operational blast radius if the agent is poorly scoped. In NHI terms, the governing question becomes whether execution rights are bounded by task, session, and data domain. When an agent can translate API intent into code, authorization and audit controls need to be attached to the execution environment, not assumed from the calling interface alone. The architecture is powerful, but it collapses the distinction between request and action.

Practical implication: Bind agent execution to explicit scopes, environment controls, and logs that survive beyond the call itself.

MCP apps and deep-link fallback behavior

The article also highlights that MCP apps can render natively in clients that support them and fall back to a link when they do not. That graceful degradation is useful for product reach, but it also introduces a policy problem: the same agent request may resolve through different user paths depending on client capability. Identity governance has to account for both paths because the access event may be mediated inside the client or externalized into the product. In practice, this is a traceability and entitlement consistency issue, not just a UX concern. The control objective is to keep the permission model stable across both rendering modes.

Practical implication: Verify that native and fallback paths enforce the same entitlements, logging, and approval boundaries.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Generative UI turns the agent from a data consumer into an interaction broker. That changes the governance surface because the agent no longer just requests information, it shapes how information is rendered and consumed. For IAM and NHI teams, the issue is not UI polish, but whether the agent can influence downstream user action without a clear entitlement boundary. The practitioner implication is that agent-mediated interfaces need explicit policy, not implicit trust.

Agent code execution shifts the control point from API authentication to runtime containment. The demo’s execute pattern shows why identity teams cannot stop at tool authorization. Once an agent can translate intent into runnable code, the real question becomes what the runtime may do, what it may reach, and how those actions are logged. The practitioner implication is to govern execution as a privileged capability, not a convenience layer.

Typed interfaces create a new kind of identity blast radius because they make product surfaces machine-addressable. That is useful for scale, but it also means the agent can reach more of the product with less friction than a human user would. In NHI terms, the access path becomes more composable, which can outpace traditional app-level review processes. The practitioner implication is to treat typed API surfaces as part of the governed identity boundary.

Privilege must be defined for the agent’s full interaction path, not just for the underlying API call. The article shows a chain that spans docs search, render UI, execute, and deep links. That chain matters because the security model breaks if each step is reviewed in isolation. The practitioner implication is to assess end-to-end agent workflows as one governed identity transaction.

For autonomous extensions, the assumption that access is human-paced becomes brittle very quickly. Access review processes were designed for actors whose permissions persist long enough to be reviewed and recertified. If a future version of this pattern allows the actor to select tools, write code, and move through product states without approval gates, that assumption fails because identity becomes runtime-directed rather than human-sequenced. The practitioner implication is that governance models must distinguish between assisted agents and autonomous execution before they converge operationally.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For a broader control lens, see OWASP Agentic Applications Top 10 for the runtime risks that emerge when agents can select tools and actions dynamically.

What this signals

Generative UI will pressure identity programmes to move from tool-level approvals to workflow-level governance. Once a machine identity can search, execute, and render product surfaces, the programme can no longer assume that access decisions live only at the API layer. The practical shift is toward governing the sequence, not just the endpoint, because sequence is where composed agent behaviour starts to exceed human review models.

With 70% of organisations already granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the issue is not future readiness but present-day privilege inflation. That same pattern will show up in agent-mediated UI if teams rely on conventional role design. The next governance question is whether the product surface itself becomes an entitlement boundary or just another place where excessive access hides.

As agent experiences become more composable, programmes should expect the audit problem to widen. Search, code execution, and UI rendering each create artefacts, but they must be stitched together into one accountable trail if identity reviews are going to mean anything.

For practitioners

• Map the full agent interaction path Inventory every step from docs lookup to render UI to execute calls and deep-link fallback, then assign a control owner to each step. The goal is to identify where authorization, logging, and approval boundaries change across the path.
• Scope runtime permissions separately from API permissions Do not assume that a validated API surface implies safe execution. Define what the agent may run, what data it may reach, and which environments it may touch when code mode is involved.
• Align rendered UI with the same entitlement model as the product Verify that a native MCP app render and a fallback product link enforce the same access rules, audit trails, and session context. Different presentation paths should not create different security outcomes.
• Build audit coverage for agent-composed interactions Capture the agent’s tool calls, generated code actions, and any user-visible UI it returns so investigations can reconstruct the full sequence. Partial logging is not enough when the interaction is composed dynamically.

Key takeaways

• Generative UI expands the agent security surface by making product presentation part of the machine identity workflow.
• Runtime execution is the real governance boundary when agents can write and run code against typed interfaces.
• Identity teams should verify that rendered and fallback paths enforce the same entitlements, audit trails, and policy decisions.

Key terms

• Generative UI: A product interface assembled at runtime by an agent from components, data, and execution results. It is not just a visual output layer. In identity terms, it becomes part of the governed access path because the agent can shape what users see and do.
• Code mode: A workflow in which an agent generates and runs code against a real interface instead of issuing isolated tool calls. That increases reliability, but it also shifts governance from simple request approval to runtime containment, logging, and permission scoping.
• Deep-link fallback: A client behavior where an app experience renders natively when supported and opens as a link when it is not. For governance, the important issue is consistency: the access rules, audit trail, and entitlement checks should remain the same across both paths.
• Agent interaction chain: The full sequence of actions an agent performs to satisfy a task, including lookup, execution, rendering, and user handoff. This chain matters because identity risk often appears only when the steps are evaluated together, not one by one.

Deepen your knowledge

Generative UI for agents and runtime execution governance are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are dealing with agent-driven product surfaces or execution paths, it is a practical place to start.

This post draws on content published by WorkOS: Generative UI for agents: Rhys Sullivan's MCP Night 4 lightning demo. Read the original.