Skip to main content
An agent’s answers are composed at runtime, long after your app shipped, so no code review or app release ever sees them. Metabind’s governance model constrains every one of them. The model picks from components you published and fills in their typed fields; it never writes HTML or code. Every response is checked before it renders. Four mechanisms do the work. Metabind’s server runs these checks before a response reaches any host, so they apply the same way in Claude, ChatGPT, every MCP host, and your own apps. Metabind’s MCP server implements the open Model Context Protocol and its extensions framework (SEP-2133, first proposed as SEP-1724), and Interactive Tools follow SEP-1865 (MCP Apps: Interactive User Interfaces for MCP).

​
1. Schema validation on every render

Every Interactive Tool has an input schema, derived from the component’s properties declaration. When the model calls the tool, the platform validates the model’s response against the schema before any rendering happens. If the model returns malformed data, such as a missing required field, a wrong type, or an out-of-range number, the call is rejected with a typed error and the renderer is never invoked. The error names the fields that failed, so the model can correct its response on retry. Validation is not opt-in. Every tool call goes through it.

​
2. Component allowlists

A layout component declares which view components the model is allowed to compose inside each slot. The allowlist is part of the component’s BindJS property definitions, the slot property’s allowedComponents array. It becomes part of the tool’s schema, so the server-side validation above enforces it. If the model references a component that isn’t on the list, the call is rejected and that component never reaches the renderer.
A layout component is required as the root of every Interactive Tool, and its child components can themselves be layouts with their own allowed components, so allowlists can nest. The full JSON schema for the layout (root, children, and their nested allowlists) is what the model sees. This is the core mechanism that keeps every answer inside your design system: the model composes what the layout permits and nothing else.

​
3. Isolated on the server, sandboxed on the client

Data Tools run in V8 isolates, not in the MCP server process. The isolate enforces:
  • Secrets are injected via env.secrets at runtime, never embedded in the component’s code or visible in the package bundle. The model never sees your keys.
  • Outbound HTTP is restricted to allowed domains declared on the Data Tool. A handler cannot reach an arbitrary URL.
  • Execution time and memory are capped (60 seconds, 128 MB by default). Runaway handlers terminate cleanly.
  • No filesystem access, no environment variables, no cross-tenant exposure.
The platform enforces these limits on every call. See Sandboxed execution. On the client, component logic runs in the BindJS runtime with no ambient authority: no DOM, no filesystem, and no network except through channels the host manages. Only a JSON view tree reaches the platform’s renderer, never code. In your own apps, the SDK draws that tree natively. In Claude, ChatGPT, and other hosts, the view renders inside the host’s sandboxed iframe, under the content security policy its tool declares. The runtime is open source under Apache 2.0, so your security team can read every line that runs on your customers’ devices.

​
4. Versioning and rollback

Every published Type is pinned to a specific package version. Editing a published Type puts it in modified status: the production endpoint continues to serve the last published version while the draft endpoint shows the working copy. When you publish, the package version increments. Reverting is a metadata change: metabind rollback re-pins tools to a previous package version. No redeploy, no rebuild. This means a bad publish never strands your users. You see the issue in the project’s execution history, you roll back, and production is whole again.

​
Tool-call history

Every tool call is recorded in the project’s execution history, with its timestamp, tool, status, timing, how the caller authenticated, and a short snippet of its input and output. Failed validations and rejected calls are recorded alongside successful ones, so a governance review can see what the model tried to do, not just what got through. Each failure carries an error type (configuration, runtime, tool, or upstream), so failures separate cleanly when triaging. Analytics roll usage up per tool: call count, success and failure counts, latency averages and p95s. Find both under Analytics in Metabind Studio, on the Developer plan and up.

​
Why this matters

Answers are composed at runtime, so the checks have to travel with every answer. MCP and AI gateways govern which tools and data an agent can reach; Metabind also governs what it shows. The two work together. For an enterprise team, the governance model is the difference between prototype and deployable. For a developer team, it’s the difference between writing infrastructure to constrain the model and writing tools.

​
What governance does not cover

Governance constrains what the model can render and which tools it can call. It does not constrain what the model says in text or what the LLM provider’s safety filters do. Those are concerns for the LLM provider and the host application, not the rendering platform. With the Agent Proxy, your system prompt steers the model on every turn, but a prompt can’t force a model’s wording. Governance also does not enforce business correctness. A Data Tool that returns the wrong price returns the wrong price. Schema validation catches malformed responses, not factually wrong ones. Tool design and the model’s own reasoning carry that responsibility.

​
Where governance lives in Metabind Studio

Governance settings appear in two places in the UI:
  • Component editor → property → allowedComponents declares which components can be composed in each slot of a layout. Authored in BindJS as part of the property definition. See Component allowlists.
  • Data Tool → Allowed Domains and Secrets scopes outbound HTTP and credentials per Data Tool. See Data Tools.

Tools and Types

What the governance model is governing.

Components and Packages

How allowlists and packages combine for safe rendering.

Sandboxed execution

How Data Tool handlers run, and their limits.

Schema validation in depth

How schema validation runs and what it catches.