Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · October 10, 2026 · repo

CopilotKit OpenIntelligentUIOpen Generative UITypeSafe Jevagent-securityagent-harnessfrontier-models

OpenIntelligentUI Runs Model-Written Code in Your Browser, and the Bridge Is the Security Model

CopilotKit's open-source answer to ChatGPT's Intelligent UI turns questions into working tools. What that generated code can reach, and which host functions you hand it, decide whether it is safe to ship.

Ask a chat model how a mortgage payment changes with the rate, and for years you got a paragraph and maybe a table. Ask the same question in CopilotKit/OpenIntelligentUI and you can get a working calculator with sliders. The model did not pick a calculator from a menu. It wrote one, in HTML, CSS and JavaScript, and your browser ran it.

That is a bigger shift than it sounds. A chat answer used to be data you read. Now it is a program you execute.

OpenIntelligentUI sat at #8 on Trendshift's daily board this morning (read at about 07:10 ET), the same week OpenAI started rolling out GPT-6 with Intelligent UI in ChatGPT on October 7. The two are not connected; the README never mentions OpenAI's feature, and OpenAI appears only as the default model provider. But they answer the same question in very different ways, and the difference is where the security story lives.

Two ways to make an answer interactive

OpenAI's GPT-6 announcement describes Intelligent UI as "a library of native, streamable components, along with a compiler that processes the interface as the model generates it." The model arranges pieces from a fixed kit: charts, buttons, forms. OpenAI does not say whether generated tools execute model-written code, and OpenAI describes the release as an update to the Chat experience in ChatGPT, with no mention of the API.

OpenIntelligentUI does both. Per its README, the answer model (chat-latest from OpenAI by default) works with a router, TypeSafe's Jev decision model (jev-latest), which picks a renderer for each turn. "Basic tables use A2UI; charts, diagrams, calculators, and maps use Open Generative UI." A2UI is the declarative path: the model describes components and the app renders them. Open Generative UI is the other path, where generateSandboxedUi "streams custom HTML, CSS, and JavaScript into an isolated iframe."

So the same app contains both philosophies. Declarative components for the safe, boring stuff. Arbitrary model-written code for anything that needs to move. And a decision model choosing between them on every turn.

What actually contains the generated code

CopilotKit's Open Generative UI docs describe the container as an "isolated iframe without same-origin access." That matters. Without same-origin access, the generated code cannot read your app's cookies, local storage or DOM. It is the right default.

Two other details in the same docs deserve as much attention.

First, the iframe can load outside code: "The sandboxed iframe can load external libraries from CDNs," and names Chart.js, D3 and Three.js as examples. That is how a model gets a 3D viewer or a real chart into a chat bubble. It also means generated code runs with some network reach. The docs do not list the iframe's exact sandbox attributes, a Content Security Policy, or a network policy, so you cannot tell from the documentation alone what else that code can contact.

Second, the generated UI talks back to your app through functions you define. Each one is "a Zod-validated, host-side bridge" that the iframe calls through Websandbox.connection.remote.<name>(args), and "your handler runs with the validated args" on the host page. In OpenIntelligentUI, a user-clicked follow-up "can send selected values through the validated host bridge and start another agent turn."

Here is my position, and the reason this repo is worth reading closely even if you never deploy it. The iframe is the wall. The bridge is the door. Zod checks that arguments have the right shape. It does not check whether the action is one you meant to allow. Every handler you register is an API that model-written code can call with any well-shaped input, and a model writes that code from whatever ended up in its context, including text a user pasted or a page an agent fetched.

The docs' own example shows how easy it is to get this wrong. The sample evaluateExpression handler filters input with a regex and then runs it with the Function constructor, with a comment saying the filter exists "so we never exec arbitrary JS." That is a regex standing between generated code and code execution on the host page. It is a demo, and the page does not present it as a security pattern. Copy it into production and it becomes one.

The key handling is careful, and the warning is about something else

OpenIntelligentUI handles provider keys thoughtfully. Visitors can paste their own OpenAI and TypeSafe keys in the chat header; the app keeps them in browser memory, "does not save them in browser storage," and keeps them out of chat state and checkpoints. Shared server-side keys are optional.

But requests still pass through the application server on their way to each provider. That is why the README says, in its section on using your own keys: "Only use this feature on a deployment whose operator you trust." The warning is about whoever runs the server seeing your keys, not about the generated UI. Both concerns are real. They are different, and it is worth keeping them apart when you evaluate any hosted generative UI demo.

Put this into practice

The quickstart is short. You need Node 22+, pnpm 9+, Python 3.12+ and uv, plus an OPENAI_API_KEY and a TYPESAFE_API_KEY.

git clone https://github.com/CopilotKit/OpenIntelligentUI.git
cd OpenIntelligentUI
make setup
make dev

The app runs at localhost:3000, with an agent health check at localhost:8123/health. The agent is a Python Deep Agent on FastAPI, and CopilotKit carries its stream to a Next.js front end.

Then do the part the quickstart does not ask for:

1. Inventory the bridge. List every host-side handler the generated UI can call. For each one, write down what it does with valid input chosen by an adversary. If any handler evaluates expressions, writes data, sends messages or triggers another agent turn, treat it like a public endpoint.

2. Inspect the iframe in your browser's dev tools. Read the actual sandbox attribute and any CSP on the frame. The docs do not state them, so look. Decide whether generated code needs network access beyond the CDNs it loads, and pin those CDNs with a CSP if it does not.

3. Prompt-inject your own demo. Paste text into the chat that tells the model to generate UI calling a bridge function with odd arguments, or to fetch an outside URL. Watch what happens. This takes ten minutes and teaches more than any README.

4. Use the declarative path where you can. If your product only needs tables and standard charts, A2UI-style components avoid running model-written code at all. Reserve generated code for the cases that need it.

5. Watch the router. Jev picks the renderer every turn, so "outputs can vary," as the README says. If a provider fails, the app surfaces the error "instead of silently substituting another router or model," which is good behavior to keep if you fork it.

Honest limits

This is a young repo. It has no tagged releases, and star counts disagree between sources this morning (shields and the rendered GitHub page put it somewhere between about 1.6k and 2.2k), so treat its popularity as momentum, not maturity. It is MIT-licensed, copyright Atai Barkai.

It depends on two hosted providers, OpenAI for answers and TypeSafe for routing, so you need two keys and two vendors' terms before the first chat. Jev's role means one more model whose behavior can shift under you.

The README's sample content is honest about itself ("Sample numbers are illustrations, not live business or weather data"), and it notes that tests and builds "do not verify model access or a deployment." The launch film uses rendered scenes. Do not judge the output quality from the demo; judge it from your own prompts.

And the core limit belongs to generative UI as a category, not to this project. The iframe without same-origin access is a strong default, but documentation that leaves out the sandbox attributes and network policy leaves the most important security decisions to whoever deploys it. The standalone MCP option makes that explicit: its assemble_document tool returns HTML as text, and "a compatible host must render it and implement the bridge." Once you take that HTML into your own host, every decision above is yours.

What to decide before you ship an answer that runs

Interactive answers are coming whether builders plan for them or not. OpenAI ships them as a component kit inside ChatGPT. OpenIntelligentUI ships them as code you can read, which is exactly why it is useful: you can see where the wall is and where the door is.

Before you put model-written code in front of users, answer one question in writing. If the model generated the worst possible UI from the worst possible input, which of your bridge functions would it call, and what would happen? If you cannot answer, you are not ready to ship the door.

Sources: CopilotKit/OpenIntelligentUI README; CopilotKit Open Generative UI docs; OpenAI, "GPT-6 and Intelligent UI for everyone" (Oct 7, 2026); Trendshift daily board, read about 07:10 ET Oct 10, 2026.

Medium metadata

  • Title: OpenIntelligentUI Runs Model-Written Code in Your Browser, and the Bridge Is the Security Model
  • Subtitle: CopilotKit's open-source generative UI turns chat answers into working tools. The functions you expose to that code decide whether it is safe.
  • Tags: Generative UI, AI Agents, Web Security, Open Source, JavaScript
  • Canonical URL: import from the fervorai.dev article URL
  • Reading time: about 8 minutes