Why we chose an iframe-based View Generation architecture in an enterprise environment
AI-generated UI is no longer a new concept.
However, in an enterprise environment, what matters more is what happens after generation.
Where the result is executed, how much of that execution is allowed, and how user experience is built on top of it are all separate design concerns. These may appear as a single feature, but they belong to different layers.
While building View Generation in CommerceOS, this distinction became clear. Designing the execution environment and connecting that result to interaction cannot be solved in the same way.
In this article, we focus on the first part: how to safely execute AI-generated UI
AI-generated UI requires an execution environment
In frontend development, iframe is often seen as an outdated technology.
In CommerceOS, it was chosen for a completely different reason.
The output generated from user requests is not just data. It includes React code and data queries, and it is something that actually runs. This result behaves like a small application inside the browser.
At this point, the question changes. It is no longer about how to display it, but about where to execute this code.
In an enterprise setting, this distinction becomes critical.
The scope and impact of execution must remain controllable.
The actual problem we needed to solve
View Generation in CommerceOS is not just about rendering results.
The generated output is used within real workflows.
The system needed to satisfy several conditions at the same time.
The AI-generated code must run separately from the host application. Users should be able to see the result immediately. They should also be able to continue editing based on that result. The system should recover even if the execution environment is interrupted.
From these conditions, the conclusion becomes clear.
This is not about how to load components. It is about how to limit the execution scope.
Why iframe
When considering micro frontend architecture, Module Federation is a strong option.
It was also seriously considered.
However, the criteria in this case were different. Module Federation assumes a shared execution context. Code runs in the same runtime, and state and dependencies are shared. This is efficient for internal systems, but it becomes risky when the behavior of generated code is unpredictable.
iframe works differently.
The execution environment is isolated. DOM and JavaScript contexts remain independent. The execution scope is clearly separated, so any issue is contained within that boundary.
This difference was important in CommerceOS.
The priority was not performance or developer convenience, but how far execution should be allowed.
iframe is a boundary, not a feature
This decision is not just about implementation.
It defines where execution happens in the system.
In CommerceOS, iframe is used as a boundary that separates execution.
User-generated code runs only within this boundary, while the host application manages state outside of it. This structure limits the impact of failures to a confined area.
From this perspective, iframe is not outdated.
It is a direct way to define and enforce execution boundaries.
How constraints were designed
The iframe itself is only a tool. What matters is how constraints are applied on top of it.
CommerceOS applied several principles to control the execution environment.
Execution always happens in a different origin
Code running in the same origin has equivalent access to the host.
The sandbox environment is always enforced to run in a different origin.
This keeps a clear boundary between the host application and the execution environment.
Permissions are explicitly limited
The sandbox starts with most capabilities disabled.
Only the necessary permissions are allowed.
In development environments, permissions are broader to support debugging and interaction. In production, only minimal permissions are kept.
This approach ensures stability in real usage.
Data flow is also restricted
Separating execution is not enough.
Data flow must also be controlled.
CSP is applied inside the iframe so that requests can only be sent to allowed endpoints. This keeps both execution and data flow within predictable limits.
Summary
Once you start working with AI-generated UI, frontend is no longer just a rendering layer.
It becomes an execution layer that must be controlled.
CommerceOS addresses this by separating execution environments.
Code runs inside a sandbox, and the host application controls it from the outside.
This structure limits execution scope and maintains system stability.
In the next article, we will explain how interaction is built on top of this isolated execution environment.
in solving your problems with Enhans!
We'll contact you shortly!